Erreur interne du serveur 500 – BadFormData

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

L'application cliente obtient un code d'état HTTP 500 Internal Server Error avec le code d'erreur protocol.http.BadFormData comme réponse aux appels d'API.

Message d'erreur

L'application cliente reçoit le code de réponse suivant:

HTTP/1.1 500 Internal Server Error

De plus, le message d'erreur suivant peut s'afficher:

{
   "fault":{
      "faultstring":"Bad Form Data",
      "detail":{
         "errorcode":"protocol.http.BadFormData"
      }
   }
}

Données de formulaire

Avant d'entrer dans les détails de la résolution de ce problème, voyons ce que sont les données de formulaire.

Les données de formulaire sont les informations fournies par l'utilisateur, généralement via un formulaire HTML, avec des éléments tels qu'une zone de saisie de texte, un bouton ou une case à cocher. Les données de formulaire sont généralement envoyées sous la forme d'une série de paires clé/valeur dans le cadre de requêtes ou de réponses HTTP.

Transmission de données de formulaire

1. Content-Type: application/x-www-form-urlcoded
   • Si les données du formulaire sont de petite taille, elles sont envoyées sous forme de paires clé/valeur avec :
     • Caractères des deux clés encodés conformément aux règles expliquées dans Forms – Section 17.13.4.1
     • En-tête Content-Type: application/x-www-form-urlencoded

     Exemple de requête avec des données de formulaire:

     curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
     

   • Tous les caractères non alphanumériques des clés et des valeurs sont encodés en pourcentage, c'est-à-dire qu'ils sont représentés par un triplet de caractères %HH, composé d'un signe de pourcentage suivi de deux chiffres hexadécimaux représentant le code ASCII du caractère spécifique.
   • Ainsi, même si le signe de pourcentage (%) est autorisé dans les données de formulaire, il est interprété comme le début d'une séquence d'échappement spéciale. Par conséquent, si les données du formulaire doivent contenir le signe de pourcentage (%) dans la clé ou la valeur, elles doivent être transmises sous la forme %25, , qui représente le code ASCII du signe de pourcentage (%).
2. Content-Type: multipart/form-data

   Si vous souhaitez transmettre de grandes quantités de données binaires ou de texte contenant des caractères non ASCII, vous pouvez envoyer ces données avec Content-Type: multipart/form-data, comme expliqué dans Forms – Section 17.13.4.2.

Causes possibles

Cette erreur se produit si et seulement si toutes les conditions suivantes sont remplies :

1. La requête HTTP envoyée par le client à Apigee Edge contient :
   1. Content-Type: application/x-www-form-urlencoded et
   2. Données de formulaire avec le signe de pourcentage (%) ou le signe de pourcentage (%) suivi de caractères hexadécimaux non valides qui ne sont pas autorisés conformément à Forms – Section 17.13.4.1

2. Le proxy d'API dans Apigee Edge lit les paramètres de formulaire spécifiques contenant des caractères qui ne sont pas autorisés à être utilisés dans le flux de requêtes à l'aide de ExtractVariables ou de la stratégie AffectMessage.

   Par exemple, si les données du formulaire contiennent le signe de pourcentage (%) tel quel (sans encodage) ou le signe de pourcentage (%) suivi de caractères hexadécimaux non valides dans la clé et/ou la valeur, cette erreur s'affiche.

   Voici les causes possibles de cette erreur:

   Cause	Description	Instructions de dépannage applicables
   Les paramètres de formulaire de la requête contiennent des caractères non autorisés	Les paramètres de formulaire transmis par le client dans le cadre de la requête HTTP contiennent des caractères non autorisés à être utilisés.	Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

Utilisez l'un des outils ou techniques suivants pour diagnostiquer cette erreur:

Cause: les paramètres de formulaire de la demande comportent des caractères non autorisés

Diagnostic

1. Déterminez le code d'erreur, la source des erreurs et les règles d'erreur pour 500 Internal Server Error à l'aide de la surveillance des API, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
2. Si le code d'erreur est protocol.http.BadFormData, Fault Source a la valeur proxy ou policy, et que Fault Policy n'est pas vide, cela signifie que la stratégie spécifiée dans Fault Policy a échoué lors de la lecture ou de l'extraction des données de formulaire (paramètres de formulaire).
3. Examinez la stratégie indiquée dans la politique de défaillance et déterminez les informations suivantes :
   1. Source:déterminez si la stratégie lit ou extrait les données d'une requête ou d'une réponse.
   2. Paramètres de formulaire:déterminez les paramètres de formulaire spécifiques qui sont lus dans la règle.

      Exemple 1

      Exemple n° 1: règle ExtractVariables extrait les paramètres de formulaire:

            <ExtractVariables name="EV-ExtractFormParms">
               <DisplayName>EV-ExtractFormParams</DisplayName>
               <Source>request</Source>
               <FormParam name="username">
                  <Pattern ignoreCase="false">{username}</Pattern>
               </FormParam>
               <FormParam name="password">
                 <Pattern ignoreCase="false">{password}</Pattern>
               </FormParam>
               <VariablePrefix>forminfo</VariablePrefix>
             <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            </ExtractVariables>
            

      Dans la règle ExtractVariables ci-dessus:

      • Source: request

        Cela est indiqué par l'élément <Source>.

      • Paramètres du formulaire:username et password

        Cela est indiqué par l'élément <Pattern> dans l'élément <FormParam>.

      Cela indique que les paramètres de formulaire username et/ou password transmis dans le cadre de la requête HTTP du client à Apigee Edge contiennent des caractères non autorisés à être utilisés.

      Exemple 2

      Exemple n° 2: Copie des paramètres de formulaire de la règleAssignMessage:

            <AssignMessage continueOnError="false" enabled="true" name="AM-CopyFormParams">
              <Copy source="request">
                <FormParams>
                  <FormParam name="username"/>
                  <FormParam name="password"/>
                </FormParams>
              </Copy>
              <AssignTo createNew="true" transport="http" type="request"/>
            </AssignMessage>
            

      Dans la règle ExtractVariables ci-dessus:

      • Source : request

        Cela est indiqué par l'attribut source dans l'élément <Copy>.

      • Paramètres du formulaire:username et password

        Cela est indiqué par l'attribut name dans l'élément <FormParam>.

      Cela indique que les paramètres de formulaire username ou password, ou les deux, transmis dans le cadre de la requête HTTP du client à Apigee Edge contiennent des caractères non autorisés à être utilisés.

