400 Bad Request - 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 400 Bad Request 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 400 Bad Request

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 requête HTTP envoyée par le client à 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 trouve un en-tête spécifique, celui-ci n'est pas autorisé à avoir les doublons, plus d'une fois dans la requête HTTP envoyée par le client, il répond avec 400 Bad Request 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 requête La requête HTTP envoyée par l'application cliente à Apigee 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 le 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. Vérifiez que le filtre proxy est défini sur Tous. <ph type="x-smartling-placeholder">
  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:

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

    <ph type="x-smartling-placeholder">
  9. Cliquez sur Afficher les journaux et développez la ligne correspondant à la requête ayant échoué.
  10. Dans la fenêtre Journaux, notez les détails suivants: <ph type="x-smartling-placeholder">
      </ph>
    1. Code d'état:400
    2. Source de l'erreur:apigee
    3. Code d'erreur:protocol.http.DuplicateHeader.
  11. Si la Source d'erreur a la valeur apigee ou MP et que le Code d'erreur a la valeur protocol.http.DuplicateHeader, cela indique que la requête HTTP provenant le client contenait des en-têtes en double.

Outil Trace

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

NGINX

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

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

  1. Si vous êtes un utilisateur Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés sur les erreurs HTTP 400.

  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 400 pendant une période spécifique (si les si le problème s'est produit dans le passé) ou si des requêtes échouent encore 400

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

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

    L'exemple d'entrée ci-dessus du journal des 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 MP

Cause: en-tête en double dans la requête

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 apigee ou MP, alors indique que la requête envoyée par l'application cliente à Apigee contient des données en double en-têtes.

  3. Vous pouvez déterminer l'en-tête réel envoyé plusieurs fois dans le cadre de la requête en utilisant 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. faultstring contient le 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 faultstring.

    Demande réelle

    En utilisant la requête réelle

    1. Si vous avez accès à la requête réelle envoyée par l'application cliente, procédez comme suit:

      1. Vérifiez la liste des en-têtes transmis dans la requête.
      2. Si vous constatez qu'un en-tête spécifique apparaît plusieurs fois dans le avec la même ou des valeurs différentes , cela explique pour cette erreur.

      Exemple de requête:

      curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"

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

      <ph type="x-smartling-placeholder">
    2. Si vous avez accès aux journaux du client, vous pouvez également voir si vous avez des informations sur la demande réelle adressée à Apigee Edge et déterminer l'en-tête qui est envoyé plusieurs fois.

Solution

Corriger les doublons

Option 1 [Option recommandée] Corriger l'application cliente pour ne pas inclure les en-têtes en double

<ph type="x-smartling-placeholder">
  1. Analysez la raison pour laquelle le client spécifique envoie un en-tête en double. Par exemple : Expires dans le cas ci-dessus. Vérifier que les serveurs proxy d'API acceptent l'en-tête en double. En général, il n'est pas souhaitable, conformément à la spécification HTTP, RFC7230
  2. Si ce n'est pas souhaitable, modifiez votre application cliente 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 en transmettant Expires une seule fois, comme indiqué ci-dessous:

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
  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 un CwC HTTPHeader.<HeaderName> ,qui permet au client applications et serveurs cibles pour 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 Private Cloud, vous pouvez configurer la propriété pour empêcher Apigee Edge de générer une erreur 400 Bad Request, même si la demande contient des en-têtes en double utilisant 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 propriété. pour votre organisation.

Spécification

Apigee s'attend à ce que l'application cliente n'envoie pas d'en-têtes en double dans le cadre de la requête. 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" (Champs d'en-tête)

Si vous avez encore besoin de l'aide de l'assistance Apigee, accédez à Obligation de 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 400.
  • 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
  • Exécutez la commande curl que vous avez utilisée pour reproduire l'erreur 400.
  • 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