Erreur interne du serveur 500 – BadFormData

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Problème constaté

L'application cliente reçoit un code d'état HTTP 500 Internal Server Error avec le code d'erreur protocol.http.BadFormData en 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'examiner en détail comment résoudre 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 comportant des éléments tels qu'une zone de saisie de texte, un bouton ou une case à cocher. Les données du formulaire sont généralement envoyées sous la forme d'une série de paires clé/valeur dans les requêtes ou réponses HTTP.

Transmission des données de formulaire

1. Content-Type: application/x-www-form-urlencoded
   • Si la taille des données du formulaire est petite, les données sont envoyées sous forme de paires clé/valeur avec :
     • Les caractères des deux clés sont 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 pourcentage (%) est autorisé dans les données du 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 pourcentage (%) dans la clé ou la valeur, elles doivent être transmises sous la forme %25, , qui représente le code ASCII du caractère signe 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 les 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 (en anglais).

2. Le proxy d'API dans Apigee Edge lit les paramètres de formulaire spécifiques contenant des caractères non autorisés à utiliser dans le flux de requête à l'aide de la règle ExtractVariables ou AssignMessage.

   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 du formulaire dans la demande contiennent des caractères non autorisés	Les paramètres de formulaire transmis dans la requête HTTP par le client contiennent des caractères non autorisés.	Utilisateurs du cloud public et privé Edge

Étapes de diagnostic courantes

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

Cause : Les paramètres de formulaire de la requête contiennent des caractères non autorisés.

Diagnostic

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

      Exemple 1

      Exemple 1 : règle ExtractVariables extrayant les paramètres du 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 de 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 par le client à Apigee Edge contiennent des caractères non autorisés.

      Exemple 2

      Exemple 2 : Règle AssignMessage copiant les paramètres du formulaire :

            <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 de 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 par le client à Apigee Edge contiennent des caractères non autorisés.

4. Vérifiez si des caractères non autorisés sont utilisés dans les paramètres de formulaire identifiés à l'étape 3, en utilisant l'une des méthodes suivantes :

   Outil Trace

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

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

      2. Faites défiler la page jusqu'à la section Détails de la phase et examinez le contenu de la demande.

         ( Agrandir l'image)

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

   Demande réelle

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

   1. Si vous n'avez pas accès à la requête réelle envoyée au serveur cible, passez à Résolution.
   2. Si vous avez accès à la requête 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, 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 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 pourcentage (%) suivi des caractères hexadécimaux non valides ZY.

         Exemple 2

         Exemple de demande 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 de 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 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 de la requête HTTP à Apigee Edge contiennent des caractères non autorisés.
   4. Par conséquent, Apigee Edge répond avec 500 Internal Server Error et le code d'erreur protocol.http.BadFormData.

Solution

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

   Exemple 1

   Exemple 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 demande 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 de form_data.xml :

   Utilisez l' encodage en pourcentage pour le signe pourcentage (%), c'est-à-dire modifiez le fichier pour qu'il contienne %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 du formulaire soient envoyées conformément aux spécifications suivantes :

Si vous avez encore besoin d'aide de l'assistance Apigee, consultez la page Vous devez collecter 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 du cloud public, fournissez les informations suivantes :

• Nom de l'organisation
• Nom de l'environnement
• Nom de proxy d'API
• Commande curl complète utilisée pour reproduire 500 Internal Server Error avec le code d'erreur protocol.http.BadFormData
• 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
• 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

Références

• Types de contenu du formulaire
• RFC3986, section 2.1: Percent encoding (en anglais)
• Encodage en pourcentage
• Caractères hexadécimaux