„502 Bad Gateway“ – ResponseWithBody

Sie lesen gerade die Apigee Edge -Dokumentation.
Zur Apigee X -Dokumentation. info

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 502 Bad Gateway mit dem Fehlercode protocol.http.ResponseWithBody als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 502 Bad Gateway

Außerdem kann eine der folgenden Fehlermeldungen angezeigt werden:

{
   "fault":{
      "faultstring":"Received 204 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

{
   "fault":{
      "faultstring":"Received 205 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

Mögliche Ursachen

Dieser Fehler tritt auf, wenn die HTTP-Antwort vom Backend-Server an Apigee Edge entweder 204 No Content oder 205 Reset Content lautet, aber den Antwort text und/oder einen oder mehrere der folgenden Header enthält:

• Content-Length
• Content-Encoding
• Transfer-Encoding

Gemäß den Spezifikationen RFC 7231, Abschnitt 6.3.5: 204 No Content und RFC 7231, Abschnitt 6.3.6: 205 Reset Content, sollten vom Ursprungsserver keine zusätzlichen Inhalte als Teil des Antwortnutzlasttexts mit dem Statuscode 204 No Content oder 205 Reset Content gesendet werden. Die Antwortheader wie Content-Length, Content-Encoding oder Transfer-Encoding geben die Größe, den Typ oder das Format der Antwortnutzlast an.

Daher gibt Apigee Edge unter den folgenden Umständen den Statuscode 502 Bad Gateway mit dem Fehlercode protocol.http.ResponseWithBody an den Client zurück:

Mögliche Ursachen für diesen Fehler:

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools/Verfahren, um diesen Fehler zu diagnostizieren:

Ursache: Antworttext oder Header mit 204-Antwort vom Backend-Server

Diagnose

1. Ermitteln Sie den Fehlercode und die Fehlerquelle für den beobachteten Fehler mithilfe des API Monitorings, des Trace-Tools oder der NGINX-Zugriffsprotokolle, wie unter Allgemeine Diagnoseschritte erläutert.
2. Wenn der Fehlercode protocol.http.ResponseWithBody ist und Fehlerquelle den Wert target hat, hat der Backend-Server mit einem 204 No Content oder 205 Reset Content Statuscode mit dem Antworttext und/oder einem der im Abschnitt Mögliche Ursachen genannten Header geantwortet.

3. So prüfen Sie, ob der Backend-Server tatsächlich einen Antwortnutzlasttext und/oder einen oder mehrere der im Abschnitt Mögliche Ursachen genannten Header gesendet hat:

   1. Wenn Sie Public Cloud-Nutzer sind, können Sie dieselbe API-Anfrage direkt von einem Ihrer Systeme an den Backend-Server senden.

   2. Wenn Sie Private Cloud-Nutzer sind, können Sie dieselbe API-Anfrage direkt von einem der Nachrichtenverarbeiter, die der jeweiligen Organisation und Umgebung zugeordnet sind, in denen der Fehler aufgetreten ist, an den Backend-Server senden.

   3. Prüfen Sie die vom Backend-Server empfangene Antwort und vergewissern Sie sich, dass sie einen Antwortnutzlasttext und/oder einen oder mehrere der oben genannten Header enthält. Wenn ja, ist dies die Ursache für diesen Fehler.

      Beispiel 1

      Beispiel 1: Backend-Serverantwort 204 mit Content-Encoding-Header

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Encoding: gzip
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      In diesem Beispiel hat der Backend-Server mit 204 No Content Statuscode und Content-Encoding: gzip geantwortet.

      Beispiel 2

      Beispiel 2: Backend-Serverantwort 204 mit Content-Length-Header

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Length: 48
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      In diesem Beispiel hat der Backend-Server mit 204 No Content Statuscode und Content-Length: 48 geantwortet.

      Beispiel 3

      Beispiel 3: Backend-Serverantwort 205 mit Antworttext

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 205 Reset Content
      < Date: Sat, 31 Jul 2021 17:14:09 GMT
      < Content-Length: 12
      < Content-Type: text/plain; charset=utf-8
      <
      * Connection #0 to host X.X.X.X left intact
      This is a sample Response
      

      In diesem Beispiel hat der Backend-Server mit 205 Reset Content Statuscode und Antworttext This is a sample Response. geantwortet.

   4. In allen oben genannten Beispielen hat der Backend-Server den Statuscode 204 No Content oder 205 Reset Content mit dem Antworttext und/oder einem der im Abschnitt Mögliche Ursachen genannten Header gesendet.
   5. Daher hat Apigee Edge den Statuscode 502 Bad Gateway mit dem Fehlercode protocol.http.ResponseWithBody gesendet.

Auflösung

Achten Sie darauf, dass der Backend-Server beim Senden der 204 No Content oder 205 Reset Content Antwort an Apigee Edge immer die Spezifikation RFC 7231, Abschnitt 6.3.6: 205 Reset Content einhält. Das bedeutet, dass der Backend-Server NICHT Folgendes als Teil einer 204 No Content oder 205 Reset Content-Antwort senden darf:

1. Antwortnutzlasttext
2. Und einer der folgenden Header:
   1. Content-Length
   2. Content-Encoding
   3. Transfer-Encoding

Spezifikation

Apigee Edge antwortet mit 502 Bad Gateway Statuscode und dem Fehlercode protocol.http.ResponseWithBody wenn der Backend-Server eine 204 No Content oder 205 Reset Content Antwort sendet, aber die folgenden RFC-Spezifikationen nicht einhält:

Wichtige Hinweise

Die empfohlene Lösung besteht darin, den Backend-Server so zu konfigurieren, dass er den 204 No Content und 205 Reset Content Statuscode ohne Antworttext und ohne die Header - Content-Length, Content-Encoding, und Transfer-Encoding sendet und die Spezifikationen RFC 7231, Abschnitt 6.3.5: 204 No Content und RFC 7231, Abschnitt 6.3.6: 205 Reset Content einhält.

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie den Abschnitt Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Erfassen Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

Wenn Sie Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Name der Organisation
• Name der Umgebung
• Name des API-Proxys
• Vollständiger curl-Befehl zum Reproduzieren des Fehlers 502
• Trace-Datei für die API-Anfragen

Wenn Sie Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
• Name der Umgebung
• API-Proxy-Bundle
• Trace-Datei für die API-Anfragen

• NGINX-Zugriffsprotokolle /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

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

• Message Processor-Systemprotokolle /opt/apigee/var/log/edge-message-processor/logs/system.log