502 Bad Gateway – DuplicateHeader

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.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

Vous pouvez également observer un message d'erreur semblable à celui présenté ci-dessous : 

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

Causes possibles :

Cette erreur se produit si un en-tête HTTP spécifique non autorisé à contenir 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 : Field Order (en anglais) de la RFC 7230, un émetteur 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 de champ entière de ce champ d'en-tête est définie comme une liste de valeurs séparées par une virgule, c'est-à-dire #(values), ou si le champ d'en-tête est une exception bien connue. Si Apigee Edge constate qu'un même en-tête spécifique, qui n'est pas autorisé à contenir des doublons, est envoyé plusieurs fois dans la réponse HTTP envoyée par le serveur cible/backend, il répond avec 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 d'Edge Cloud public et privé

Étapes de diagnostic courantes

Utilisez l'un des outils/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 d'un rôle approprié.

  2. Basculez vers l'organisation dans laquelle vous souhaitez examiner le problème.

  3. Accédez à la page Analyze > API Monitoring > Investigate (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 All (Tous).
  6. Tracez le code d'erreur par rapport au temps.

  7. Sélectionnez une cellule contenant le code d'erreur protocol.http.DuplicateHeader, comme illustré 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 View logs (Afficher les journaux) et développez la ligne de la requête ayant échoué.

  11. Dans la fenêtre "Logs" (Journaux), notez les détails suivants :

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

Outil Trace

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

  1. Activez la session de trace et
    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' 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 identifiez l'endroit où l'échec s'est produit.

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

    (Agrandir l'image)

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

    L'exemple de trace ci-dessus indique l'erreur 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 le serveur backend a envoyé l'en-tête Expires plusieurs fois.

  7. Accédez à la phase AX (Analytics Data Recorded, Données d'analyse enregistrées) de 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 les valeurs de X-Apigee-fault-code et X-Apigee-fault-source , comme illustré ci-dessous :

    (Agrandir l'image)

  9. Les valeurs de X-Apigee-fault-code et X-Apigee-fault-source sont protocol.http.DuplicateHeader et target, ce qui indique que cette erreur est due au 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 le chaînage de proxy ; c'est-à-dire si le serveur cible ou le point de terminaison cible appelle un autre proxy dans Apigee.

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

    2. La fenêtre Curl for Request Sent to Target Server (Curl pour la requête envoyée au serveur cible) s'ouvre. Vous pouvez y déterminer l'alias d'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 chaîné jusqu'à ce que vous déterminiez la cause réelle de l'erreur 502 Bad Gateway.
    4. Si l'alias d'hôte du serveur cible pointe vers votre serveur backend, cela indique que votre serveur backend 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 :

  1. Si vous êtes un utilisateur de Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés 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 dans 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 protocol.http.DuplicateHeader, alors déterminez la valeur de X-Apigee-fault-source.

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

    L'entrée d'exemple ci-dessus du journal d'accès NGINX comporte 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 pour l'erreur observée à l'aide de la surveillance des API ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
  2. Si la source de l'erreur a la valeur target, cela indique 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

    Utiliser le message d'erreur :

    1. Si vous avez accès au message d'erreur complet reçu d'Apigee Edge, reportez-vous à faultstring. Le 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 indiqué dans le faultstring.

    Requête réelle

    Utiliser 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 à l'étape 10.a et à l'étape 10.b de la section Utiliser l'outil Trace.

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

      1. Effectuez un appel au 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é plus de fois. Par conséquent, cette requête échoue avec l'502 Bad Gateway erreur et le code d'erreur protocol.http.DuplicateHeader.

      3. Si l'en-tête dont le nom apparaît dans le 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.

Solution

Corriger la duplication

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 en double Expires et vérifiez si les proxys d'API peuvent l'accepter. Dans la plupart des cas, cela ne sera pas souhaitable conformément à la spécification HTTP RFC7230.
  2. Si ce n'est pas souhaitable, modifiez l'application de votre serveur cible pour qu'elle n'envoie pas d'en-têtes en double. Dans l'exemple ci-dessus, nous constatons 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 en vous assurant que le serveur cible ne transmet l'en-tête Expires qu'une seule fois.
  3. Si cela est souhaitable et que vous souhaitez autoriser les en-têtes en double, passez à l'option 2 : Utiliser la propriété CwC.

CwC

Option 2 : Utiliser la propriété CwC

Apigee provides a CwC property 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 d'utilisation Configurer les 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 pour configurer cette propriété pour votre organisation.

Spécification

Apigee répond avec l'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: Field Order (en anglais)
RFC 7230, section 3.2: Header Fields (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 de Private Cloud, 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