„502 Bad Gateway“ – Antwort 405 ohne „Allow Header“ (Zulassen-Header)

API-Monitoring

So diagnostizieren Sie den Fehler mit dem API-Monitoring:

1. Melden Sie sich in der Edge-Benutzeroberfläche als Nutzer mit einer geeigneten Rolle an.

2. Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.

   
3. Rufen Sie die Seite Analysieren > API-Monitoring > Untersuchen auf.
4. Wählen Sie den Zeitraum aus, in dem die Fehler aufgetreten sind.

5. Stellen Sie Fehlercode im Verhältnis zu Zeit dar.

6. Wählen Sie eine Zelle mit dem Fehlercode protocol.http.Response405WithoutAllowHeader aus, wie unten gezeigt:

   

7. Informationen zum Fehlercode protocol.http.Response405WithoutAllowHeader werden wie unten gezeigt angezeigt:

   

8. Klicken Sie auf Logs ansehen und maximieren Sie eine der fehlgeschlagenen Anfragen, um weitere Informationen aufzurufen.

   
9. Notieren Sie sich im Fenster Logs die folgenden Details:
   • Statuscode:502
   • Fehlerquelle:target
   • Fehlercode:protocol.http.Response405WithoutAllowHeader.
10. Wenn die Fehlerquelle target und der Fehlercode protocol.http.Response405WithoutAllowHeader ist, hat der Backend-Server mit dem Statuscode 405 Method Not Allowed ohne den Header Allow geantwortet.

Trace-Tool

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

1. Aktivieren Sie die Trace-Sitzung und entweder
   • warten Sie, bis der Fehler 502 Bad Gateway auftritt, oder
   • wenn Sie das Problem reproduzieren können, stellen Sie den API-Aufruf, um den Fehler 502 Bad Gateway zu reproduzieren.

2. Achten Sie darauf, dass Alle FlowInfos anzeigen aktiviert ist:

   
3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und untersuchen Sie den Trace.
4. Gehen Sie die verschiedenen Phasen des Traces durch und suchen Sie nach der Stelle, an der der Fehler aufgetreten ist.

5. Der Fehler tritt in der Regel in einem Ablauf nach der Phase Anfrage an Zielserver gesendet auf, wie unten gezeigt:

   

6. Notieren Sie sich den Wert des Fehlers aus dem Trace.

   Im obigen Beispiel-Trace wird der Fehler als Received 405 Response without Allow Header angezeigt. Da der Fehler von Apigee ausgelöst wird, nachdem die Anfrage an den Backend Server gesendet wurde, hat der Backend-Server den 405 Antwortstatuscode ohne den Allow Header gesendet.

7. Rufen Sie im Trace die Phase AX (Analysedaten aufgezeichnet) auf und klicken Sie darauf.

8. Scrollen Sie im Bereich Phasendetails nach unten zum Abschnitt Fehler-/Antwortheader und ermitteln Sie die Werte von X-Apigee-fault-code und X-Apigee-fault-source wie unten gezeigt:

   
9. Die Werte von X-Apigee-fault-code und X-Apigee-fault-source sind protocol.http.Response405WithoutAllowHeader bzw. target, was darauf hinweist, dass dieser Fehler auftritt, weil das Backend den 405 Antwortstatuscode ohne den Allow Header gesendet hat.

   Antwortheader	Wert
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

NGINX

So diagnostizieren Sie den Fehler mit NGINX-Zugriffslogs:

1. Wenn Sie Private Cloud-Nutzer sind, können Sie NGINX-Zugriffslogs verwenden, um die wichtigsten Informationen zu HTTP-502-Fehlern zu ermitteln.

2. Prüfen Sie die NGINX-Zugriffslogs:

   /opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log

   Dabei gilt: ORG, ORG und PORT# werden durch tatsächliche Werte ersetzt.

3. Suchen Sie nach 502-Fehlern mit dem Fehlercode protocol.http.Response405WithoutAllowHeader in einem bestimmten Zeitraum (wenn das Problem in der Vergangenheit aufgetreten ist) oder nach Anfragen, die immer noch mit 502 fehlschlagen.

