502 Bad Gateway – ResponseWithBody

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Problème constaté

L'application cliente reçoit un code d'état HTTP 502 Bad Gateway avec le code d'erreur protocol.http.ResponseWithBody en réponse aux appels d'API.

Message d'erreur

L'application cliente reçoit le code de réponse suivant :

HTTP/1.1 502 Bad Gateway

Vous pouvez également rencontrer l'un des messages d'erreur suivants :

{
   "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"
      }
   }
}

Causes possibles

Cette erreur se produit si la réponse HTTP du serveur backend à Apigee Edge est soit 204 No Content ou 205 Reset Content mais qu'elle contient le corps de la réponse et/ou un ou plusieurs des en-têtes suivants :

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

Conformément aux spécifications RFC 7231, section 6.3.5 : 204 No Content (en anglais) et RFC 7231, section 6.3.6 : 205 Reset Content (en anglais), aucun contenu supplémentaire ne doit être envoyé dans le corps de la charge utile de la réponse avec le code d'état 204 No Content ou 205 Reset Content par le serveur d'origine. Les en-têtes de réponse tels que Content-Length, Content-Encoding ou Transfer-Encoding indiquent la taille, le type ou le format de la charge utile de la réponse.

Par conséquent, Apigee Edge renvoie un code d'état 502 Bad Gateway avec le code d'erreur protocol.http.ResponseWithBody au client dans les circonstances suivantes :

Voici les causes possibles de cette erreur :

Étapes de diagnostic courantes

Utilisez l'un des outils/techniques suivants pour diagnostiquer cette erreur :

Cause : Corps de la réponse ou en-têtes avec une réponse 204 du serveur backend

Diagnostic

1. Déterminez le code d'erreur et la source de l'erreur observée à l'aide de la surveillance des API, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
2. Si le code d'erreur est protocol.http.ResponseWithBody et que la source de l'erreur a la valeur target, cela indique que le serveur backend a répondu avec un code d'état 204 No Content ou 205 Reset Content avec le corps de la réponse et/ou l'un des en-têtes mentionnés dans Causes possibles.

3. Pour vérifier si le serveur backend a bien envoyé un corps de charge utile de réponse et/ou un ou plusieurs des en-têtes mentionnés dans Causes possibles, vous pouvez procéder comme suit :

   1. Si vous êtes un utilisateur du cloud public et que vous pouvez effectuer la même requête API directement auprès du serveur backend à partir de l'un de vos systèmes.

   2. Si vous êtes un utilisateur du cloud privé, vous pouvez effectuer la même requête API directement auprès du serveur backend à partir de l'un des processeurs de messages associés à l'organisation et à l'environnement spécifiques dans lesquels l'échec est observé.

   3. Examinez la réponse reçue du serveur backend et vérifiez qu'elle contient un corps de charge utile de réponse et/ou un ou plusieurs des en-têtes mentionnés ci-dessus. Si c'est le cas, il s'agit de la cause de cette erreur.

      Exemple 1

      Exemple 1 : Réponse 204 du serveur backend avec l'en-tête Content-Encoding

      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
      

      Dans cet exemple, le serveur backend a répondu avec 204 No Content code d'état et Content-Encoding: gzip

      Exemple 2

      Exemple 2 : Réponse 204 du serveur backend avec l'en-tête Content-Length

      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
      

      Dans cet exemple, le serveur backend a répondu avec 204 No Content code d'état et Content-Length: 48

      Exemple 3

      Exemple 3 : Réponse 205 du serveur backend avec le corps de la réponse

      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
      

      Dans cet exemple, le serveur backend a répondu avec 205 Reset Content code d'état avec le corps de la réponse This is a sample Response.

   4. Dans tous les exemples ci-dessus, le serveur backend a envoyé 204 No Content ou 205 Reset Content code d'état avec le corps de la réponse et/ou l'un des en-têtes mentionnés dans Causes possibles.
   5. Par conséquent, Apigee Edge a envoyé le code d'état 502 Bad Gateway avec le code d'erreur protocol.http.ResponseWithBody.

Solution

Assurez-vous que le serveur backend respecte toujours les spécifications RFC 7231, section 6.3.6 : 205 Reset Content (en anglais) lors de l'envoi de la réponse 204 No Content ou 205 Reset Content à Apigee Edge. Autrement dit, le serveur backend NE DOIT PAS envoyer les éléments suivants dans le cadre d'une réponse 204 No Content ou 205 Reset Content :

1. Corps de la charge utile de la réponse
2. Et l'un des en-têtes suivants :
   1. Content-Length
   2. Content-Encoding
   3. Transfer-Encoding

Spécification

Apigee Edge répond avec 502 Bad Gateway code d'état et le code d'erreur protocol.http.ResponseWithBody si le serveur backend envoie une 204 No Content ou 205 Reset Content réponse, mais ne respecte pas les spécifications RFC suivantes :

Points importants à retenir

La solution recommandée consiste à corriger le serveur backend pour qu'il envoie le code d'état 204 No Content et 205 Reset Content sans corps de réponse et sans aucun des en-têtes (Content-Length, Content-Encoding et Transfer-Encoding), et à respecter les spécifications RFC 7231, section 6.3.5 : 204 No Content (en anglais) et RFC 7231, section 6.3.6 : 205 Reset Content (en anglais).

Si vous avez encore besoin d'aide de la part de l'assistance Apigee, consultez la section Vous devez collecter des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge :

Si vous êtes un utilisateur du cloud public, fournissez les informations suivantes :

• Nom de l'organisation
• Nom de l'environnement
• Nom du proxy d'API
• Commande curl complète utilisée pour reproduire l'erreur 502
• Fichier de trace pour les requêtes API

Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :

• Message d'erreur complet observé pour les requêtes ayant échoué
• Nom de l'environnement
• Bundle de proxy d'API
• Fichier de trace pour les requêtes API

• Journaux d'accès NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Où : ORG, ENV et PORT# sont remplacés par des valeurs réelles.

• Journaux système du processeur de messages /opt/apigee/var/log/edge-message-processor/logs/system.log