502 Bad Gateway – DuplicateHeader

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

En réponse aux appels d'API, l'application cliente reçoit un code d'état HTTP 502 Bad Gateway avec le code d'erreur protocol.http.DuplicateHeader .

Message d'erreur

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

HTTP/1.1 502 Bad Gateway

En outre, un message d'erreur semblable à celui présenté ci-dessous peut s'afficher: 

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

Causes possibles :

Cette erreur se produit si un en-tête HTTP spécifique qui n'est pas autorisé à avoir des doublons dans Apigee Edge apparaît plusieurs fois avec des valeurs identiques ou différentes, dans la réponse HTTP envoyée par le serveur backend à Apigee Edge.

Conformément à la section 3.2.2 de la norme RFC 7230 sur l'ordre des champs , un expéditeur NE DOIT PAS générer plusieurs champs d'en-tête avec le même nom de champ dans un message, sauf si la valeur entière de ce champ d'en-tête est définie sous la forme d'une liste d'éléments séparés par une virgule, #(values)] ou le champ d'en-tête est une exception bien connue. Si Apigee Edge détecte qu'un même en-tête spécifique, qui n'est pas autorisé à avoir des doublons, est envoyé plusieurs fois dans la réponse HTTP envoyée par le serveur cible/backend, il répond par 502 Bad Gateway et le code d'erreur protocol.http.DuplicateHeader.

Voici les causes possibles de cette erreur:

Cause Description Instructions de dépannage applicables
En-tête en double dans la réponse La réponse du serveur backend contient des en-têtes en double. Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

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

Surveillance des API