4. Vérifiez si des caractères ne sont pas autorisés à utiliser des caractères dans les paramètres de formulaire identifiés à l'étape 3 à l'aide de l'une des méthodes suivantes:

   Outil de traçage

   Pour valider à l'aide de l'outil Trace:

   1. Si vous avez capturé la trace de la requête ayant échoué, comme expliqué dans la section Étapes de diagnostic courantes, sélectionnez l'une des requêtes ayant échoué.
   2. Si vous avez déterminé que les paramètres de formulaire contenant des caractères non autorisés à être utilisés font partie de la requête HTTP à l'étape 3 ci-dessus, alors
      1. Accédez à la phase Request Received from Client (Demande reçue du client).

      2. Faites défiler la page jusqu'à la section Phase Details (Détails de la phase) et consultez la section Request Content (Contenu de la demande).

         ( Afficher l'image plus grande)

         
      3. Dans l'exemple ci-dessus, notez que le paramètre de formulaire password contient le signe de pourcentage (%).
      4. Étant donné que le signe de pourcentage (%) est également utilisé pour encoder le pourcentage des caractères spéciaux, il ne peut pas être utilisé tel quel dans les données de formulaire.
      5. Par conséquent, Apigee Edge répond par 500 Internal Server Error avec le code d'erreur protocol.http.BadFormData.

   Demande réelle

   Pour valider à l'aide de la requête réelle:

   1. Si vous n'avez pas accès à la demande réelle envoyée au serveur cible, accédez à Résolution.
   2. Si vous avez accès à la demande réelle envoyée à Apigee Edge, procédez comme suit :
      1. Examinez le contenu des données du formulaire et vérifiez s'il contient des caractères non autorisés à être utilisés, tels que le signe de pourcentage (%) ou le signe de pourcentage (%), suivi de caractères hexadécimaux non valides.

         Exemple 1

         Exemple de requête n° 1: Données de formulaire incluses dans la requête

         curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%ZY"
         

         Dans cet exemple, notez que l'élément client_secret contient le signe de pourcentage (%) suivi de caractères hexadécimaux non valides ZY.

         Exemple 2

         Exemple de requête n° 2 : Données de formulaire transmises dans un fichier

         curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
         

         Contenu du fichier form_data.xml:

         xml=<user><username>abc1234@google.com</username><password>qwerty12345!@#$%</password></user>
         

         Dans cet exemple, notez que l'élément password contient le signe de pourcentage (%), qui ne doit pas être transmis tel quel dans les données du formulaire.

   3. Dans les deux exemples ci-dessus, les données de formulaire envoyées dans le cadre d'une requête HTTP à Apigee Edge contiennent des caractères qui ne sont pas autorisés à être utilisés.
   4. Par conséquent, Apigee Edge répond par 500 Internal Server Error avec le code d'erreur protocol.http.BadFormData.

Résolution

1. Assurez-vous que tous les caractères spéciaux contenus dans les clés et les valeurs des données de formulaire ou des paramètres envoyés dans le cadre d'une requête HTTP par le client sont toujours encodés comme expliqué dans la section Données de formulaire - application/x-www-form-urlcoded.
2. Pour les exemples abordés ci-dessus, vous pouvez résoudre les problèmes comme suit:

   Exemple 1

   Exemple n° 1 : Données de formulaire transmises dans la requête

   Utilisez des caractères hexadécimaux valides correspondant au code ASCII d'un caractère spécifique. Par exemple, si vous souhaitez envoyer le signe dollar ($), utilisez %24 comme indiqué ci-dessous:

   curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%24"
   

   Exemple 2

   Exemple de requête n° 2 : Données de formulaire transmises dans un fichier

   curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
   

   Contenu du fichier form_data.xml:

   Utilisez l' encodage de pourcentage pour le signe de pourcentage (%), c'est-à-dire modifiez le fichier pour qu'il affiche %25 , comme indiqué ci-dessous :

   xml=<user><username>abc1234@google.com</username><password>qwerty12345!!@#$%25</password></user>
   

Spécification

Apigee Edge s'attend à ce que les données de formulaire soient envoyées conformément aux spécifications suivantes:

Spécification
Données de formulaire : application/x-www-form-urlcoded

Si vous avez encore besoin de l'aide de l'assistance Apigee, consultez la section Vous devez recueillir des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste même après avoir suivi les instructions ci-dessus, 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 de proxy d'API
• Terminez la commande curl permettant de reproduire le 500 Internal Server Error avec le code d'erreur protocol.http.BadFormData.
• 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
• 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

Références

• Types de contenu de formulaire
• RFC 3986, section 2.1: encodage en pourcentage
• Codage en pourcentage
• Caractères hexadécimaux