4. Wenn Sie 502-Fehler finden, bei denen der X-Apigee-fault-code mit dem Wert protocol.http.Response405WithoutAllowHeader übereinstimmt, ermitteln Sie den Wert der X-Apigee-fault-source.

   Beispiel für einen 502-Fehler aus dem NGINX-Zugriffslog :

   

   Der obige Beispielseintrag aus dem NGINX-Zugriffslog hat die folgenden Werte für X-Apigee- fault-code und X-Apigee-fault-source:

   Antwortheader	Wert
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

Backend-Server

Option 1: Backend-Server so korrigieren, dass er den Statuscode 405 mit dem Header „Allow“ sendet :

1. Achten Sie darauf, dass der Backend-Server immer der Spezifikation RFC 7231, Abschnitt 6.5.5: 405 Method Not Allowed entspricht und den 405 Status code sendet, indem er die Liste der zulässigen Methoden als Teil eines Allow Headers einfügt, wie unten gezeigt:

   Allow: HTTP_METHODS

2. Wenn Ihr Backend-Server beispielsweise die Methoden GET, POST und HEAD zulässt, muss der Header Allow diese wie folgt enthalten:

   Allow: GET, POST, HEAD

Fehlerbehandlung

Option 2: Fehlerbehebung verwenden, um den Statuscode 405 mit dem Header „Allow“ von Ihrem API Proxy zu senden:

Wenn der Backend-Server den Statuscode 405 ohne den Header Allow zurückgibt, können Sie die Fehlerbehandlung verwenden, um mit dem Statuscode 405 und dem Header Allow von Ihrem API-Proxy zu antworten. Gehen Sie dazu so vor:

1. Erstellen Sie eine Richtlinie wie die AssignMessage-Richtlinie oder die RaiseFault-Richtlinie und legen Sie den Statuscode auf 405 mit dem Header Allow und einer benutzerdefinierten Nachricht fest.

   Beispiel für eine AssignMessage-Richtlinie zum Senden von 405 mit dem Header „Allow“ :

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-405WithAllowHeader">
       <DisplayName>AM-405WithAllowHeader</DisplayName>
       <Set>
           <Payload contentType="application/json">{"Specified method is not allowed. Please use one of the methods mentioned in the Allow header."}</Payload>
           <StatusCode>405</StatusCode>
           <ReasonPhrase>Method Not Allowed</ReasonPhrase>
       </Set>
       <Add>
           <Headers>
               <Header name="Allow">GET, POST, HEAD</Header>
           </Headers>
       </Add>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

2. Erstellen Sie eine FaultRule in der TargetEndpoint, die die Richtlinie aufruft, wenn der Fehler 502 mit dem Fehlercode protocol.http.Response405WithoutAllowHeader auftritt.

   Beispiel für eine TargetEndpoint-Konfiguration mit FaultRule :

   <TargetEndpoint name="default">
   ...
       <FaultRules>
          <FaultRule name="405WithoutAllowHeader">
               <Step>
                   <Name>AM-405WithAllowHeader</Name>
               </Step>
               <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition>
           </FaultRule>
       </FaultRules>

3. Speichern Sie diese Änderungen in einer neuen Überarbeitung Ihres API-Proxys und stellen Sie die Überarbeitung bereit.
4. Stellen Sie die API-Aufrufe und prüfen Sie, ob Sie den 405 Statuscode mit dem Allow Header erhalten.

Attribut konfigurieren

Option 3: Attribut im Nachrichtenprozessor konfigurieren, um zu verhindern, dass Apigee Edge den Fehler 502 zurückgibt

1. Wenn Sie Private Cloud-Nutzer sind, können Sie das Attribut HTTP.ignore.allow_header.for.405 auf true setzen, um zu verhindern, dass Apigee Edge einen 502 Fehler auslöst, auch wenn der Backend-Server mit dem Statuscode 405 ohne den Header Allow antwortet. Folgen Sie dazu der Anleitung unter: „Ignore allow header for 405 property in Message Processors“ konfigurieren.
2. Wenn Sie Public Cloud-Nutzer sind, wenden Sie sich bitte an den Apigee Edge-Support