Pour diagnostiquer l'erreur à l'aide de la surveillance des API:

  1. Connectez-vous à l'interface utilisateur Apigee Edge en tant qu'utilisateur disposant du rôle approprié.

  2. Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.

  3. Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Enquêter).
  4. Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.
  5. Assurez-vous que le filtre Proxy est défini sur Tous.
  6. Tracez le code d'erreur par rapport à l'heure.

  7. Sélectionnez une cellule avec le code d'erreur protocol.http.DuplicateHeader, comme indiqué ci-dessous:

    (Agrandir l'image)

  8. Les informations sur le code d'erreur protocol.http.DuplicateHeader sont affichées comme indiqué ci-dessous:

    (Agrandir l'image)

  9. Assurez-vous que le code d'état est 502, comme indiqué dans l'exemple ci-dessus.
  10. Cliquez sur Afficher les journaux, puis développez la ligne de la requête ayant échoué.

  11. Dans la fenêtre "Journaux", notez les informations suivantes:

    • Code d'état:502
    • Source de l'erreur: target
    • Code d'erreur:protocol.http.DuplicateHeader.
  12. La valeur Fault Source (Source d'erreur) est target, ce qui indique que la réponse du serveur backend contenait des en-têtes en double.

Outil de traçage

Pour diagnostiquer l'erreur à l'aide de l'outil Trace:

  1. Activez la session de trace, puis effectuez l'une des opérations suivantes :
    1. Attendez que l'erreur 502 Bad Gateway se produise ou
    2. Si vous pouvez reproduire le problème, effectuez l'appel d'API et reproduisez l'erreur 502 Bad Gateway.

  2. Assurez-vous que l'option Show all Flow Infos (Afficher tous les détails du flux) est activée:

  3. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
  4. Parcourez les différentes phases de la trace et localisez l'origine de l'échec.

  5. L'erreur apparaît généralement dans un flux après la phase Request sent to target server (Requête envoyée au serveur cible), comme indiqué ci-dessous:

    (Agrandir l'image)

  6. Notez la valeur de l'erreur dans la trace.

    L'exemple de trace ci-dessus affiche l'erreur sous la forme Duplicate Header "Expires". Étant donné que l'erreur est générée par Apigee après l'envoi de la requête au serveur backend, cela indique que celui-ci a envoyé l'en-tête Expires plusieurs fois.

  7. Dans la trace, accédez à la phase AX (Données analytiques enregistrées) et cliquez dessus.

  8. Faites défiler la page vers le bas jusqu'à la section Phase Details - Response Headers (Détails de la phase – En-têtes de réponse) et déterminez les valeurs de X-Apigee-fault-code et de X-Apigee-fault-source, comme indiqué ci-dessous:

    (Agrandir l'image)

  9. Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source comme protocol.http.DuplicateHeader et target, ce qui indique que cette erreur est causée par le fait que le serveur backend a transmis des en-têtes en double pour l'en-tête de réponse Expires.
    En-têtes de réponse Valeur
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source target

  10. Vérifiez si vous utilisez un chaînage de proxy, c'est-à-dire si le serveur ou le point de terminaison cible appelle un autre proxy dans Apigee.

    1. Pour déterminer cela, revenez à la phase Request sent to target (Requête envoyée au serveur cible). Cliquez sur Show Curl (Afficher le bouclage).

    2. La fenêtre Curl for Request Sent to Target Server (Curl de la requête envoyée au serveur cible) s'ouvre. Elle vous permet de déterminer l'alias de l'hôte du serveur cible.

    3. Si l'alias d'hôte du serveur cible pointe vers un alias d'hôte virtuel, il s'agit d'un chaînage de proxy. Dans ce cas, vous devez répéter toutes les étapes ci-dessus pour le proxy en chaîne jusqu'à ce que vous déterminiez la cause de l'erreur 502 Bad Gateway.
    4. Si l'alias d'hôte du serveur cible pointe vers votre serveur backend, cela signifie que celui-ci envoie les en-têtes en double dans la réponse à Apigee.

NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX, procédez comme suit:

  1. Si vous êtes un utilisateur du cloud privé, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations essentielles sur les erreurs HTTP 502.

  2. Vérifiez les 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.

  3. Recherchez s'il existe des erreurs 502 pendant une durée spécifique (si le problème s'est produit par le passé) ou si des requêtes échouent toujours avec 502.

  4. Si vous trouvez des erreurs 502 avec le X-Apigee-fault-code correspondant à la valeur de X-Apigee-fault-code , déterminez la valeur de la source X-Apigee-fault-code .

    Exemple d'erreur 502 du journal d'accès NGINX:

    L'exemple d'entrée ci-dessus du journal d'accès NGINX contient les valeurs suivantes pour X-Apigee-fault-code et X-Apigee-fault-source :

    En-têtes de réponse Valeur
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source target

Cause: en-tête en double dans la réponse

Diagnostic

  1. Déterminez le code d'erreur et la source de l'erreur de l'erreur observée à l'aide de l'API Monitoring ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
  2. Si la valeur Fault Source est définie sur target, cela signifie que la réponse envoyée par le serveur cible contient des en-têtes en double.

  3. Vous pouvez déterminer l'en-tête réel envoyé plusieurs fois dans la réponse à l'aide de l'une des méthodes suivantes:

    Message d'erreur

    Utilisation du message d'erreur:

    1. Si vous avez accès au message d'erreur complet reçu d'Apigee Edge, reportez-vous au faultstring. faultstring contient le nom d'en-tête qui a été envoyé plusieurs fois.

      Exemple de message d'erreur:

      "faultstring":"Duplicate Header \"Expires\""
    2. Dans le message d'erreur ci-dessus, vous pouvez constater que l'en-tête Expires est envoyé plusieurs fois, comme dans faultstring.

    Demande réelle

    Avec la requête réelle:

    1. Si vous n'avez pas accès à la requête envoyée au serveur cible, obtenez la commande curl correspondante des étapes 10.a et 10.b de la section Utiliser l'outil Trace.

    2. Si vous avez accès à la requête envoyée à l'application du serveur cible, procédez comme suit:

      1. Appelez le serveur cible.

        Exemple de requête pour le serveur cible utilisé dans cet exemple:

        curl -X GET "https://BACKEND_SERVER_HOST/response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT" -v

      2. Vérifiez la liste des en-têtes affichés dans la réponse.

        Exemple de réponse du serveur cible utilisé dans cet exemple:

        * ...Trimmed...
> GET /response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT HTTP/2
> Host: BACKEND_SERVER_HOST
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Fri, 02 Jul 2021 05:29:07 GMT
< content-type: application/json
< content-length: 166
< server: gunicorn/19.9.0
< Expires: Mon, 21 June 2021 07:28:00 GMT
< Expires: Mon, 21 June 2021 07:28:00 GMT
< access-control-allow-origin: *
< access-control-allow-credentials: true
<
----<Response BODY>------
* Connection #0 to host httpbin.org left intact
* Closing connection 0

        Dans l'exemple de requête ci-dessus, l'en-tête Expires est envoyé plusieurs fois. Par conséquent, cette requête échoue avec l'erreur 502 Bad Gateway et le code d'erreur: protocol.http.DuplicateHeader.

      3. Si l'en-tête dont le nom apparaît dans faultstring apparaît plusieurs fois dans la réponse du serveur backend, c'est la cause de cette erreur. Dans le cas ci-dessus, l'en-tête Expires est envoyé plusieurs fois.

Résolution

Corriger les doublons

Option 1 [Option recommandée] Corrigez le serveur backend pour qu'il n'inclue pas d'en-têtes en double

  1. Analysez la raison pour laquelle le serveur backend spécifique envoie l'en-tête Expires en double et vérifiez si les proxys d'API acceptent cet en-tête. Dans la plupart des cas, elle n'est pas souhaitable conformément à la spécification HTTP RFC7230.
  2. Si ce n'est pas ce que vous souhaitez, modifiez votre application de serveur cible pour qu'elle n'envoie pas d'en-têtes en double. Dans l'exemple décrit ci-dessus, on constate que l'en-tête Expires est envoyé deux fois avec la même valeur, ce qui n'est pas souhaitable. Pour résoudre le problème, assurez-vous que le serveur cible ne transmet l'en-tête Expires qu'une seule fois.
  3. Si vous souhaitez autoriser les en-têtes en double, accédez à Option 2 : Utiliser la propriété CwC.

CwC

Option 2 avec la propriété CwC

Apigee fournit une propriété CwC HTTPHeader.<HeaderName> ,qui permet aux applications clientes et aux serveurs cibles d'envoyer des en-têtes en double aux proxys d'API dans Apigee Edge.

Propriété CwC Valeurs
HTTPHeader.<HeaderName> allowDuplicates,multivalued

Par exemple, la propriété suivante peut être définie sur les processeurs de messages pour autoriser les doublons et les valeurs multiples pour l'en-tête Expires. 

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Si vous êtes un utilisateur de cloud privé, vous pouvez configurer la propriété pour empêcher Apigee Edge de générer une erreur 502 Bad Gateway, même si la requête contient des en-têtes en double, à l'aide du guide Configurer des processeurs de messages pour utiliser des en-têtes en double.
  2. Si vous êtes un utilisateur du cloud public, contactez l'assistance Apigee Edge afin de configurer cette propriété pour votre organisation.

Spécification

Apigee renvoie la réponse d'erreur 502 Bad Gateway, car il s'attend à ce que le serveur backend se comporte conformément aux spécifications RFC suivantes:

Spécification
RFC 7230, section 3.2.2: ordre des champs
RFC 7230, section 3.2: champs d'en-tête

Si vous avez encore besoin de l'aide de l'assistance Apigee, consultez Vous devez recueillir 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 de cloud public, fournissez les informations suivantes:

  • Le nom de l'organisation.
  • Nom de l'environnement
  • Nom du proxy d'API
  • Complétez la commande curl permettant de reproduire l'erreur 502.
  • Fichier de suivi des requêtes API

Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:

  • Message d'erreur complet observé pour les requêtes ayant échoué
  • Nom de l'environnement
  • Groupe de proxys d'API
  • Fichier de suivi des 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