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

API-Monitoring

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

1. Melden Sie sich bei der Edge-UI als Nutzer mit einem Rolle.

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

   
3. Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
4. Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.

5. Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.

   <ph type="x-smartling-placeholder">

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

   

7. Informationen zum Fehlercode protocol.http.Response405WithoutAllowHeader wird wie folgt angezeigt:

   

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

   
9. Im Fenster Logs werden die folgenden Details angezeigt: <ph type="x-smartling-placeholder">
   </ph>
   • Statuscode: 502
   • Fehlerquelle: target
   • Fehlercode: protocol.http.Response405WithoutAllowHeader.
10. Wenn die Fehlerquelle target und der Fehlercode protocol.http.Response405WithoutAllowHeader, dann bedeutet dies, dass das Back-End Der Server hat mit dem Statuscode 405 Method Not Allowed ohne den Allow-Header.

Trace-Tool

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

1. Aktivieren Sie die Funktion . Trace-Sitzung und entweder <ph type="x-smartling-placeholder">
   </ph>
   • Warten Sie, bis der Fehler 502 Bad Gateway auftritt, oder
   • Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus, um es zu reproduzieren: 502 Bad Gateway Fehler

2. Achten Sie darauf, dass Show all FlowInfos (Alle FlowInfos anzeigen) aktiviert ist:

   
3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
4. Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.

5. Sie finden den Fehler normalerweise in einem Ablauf nach der Anfrage an den Zielserver gesendet wie unten dargestellt:

   

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 ausgegeben wird, nachdem die Anfrage an das Backend gesendet wurde Server gibt es an, dass der Backend-Server den Antwortstatuscode 405 gesendet hat. ohne den Header Allow.

7. Navigieren Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.

8. Scrollen Sie nach unten zum Abschnitt Error / Response Headers (Fehler-/Antwort-Header) in den Phase Details (Phase-Details). und bestimmen die für X-Apigee-fault-code und X-Apigee-fault-code, wie unten gezeigt:

   
9. Sie sehen die Werte X-Apigee-fault-code und X-Apigee-fault-code als protocol.http.Response405WithoutAllowHeader bzw. target, Dieser Fehler wird dadurch verursacht, dass das Backend den Antwortstatuscode 405 ohne den Header Allow.

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

NGINX

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

1. Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs die wichtige Informationen zu HTTP-502-Fehlern.

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. Nach 502-Fehlern mit Fehlercode suchen protocol.http.Response405WithoutAllowHeader während eines bestimmten Zeitraums (wenn der in der Vergangenheit aufgetreten ist) oder wenn immer noch Anfragen mit 502

4. Wenn Sie 502-Fehler mit dem X-Apigee-fault-code finden, der den Wert von protocol.http.Response405WithoutAllowHeader und ermitteln Sie dann den Wert der X-Apigee-fault-source..

   Beispielfehler 502 aus dem NGINX-Zugriffsprotokoll:

   

   Der obige Beispieleintrag aus dem NGINX-Zugriffslog enthält die folgenden Werte für X-Apigee- Fehlercode und X-Apigee-Fehler-Quelle:

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

Back-End-Server

Option 1: Korrigieren Sie den Backend-Server, damit dieser den Statuscode 405 mit dem Header „Allow“ sendet:

1. Sicherstellen, dass der Backend-Server immer die Spezifikation einhält <ph type="x-smartling-placeholder"></ph> RFC 7231, Abschnitt 6.5.5: 405 Method Not Allowed und sendet mit dem Status 405. indem Sie die Liste der zulässigen Methoden als Teil eines Allow-Headers einfügen wie unten dargestellt:

   Allow: HTTP_METHODS
   

2. Wenn dein Backend-Server beispielsweise GET, POST und HEAD-Methoden verwenden, müssen Sie darauf achten, dass der Header Allow Folgendes enthält: wie folgt:

   Allow: GET, POST, HEAD
   

Fehlerbehebung

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

Wenn der Backend-Server den Statuscode 405 ohne das Allow-Objekt zurückgibt können Sie mithilfe der Fehlerbehandlung mit dem Statuscode 405 und dem Allow-Header von Ihrem API-Proxy folgendermaßen ab:

1. Erstellen Sie eine Richtlinie wie AssignMessage-Richtlinie oder RaiseFault-Richtlinie und setzen Sie den Statuscode auf 405 mit dem Header Allow und einem benutzerdefinierten angezeigt.

   Beispiel-Richtlinie „AssignMessage“ zum Senden von 405-Fehlern 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. FaultRule in TargetEndpoint erstellen, die die Richtlinie aufruft bei Ausgabe des Fehlers 502 mit dem Fehlercode protocol.http.Response405WithoutAllowHeader.

   TargetEndpoint-Konfigurationsbeispiel 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. Führen Sie die API-Aufrufe aus und prüfen Sie, ob Sie den Statuscode 405 mit dem Allow-Header.

Property konfigurieren

Option 3: Attribut im Message Processor konfigurieren, um zu verhindern, dass Apigee Edge Fehler 502 wird zurückgegeben

1. Wenn Sie Nutzer der Private Cloud sind, können Sie die Property aktualisieren. HTTP.ignore.allow_header.for.405 bis true, um zu verhindern, dass Apigee Edge wird ein 502-Fehler ausgelöst, auch wenn der Backend-Server mit 405 antwortet ohne den Header Allow: Konfigurieren des Ignorieren-Zulassungsheaders für die Property 405 in Message Processors.
2. Wenn Sie Public Cloud-Nutzer sind, wenden Sie sich bitte an den Apigee Edge-Support.