400 Bad Request - 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 400 Bad Request 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 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 à 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 trouve un en-tête spécifique qui n'est pas autorisé à avoir des doublons, plusieurs fois dans la requête HTTP envoyée par le client, il répond par 400 Bad Request 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 requête La requête HTTP de l'application cliente à Apigee 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 d'un 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 All (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:

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

  9. Cliquez sur Afficher les journaux, puis développez la ligne de la requête ayant échoué.
  10. Dans la fenêtre Journaux, notez les détails suivants :
    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 si le code d'erreur a la valeur protocol.http.DuplicateHeader, cela signifie que la requête HTTP du client contenait des en-têtes en double.

Outil de traçage

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 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 des valeurs réelles.

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

  4. Si vous trouvez des erreurs 400 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 400 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 MP

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

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 Fault Source a la valeur apigee ou MP, cela signifie que la requête envoyée par l'application cliente à Apigee contient des en-têtes en double.

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

    Demande réelle

    Utiliser 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 particulier apparaît plusieurs fois dans la requête avec la même valeur ou des valeurs différentes , c'est la cause de 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é plusieurs fois. Par conséquent, cette requête échoue avec l'erreur 400 Bad Request et le code d'erreur: protocol.http.DuplicateHeader.

    2. Si vous avez accès aux journaux client, vous pouvez également vérifier si vous disposez d'informations sur la requête réelle faite à Apigee Edge et déterminer l'en-tête qui est envoyé plusieurs fois.

Résolution

Corriger les doublons

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

  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érifiez que les proxys d'API peuvent accepter l'en-tête en double. En règle générale, 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 cliente pour ne pas envoyer 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. Vous pouvez résoudre le problème en transmettant l'en-tête 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 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 400 Bad Request, 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 s'attend à ce que l'application cliente n'envoie pas d'en-têtes en double dans la requête, 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 d'aide de l'assistance Apigee, consultez la section 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 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 ayant échoué
  • 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 des valeurs réelles.

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