502 Bad Gateway – DuplicateHeader

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente obtient le code d'état HTTP 502 Bad Gateway avec un code d'erreur protocol.http.DuplicateHeader 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

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 vers Apigee Edge.

Conformément à RFC 7230, section 3.2.2: Ordre des champs, un expéditeur NE DOIT PAS générer plusieurs en-têtes des champs ayant le même nom dans un message, sauf si la valeur complète du champ d'en-tête est défini comme une liste d'éléments séparés par une virgule (par exemple, #(values)] ou le champ d'en-tête est un une exception bien connue. Si Apigee Edge détecte un même en-tête spécifique, cela n'est pas autorisé sont envoyés plusieurs fois dans la réponse HTTP envoyée par le serveur cible/backend, puis renvoie 502 Bad Gateway et un code d'erreur protocol.http.DuplicateHeader

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

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 de cloud public et privé

Étapes de diagnostic courantes

Utilisez l'une des techniques ou l'un des outils suivants pour diagnostiquer ce problème:

Surveillance des API

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

Pour diagnostiquer l'erreur à l'aide de l'API Monitoring, procédez comme suit:

  1. <ph type="x-smartling-placeholder"></ph> Connectez-vous à l'interface utilisateur d'Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.

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

  3. Accédez à Analyser > Surveillance des API > Examiner.
  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. Représentez 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 s'affichent comme suit:

    (Agrandir l'image)

  9. Assurez-vous que le code d'état est 502, comme illustré dans l'exemple ci-dessus.
  10. Cliquez sur Afficher les journaux et développez la ligne correspondant à 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 source de la défaillance est target, ce qui indique que la réponse du serveur backend contient des en-têtes en double.

Outil Trace

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

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

  1. Activez la session de trace, puis <ph type="x-smartling-placeholder">
      </ph>
    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 les 502 Bad Gateway erreur

  2. Assurez-vous que l'option Show all Flow Infos (Afficher toutes les informations sur le 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 s'affiche généralement dans un flux après la demande Request sent to target serveur comme indiqué ci-dessous:

    (Agrandir l'image)

  6. Notez la valeur de l'erreur à partir de la trace.

    L'exemple de trace ci-dessus indique l'erreur sous la forme Duplicate Header "Expires". Depuis l'erreur est signalée par Apigee après l'envoi de la requête au serveur backend, cela indique que le serveur backend a envoyé l'en-tête Expires plusieurs fois.

  7. Accédez à la phase AX (Données analytiques enregistrées) dans la trace, puis cliquez dessus.

  8. Faites défiler la page jusqu'à la section Phase Details - Response Headers (Détails de la phase - En-têtes de réponse) et déterminez de X-Apigee-fault-code et 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 due au fait que des en-têtes en double ont été transmis par le serveur backend pour le 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 chaînage de proxy ; c'est-à-dire si le serveur ou le point de terminaison cible appelle un autre proxy dans Apigee.

    1. Pour le déterminer, revenez à la phase Request sent to target server (Demande envoyée au serveur cible). Cliquez sur Show Curl (Afficher le mouvement curl).

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

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

NGINX

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

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX:

  1. Si vous êtes un utilisateur du Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés concernant 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 les valeurs réelles.

  3. Effectuez une recherche pour voir s'il existe des erreurs 502 pendant une durée spécifique (si le problème s'est produit dans le passé) ou si des requêtes échouent encore avec 502

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

    Exemple d'erreur 502 dans le journal d'accès NGINX:

    L'exemple d'entrée ci-dessus du journal des accès NGINX présente 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 d'erreur pour l'erreur observée à l'aide de l'API. Journaux d'accès Monitoring ou NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
  2. Si la source de la défaillance a la valeur target, cela indique que la réponse envoyées 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, consultez à faultstring. faultstring contient le nom de l'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 voir 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 réelle adressée au serveur cible, obtenez la commande curl correspondante Utiliser l'outil Trace à l'étape 10.a et Étape 10.b.

    2. Si vous avez accès à la requête réelle envoyée à l'application du serveur cible, puis effectuez les étapes suivantes:

      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é davantage plusieurs fois. Par conséquent, cette requête échoue avec l'erreur 502 Bad Gateway. et le code d'erreur suivant: protocol.http.DuplicateHeader.

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

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

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

Solution

Corriger les doublons

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

<ph type="x-smartling-placeholder">
  1. Analyser la raison pour laquelle le serveur backend spécifique envoie un en-tête en double Expires et vérifiez si les proxys d'API acceptent cela. Dans dans la plupart des cas, il n'est pas souhaitable, conformément à la spécification HTTP, RFC7230
  2. Si ce n'est pas souhaitable, modifiez votre application de serveur cible pour ne pas envoyer d'en-têtes en double. Dans l'exemple présenté ci-dessus, on remarque que l'en-tête Expires est envoyé deux fois avec la même valeur, ce qui n'est pas souhaitable. Vous pouvez résoudre le problème que le serveur cible ne transmet l'en-tête Expires qu'une seule fois.
  3. Si c'est souhaitable et que vous voulez autoriser les en-têtes en double, accédez à Option 2 : Utilisation de la propriété CwC.

CwC

Option 2 : Utilisation de la propriété CwC

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

Apigee fournit une propriété CwC HTTPHeader.<HeaderName> ,qui permet aux applications clientes et à cibler 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 plusieurs valeurs pour l'en-tête Expires. 

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Si vous êtes un utilisateur du cloud privé, vous pouvez configurer la propriété pour empêcher Apigee Edge ne génère pas une erreur 502 Bad Gateway, même si la requête contient en-têtes en double à l'aide de la méthode <ph type="x-smartling-placeholder"></ph> Guide d'utilisation "Configurer les processeurs de messages pour utiliser des en-têtes en double"
  2. Si vous êtes un utilisateur de cloud public, contactez l'assistance Apigee Edge pour configurer cette pour votre organisation.

Spécification

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

Spécification
<ph type="x-smartling-placeholder"></ph> RFC 7230, section 3.2.2: Ordre des champs
<ph type="x-smartling-placeholder"></ph> RFC 7230, section 3.2: Header Fields

Si vous avez encore besoin de l'aide de l'assistance Apigee, consultez doit 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:

  • Nom de l'organisation
  • Nom de l'environnement
  • Nom du proxy d'API
  • Exécutez la commande curl utilisée pour 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 en échec
  • 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 les valeurs réelles.

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