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

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 requête HTTP envoyée par le client à Apigee Edge.

Conformément à la section 3.2.2 de la norme RFC 7230 : Field Order (en anglais), un expéditeur ne DOIT PAS générer plusieurs champs d'en-tête portant le même nom 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 trouve un en-tête spécifique, qui n'est pas autorisé à contenir des doublons, plusieurs fois dans la requête HTTP envoyée par le client, il répond avec 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 du cloud public et privé Edge

É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 :

  8. Les informations sur le code d'erreur protocol.http.DuplicateHeader s' affichent comme suit :

  9. Cliquez sur View logs (Afficher les journaux) et développez la ligne de la requête ayant échoué.
  10. Dans la fenêtre Logs (Journaux), notez les informations suivantes :
    1. Code d'état : 400
    2. Source de l'erreur : apigee
    3. Code d'erreur : protocol.http.DuplicateHeader.
  11. Si la source de l'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 du client contenait des en-têtes en double.

Outil Trace

NGINX

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

  1. Si vous êtes un utilisateur du cloud privé, 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 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 dans 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 protocol.http.DuplicateHeader, déterminez la valeur de la source de l'erreur X-Apigee.

    Exemple d'erreur 400 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 le code d'erreur X-Apigee et la source de l'erreur X-Apigee :

    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 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 apigee ou MP, cela indique 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 envoyé plusieurs fois dans 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, alors 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 avez accès à la requête réelle effectuée par l'application cliente, alors 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. Vous pouvez également, si vous avez accès aux journaux du client, vérifier si vous disposez d'informations sur la requête réelle adressée à Apigee Edge et déterminer l'en-tête envoyé plusieurs fois.

Solution

Corriger la duplication

Option 1 [option recommandée] : corriger l'application cliente pour qu'elle n'inclue pas 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, ce n'est pas souhaitable, conformément à la spécification HTTP RFC7230.
  2. Si ce n'est pas souhaitable, modifiez votre application cliente 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 transmettant l' Expires en-tête 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 le souhaitez et que vous voulez 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 du 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 pratique 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 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: 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 400
  • Fichier de trace pour les requêtes API

Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :

  • Message d'erreur complet observé pour les requêtes ayant échoué
  • Nom de l'environnement
  • Bundle de proxy d'API
  • Commande curl complète utilisée pour reproduire l'erreur 400
  • 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