Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
Symptom
Die Clientanwendung erhält als Antwort auf API-Aufrufe den HTTP-Statuscode 502 Bad Gateway
mit dem Fehlercode protocol.http.Response405WithoutAllowHeader
.
Fehlermeldung
Die Clientanwendung ruft den folgenden Antwortcode ab:
HTTP/1.1 502 Bad Gateway
Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:
{ "fault":{ "faultstring":"Received 405 Response without Allow Header", "detail":{ "errorcode":"protocol.http.Response405WithoutAllowHeader" } } }
Mögliche Ursachen
Dieser Fehler tritt auf, wenn der Back-End-Server mit dem Statuscode 405 Method Not Allowed
ohne den Header Allow
antwortet.
Gemäß der Spezifikation
RFC 7231, Abschnitt 6.5.5: 405 Method Not Allowed muss der Ursprungsserver voraussichtlich ein Allow
-Header-Feld in einer 405
-Antwort generieren und senden, die eine Liste der derzeit von der Zielressource unterstützten Methoden enthält. Andernfalls antwortet Apigee mit 502 Bad Gateway
und dem Fehlercode protocol.http.Response405WithoutAllowHeader
.
Ursache | Beschreibung | Anleitungen zur Fehlerbehebung gelten für |
---|---|---|
405-Antwort ohne „Allow-Header des Back-End-Servers“ | Der Back-End-Server, der die API-Anfrage verarbeitet, antwortet mit dem Statuscode 405 ohne Allow -Header. |
Nutzer von Edge Public und Private Cloud |
Allgemeine Diagnoseschritte
Verwenden Sie eines der folgenden Tools oder Methoden, um diesen Fehler zu diagnostizieren:
API-Monitoring
So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:
- Melden Sie sich bei der Edge-UI als Nutzer mit einer entsprechenden Rolle an.
Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.
- Rufen Sie die Seite Analysieren > API-Überwachung > Untersuchen auf.
- Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
Stellen Sie den Fehlercode der Zeit gegenüber.
Wählen Sie eine Zelle mit dem Fehlercode
protocol.http.Response405WithoutAllowHeader
aus, wie unten dargestellt:Informationen zum Fehlercode
protocol.http.Response405WithoutAllowHeader
werden wie unten dargestellt angezeigt:Klicken Sie auf Logs ansehen und maximieren Sie eine der fehlgeschlagenen Anfragen, um weitere Informationen zu sehen.
- Notieren Sie sich im Fenster Logs die folgenden Details:
- Statuscode:
502
- Fehlerquelle:
target
- Fehlercode:
protocol.http.Response405WithoutAllowHeader
.
- Statuscode:
- Wenn die Fehlerquelle
target
und der Fehlercodeprotocol.http.Response405WithoutAllowHeader
ist, bedeutet dies, dass der Back-End-Server mit dem Statuscode405 Method Not Allowed
ohne den HeaderAllow
geantwortet hat.
Trace-Tool
So diagnostizieren Sie den Fehler mit dem Trace-Tool:
- Aktivieren Sie die
Trace-Sitzung und entweder
- 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 das Problem zu reproduzieren –
502 Bad Gateway
-Fehler
- Warten Sie, bis der Fehler
Achten Sie darauf, dass Show all FlowInfos aktiviert ist:
- Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
- Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.
Der Fehler tritt normalerweise in einem Ablauf nach der Phase Anfrage an Zielserver gesendet auf, wie unten dargestellt:
Notieren Sie sich den Wert des Fehlers aus dem Trace.
Das obige Beispiel-Trace zeigt den Fehler als
Received 405 Response without Allow Header
. Da der Fehler von Apigee ausgelöst wird, nachdem die Anfrage an den Back-End-Server gesendet wurde, weist er darauf hin, dass der Back-End-Server den Antwortstatuscode405
ohne den HeaderAllow
gesendet hat.- Gehen Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.
Scrollen Sie im Bereich Phasendetails nach unten zum Abschnitt Fehler-/Antwortheader und ermitteln Sie die Werte von X-Apigee-Fehler-Code und X-Apigee-Fehler-Quelle, wie unten gezeigt:
- Die Werte von X-Apigee-fault-code und X-Apigee-fault-code werden als
protocol.http.Response405WithoutAllowHeader
bzw.target
angezeigt. Dies weist darauf hin, dass dieser Fehler verursacht wird, weil das Back-End den Antwortstatuscode405
ohne den HeaderAllow
gesendet hat.Antwortheader Wert X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
X-Apigee-fault-source target
NGINX
So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs die wichtigsten Informationen zu HTTP-
502
-Fehlern ermitteln. Prüfen Sie die NGINX-Zugriffslogs:
/opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
Wo:ORG, ORG und PORT# werden durch die tatsächlichen Werte ersetzt.
- Prüfen Sie, ob während eines bestimmten Zeitraums (wenn das Problem in der Vergangenheit aufgetreten ist)
502
-Fehler mit dem Fehlercodeprotocol.http.Response405WithoutAllowHeader
aufgetreten sind oder ob Anfragen immer noch mit502
fehlschlagen. Wenn Sie
502
-Fehler mit dem X-Apigee-fault-code finden, der dem Wert vonprotocol.http.Response405WithoutAllowHeader
entspricht, bestimmen Sie den Wert von X-Apigee-fault-code .Beispiel für einen 502-Fehler aus dem NGINX-Zugriffslog:
Der obige Beispieleintrag aus dem NGINX-Zugriffslog enthält die folgenden Werte für X-Apigee-Fehler-Code und X-Apigee-Fehler-Quelle:
Antwortheader Wert X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
X-Apigee-fault-source target
Ursache: 405-Antwort ohne Zulassen-Header des Back-End-Servers
Diagnose
- Bestimmen Sie den Fehlercode und die Fehlerquelle für
502 Bad Gateway
mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte erläutert. - Wenn der Fehlercode
protocol.http.Response405WithoutAllowHeader
lautet und die Fehlerquelle den Werttarget
hat, bedeutet dies, dass der Back-End-Server mit einem Statuscode405
ohne den HeaderAllow
geantwortet hat. Daher antwortet Apigee mit502 Bad Gateway
mit dem Fehlercodeprotocol.http.Response405WithoutAllowHeader
.
Auflösung
Wenden Sie eine der folgenden Methoden an, um das Problem zu beheben:
Back-End-Server
Option 1: Beheben Sie das Problem, dass der Back-End-Server den Statuscode 405 mit dem Header „Allow“ sendet:
Der Back-End-Server muss immer der Spezifikation RFC 7231, Abschnitt 6.5.5: 405 Method Not Allowed entsprechen und mit dem Statuscode
405
gesendet werden. Dazu nehmen Sie die Liste der zulässigen Methoden als Teil einesAllow
-Headers auf, wie unten dargestellt:Allow: HTTP_METHODS
- Wenn Ihr Back-End-Server beispielsweise die Methoden
GET
,POST
undHEAD
zulässt, müssen Sie dafür sorgen, dass der HeaderAllow
sie so enthält:Allow: GET, POST, HEAD
Fehlerbehebung
Option 2: Über die Fehlerbehandlung den 405-Statuscode mit dem „Allow“-Header von deinem API-Proxy senden:
Wenn der Back-End-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:
Erstellen Sie eine Richtlinie wie die AssignMessage-Richtlinie oder die IncreaseFault-Richtlinie und legen Sie den Statuscode auf
405
mit demAllow
-Header und einer benutzerdefinierten Nachricht fest.Beispiel für die Methode „AssignMessage“ zum Senden von 405 mit „Allow“-Header:
<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>
Erstellen Sie ein
FaultRule
imTargetEndpoint
, das die Richtlinie aufruft, wenn der Fehler502
mit dem Fehlercodeprotocol.http.Response405WithoutAllowHeader
zurückgegeben wird.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>
- Speichern Sie diese Änderungen in einer neuen Version des API-Proxys und stellen Sie die Überarbeitung bereit.
- Führen Sie die API-Aufrufe aus und prüfen Sie, ob Sie den Statuscode
405
mit dem HeaderAllow
erhalten.
Property konfigurieren
Option 3: Konfigurieren Sie das Attribut im Message Processor, um zu verhindern, dass Apigee Edge den Fehler 502 zurückgibt
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie das Attribut
HTTP.ignore.allow_header.for.405
auftrue
aktualisieren, um zu verhindern, dass Apigee Edge den Fehler502
ausgibt, auch wenn der Back-End-Server mithilfe der Anleitung mit der Anleitung den Statuscode405
ohne den HeaderAllow
zurückgibt: Konfigurieren Sie den Header zum Ignorieren von 405-Attributen in Nachrichtenprozessoren. - Wenn Sie die öffentliche Cloud verwenden , wenden Sie sich bitte an den Apigee Edge-Support.
Spezifikation
Apigee erwartet die Antwort 405 Method Not Allowed
vom Back-End-Server zusammen mit dem Allow
-Header gemäß den folgenden Spezifikationen:
Spezifikation | |
---|---|
RFC 7231, Abschnitt 6.5.5: 405 Methode nicht zulässig | |
RFC 7231, Abschnitt 7.4.1: Zulassen |
Wichtige Hinweise
Die empfohlene Lösung besteht darin, den Back-End-Server so zu reparieren, dass der Statuscode 405
mit dem Allow
-Header gesendet wird und die Spezifikation
RFC 7231, Abschnitt 6.5.5: 405 Methode nicht zulässig eingehalten wird.
Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie Diagnoseinformationen müssen eingeholt werden.
Erfassen von Diagnoseinformationen erforderlich
Wenn das Problem auch nach Befolgen der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen und wenden Sie sich an den Apigee Edge-Support.
Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
- Name der Organisation
- Name der Umgebung
- API-Proxy-Name
- Führen Sie den Befehl
curl
aus, der zum Reproduzieren von502 Bad Gateway
mit dem Fehlercodeprotocol.http.Response405WithoutAllowHeader
verwendet wurde. - Ablaufverfolgungsdatei für die API-Anfragen
Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
- Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
- Name der Umgebung
- API-Proxy-Bundle
- Ablaufverfolgungsdatei für die API-Anfragen
NGINX-Zugriffslogs
/opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
Wo:ORG, ORG und PORT# werden durch die tatsächlichen Werte ersetzt.
- Systemprotokolle von Message Processor
/opt/apigee/var/log/edge-message-processor/logs/system.log