Erreur interne du serveur 500 – BadFormData

<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 reçoit 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

Le message d'erreur suivant peut également s'afficher:

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

Données de formulaire

Avant d'entrer dans les détails du dépannage de ce problème, examinons 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 comme 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 dans les requêtes ou réponses HTTP.

Transmission de données de formulaire

1. Content-Type: application/x-www-form-urlEncoding <ph type="x-smartling-placeholder">
   </ph>
   • Si les données du formulaire sont de petite taille, elles sont envoyées sous forme de paires clé-valeur avec: <ph type="x-smartling-placeholder">
     </ph>
     • Les caractères des deux clés sont encodés conformément aux règles expliquées dans <ph type="x-smartling-placeholder"></ph> Forms – Section 17.13.4.1
     • L'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 <ph type="x-smartling-placeholder"></ph> codés selon un 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ée comme le début d'une séquence d'échappement spéciale. Par conséquent, si les données du formulaire doivent contiennent le signe de pourcentage (%) dans la clé ou la valeur, il doit être transmis %25, , qui représente le code ASCII pour le signe de pourcentage (%).
2. Content-Type (Type de contenu) : multipart/form-data

   Si vous souhaitez transmettre de grandes quantités de données binaires ou du texte contenant des caractères non-ASCII vous pouvez envoyer les données avec Content-Type: multipart/form-data, comme expliqué dans <ph type="x-smartling-placeholder"></ph> 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: <ph type="x-smartling-placeholder">
   </ph>
   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 non autorisés <ph type="x-smartling-placeholder"></ph> 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 peuvent pas être utilisés dans le flux de requêtes à l'aide des variables ExtractVariables ou Règle "AssignMessage".

   Par exemple, si les données du formulaire contiennent le signe de pourcentage (%) tel quel (sans ou le signe pourcentage (%) suivi de toute valeur hexadécimale incorrecte dans la clé et/ou la valeur, vous obtenez cette erreur.

   Voici les causes possibles de cette erreur:

   Cause	Description	Instructions de dépannage applicables
   Les paramètres de formulaire de la demande comportent des caractères non autorisés	Les paramètres du formulaire transmis dans le cadre de la requête HTTP par le client contiennent caractères dont l'utilisation n'est pas autorisée.	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:

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

Diagnostic

1. Déterminez le code d'erreur, la source d'erreur et la stratégie 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 les étapes de diagnostic courantes.
2. Si le code d'erreur est protocol.http.BadFormData, la source d'erreur a la valeur proxy ou policy, et la stratégie d'erreur n'est pas vide, cela indique que la stratégie spécifiée dans la stratégie d'erreur a échoué alors que lire ou extraire les données du formulaire (paramètres de formulaire).
3. Examinez la règle indiquée dans le règlement d'erreur et déterminez les éléments suivants informations: <ph type="x-smartling-placeholder">
   </ph>
   1. Source:déterminez si la stratégie lit ou extrait les données requête ou réponse.
   2. Paramètres de formulaire:déterminez les paramètres spécifiques du formulaire qui sont lus dans le .

      Exemple 1

      Exemple n° 1 : La règle ExtractVariables extrait 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

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

      • Paramètres du formulaire:username et password

        Ceci est indiqué par l'élément <Pattern> dans Élément <FormParam>

      Cela indique que les paramètres de formulaire username et/ou password transmis dans la requête HTTP par le client à Apigee Edge contient des caractères dont l'utilisation est non autorisée.

      Exemple 2

      Exemple n° 2: Paramètres du formulaire de copie de la règle assignMessage:

            <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ément <Copy>

      • Paramètres du formulaire:username et password

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

      Cela indique que les paramètres de formulaire username, password ou transmis dans le cadre de la requête HTTP par le client à Apigee Edge contient caractères dont l'utilisation n'est pas autorisée.

4. Vérifiez que certains caractères ne sont pas autorisés caractères utilisés dans les paramètres de formulaire identifiés à l'étape 3 à l'aide de 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 en échec, comme expliqué dans Étapes de diagnostic courantes, puis sélectionnez l'une des en échec.
   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 dans à l'étape 3 ci-dessus, <ph type="x-smartling-placeholder">
      </ph>
      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 examinez les Demander des contenus.

         ( Agrandir l'image)

         
      3. Dans l'exemple ci-dessus, notez que le paramètre de formulaire password contient le signe de pourcentage (%).
      4. Comme le signe de pourcentage (%) est également utilisé pour <ph type="x-smartling-placeholder"></ph> l'encodage "%" 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 par le code d'erreur protocol.http.BadFormData

   Demande réelle

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

   1. Si vous n'avez pas accès à la requête réelle adressée au serveur cible, puis accédez à Resolution (Résolution).
   2. Si vous avez accès à la requête réelle envoyée à Apigee Edge, effectuez procédez comme suit: <ph type="x-smartling-placeholder">
      </ph>
      1. Examinez le contenu des données du formulaire et vérifiez s'il contient des caractères qui ne peuvent pas être utilisés, comme le signe de pourcentage (%) ou le signe pourcentage (%) suivi de la mention caractères hexadécimaux.

         Exemple 1

         Exemple de requête n° 1: données de formulaire 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 du caractère Caractères hexadécimaux non valides : ZY.

         Exemple 2

         Exemple de demande 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 contient des caractères dont l'utilisation est non autorisée.
   4. Par conséquent, Apigee Edge renvoie 500 Internal Server Error avec le code d'erreur protocol.http.BadFormData.

Solution

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

   Exemple 1

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

   Utiliser un valide caractères hexadécimaux 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 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 le <ph type="x-smartling-placeholder"></ph> "%-encoding" pour le signe de pourcentage (%), c'est-à-dire modifier le fichier en %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
<ph type="x-smartling-placeholder"></ph> Données de formulaire - application/x-www-form-urlencode

Si vous avez toujours besoin de l'aide de l'assistance Apigee, consultez la section Doit rassembler de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, rassemblez les informations suivantes : de diagnostic, 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 de proxy d'API
• Exécutez la commande curl qui permet de reproduire le problème. 500 Internal Server Error par 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 en échec
• 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 les valeurs réelles.

• Journaux système du processeur de messages

  /opt/apigee/var/log/edge-message-processor/logs/system.log

Références

• <ph type="x-smartling-placeholder"></ph> Types de contenus des formulaires
• <ph type="x-smartling-placeholder"></ph> RFC3986, section 2.1: Encodage en pourcentage
• <ph type="x-smartling-placeholder"></ph> Encodage en pourcentage
• <ph type="x-smartling-placeholder"></ph> Caractères hexadécimaux