500 Interner Serverfehler – BadFormData

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Die Clientanwendung ruft den HTTP-Statuscode 500 Internal Server Error mit Fehlercode protocol.http.BadFormData als Antwort für API-Aufrufe.

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 500 Internal Server Error

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

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

Formulardaten

Bevor wir uns mit der Fehlerbehebung für dieses Problem befassen, wollen wir zunächst verstehen, was Formulardaten sind.

Formulardaten sind die Informationen, die der Nutzer in der Regel über ein HTML-Formular mit Elementen bereitstellt. wie ein Texteingabefeld, eine Schaltfläche oder ein Kontrollkästchen. Die Formulardaten werden in der Regel Schlüssel/Wert-Paare als Teil von HTTP-Anfragen oder -Antworten.

Datenübertragung mit Formular

1. Inhaltstyp: application/x-www-form-urlencoded <ph type="x-smartling-placeholder">
   </ph>
   • Wenn die Formulardaten klein sind, werden die Daten als Schlüssel/Wert-Paare gesendet mit: <ph type="x-smartling-placeholder">
     </ph>
     • Die Zeichen in beiden Schlüsseln wurden gemäß den Regeln unter <ph type="x-smartling-placeholder"></ph> Formulare – Abschnitt 17.13.4.1
     • Die Überschrift Content-Type: application/x-www-form-urlencoded

     Beispielanfrage mit Formulardaten:

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

   • Alle nicht alphanumerischen Zeichen in Schlüssel und Werten werden <ph type="x-smartling-placeholder"></ph> Prozent codiert, d. h., sie werden als Zeichentriplet dargestellt %HH, bestehend aus einem Prozentzeichen gefolgt von zwei Hexadezimalziffern für den ASCII-Code des jeweiligen Zeichens.
   • Obwohl das Prozentzeichen (%) in den Formulardaten zulässig ist, ist es als Beginn einer speziellen Escapesequenz interpretiert. Wenn also die Formulardaten das Prozentzeichen (%) im Schlüssel oder Wert enthalten, dann muss dieser als %25, (der ASCII-Code für das Prozentzeichen darstellt) (%) Zeichen.
2. Inhaltstyp: multipart/form-data

   Wenn Sie große Mengen an Binärdaten oder Text mit Nicht-ASCII-Zeichen übertragen möchten Zeichen, dann können Sie die Daten mit den Zeichen Content-Type: multipart/form-data wie unter <ph type="x-smartling-placeholder"></ph> Formulare – Abschnitt 17.13.4.2

Mögliche Ursachen

Dieser Fehler tritt nur dann auf, wenn alle folgenden Bedingungen erfüllt sind:

1. Die HTTP-Anfrage, die der Client an Apigee Edge sendet, enthält: <ph type="x-smartling-placeholder">
   </ph>
   1. Content-Type: application/x-www-form-urlencoded und
   2. Formulardaten mit dem Prozentzeichen (%) oder dem Prozentzeichen (%) gefolgt von ungültigen Hexadezimalzeichen, die gemäß <ph type="x-smartling-placeholder"></ph> Formulare – Abschnitt 17.13.4.1

2. Der API-Proxy in Apigee Edge liest die spezifischen Formularparameter, die beliebige Zeichen enthalten. die im Anfrageablauf mit ExtractVariables oder der Methode nicht zulässig AssignMessage-Richtlinie.

   Wenn die Formulardaten beispielsweise das Prozentzeichen (%) unverändert (ohne Codierung) oder dem Prozentzeichen (%) gefolgt von einem ungültigen Hexadezimalwert im Schlüssel und/oder Wert enthält, erhalten Sie diesen Fehler.

   Mögliche Ursachen für diesen Fehler:

   Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
   Die Formularparameter in der Anfrage enthalten unzulässige Zeichen	Die Formularparameter, die als Teil der HTTP-Anfrage vom Client übergeben werden, enthalten beliebige Zeichen, die nicht verwendet werden dürfen.	Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Techniken, um diesen Fehler zu diagnostizieren:

Ursache: Formularparameter in der Anfrage enthalten unzulässige Zeichen.

Diagnose

1. Ermitteln Sie den Fehlercode, die Fehlerquelle und die Fehlerrichtlinie für 500 Internal Server Error mithilfe des API-Monitorings, des Trace-Tools oder der NGINX-Zugriffslogs wie beschrieben. finden Sie unter Häufige Diagnoseschritte.
2. Wenn der Fehlercode protocol.http.BadFormData lautet, hat die Fehlerquelle der Wert proxy oder policy und Fault Policy ist kein leer, bedeutet dies, dass die in der Fault Policy angegebene Richtlinie während Lesen oder Extrahieren der Formulardaten (Formularparameter)
3. Sieh dir die in der Fault Policy angegebene Richtlinie an und stelle Folgendes fest: Informationen: <ph type="x-smartling-placeholder">
   </ph>
   1. Quelle:Ermitteln Sie, ob die Richtlinie die Daten aus liest oder extrahiert. Anfrage oder Antwort.
   2. Formparameter:Bestimmen Sie die Formularparameter, die in der .

      Beispiel 1

      Beispiel 1: ExtractVariables-Richtlinie zum Extrahieren von Formularparametern:

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

      In der obigen ExtractVariables-Richtlinie:

      • Quelle: request

        Dies wird durch das Element <Source> angezeigt.

      • Formularparameter: username und password

        Dies wird durch das Element <Pattern> im <FormParam>-Element

      Das bedeutet, dass die Formularparameter username und/oder password wurde als Teil der HTTP-Anfrage vom Client an Apigee Edge enthält Zeichen, die nicht verwendet werden dürfen.

      Beispiel 2

      Beispiel 2: AssignMessage-Richtlinie zum Kopieren von Formularparametern:

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

      In der obigen ExtractVariables-Richtlinie:

      • Quelle: request

        Dies wird durch das Attribut source in der <Copy>-Element

      • Formularparameter: username und password

        Dies wird durch das Attribut name in der <FormParam>-Element

      Das bedeutet, dass der Formularparameter username, password oder die beide als Teil der HTTP-Anfrage vom Client an Apigee Edge übergeben werden, enthalten Zeichen, die nicht verwendet werden dürfen.

4. Prüfen Sie, ob Zeichen enthalten sind, die nicht verwendet werden dürfen. Zeichen in den Formularparametern, die in Schritt 3 identifiziert wurden mithilfe einer der folgenden Methoden:

   Trace-Tool

   So führen Sie eine Validierung mit dem Trace-Tool durch:

   1. Wenn Sie den Trace für die fehlgeschlagene Anfrage wie unter Häufig auftretende Diagnoseschritte und wählen Sie dann einen der fehlgeschlagenen Anfragen.
   2. Wenn Sie festgestellt haben, dass die Formularparameter die nicht verwendet werden dürfen, sind Teil der HTTP-Anfrage in Schritt 3 oben und dann <ph type="x-smartling-placeholder">
      </ph>
      1. Gehen Sie zur Phase Request Received from Client.

      2. Scrollen Sie nach unten zum Abschnitt Phase Details (Phasendetails) und überprüfen Sie die Inhalte anfordern

         ( Größeres Bild ansehen)

         
      3. Beachten Sie im obigen Beispiel, dass der Formularparameter password enthält das Prozentzeichen (%).
      4. Da das Prozentzeichen (%) auch für <ph type="x-smartling-placeholder"></ph> Prozentcodierung der Sonderzeichen, kann also nicht unverändert in der Formulardaten.
      5. Daher antwortet Apigee Edge mit 500 Internal Server Error durch den Fehlercode protocol.http.BadFormData.

   Tatsächliche Anfrage

   So validieren Sie die Anfrage anhand der tatsächlichen Anfrage:

   1. Wenn Sie keinen Zugriff auf die Anfrage haben, die an den Zielserver gesendet wurde, und gehe zu Auflösung.
   2. Wenn Sie Zugriff auf die eigentliche Anfrage an Apigee Edge haben, führen Sie führen Sie die folgenden Schritte aus: <ph type="x-smartling-placeholder">
      </ph>
      1. Überprüfen Sie den Inhalt der Formulardaten und kontrollieren Sie, ob er Zeichen enthält, die dürfen nicht verwendet werden, z. B. das Prozentzeichen (%) oder das Prozentzeichen (%) gefolgt von einem ungültigen Hexadezimalzeichen.

         Beispiel 1

         Beispielanfrage 1: Formulardaten als Teil der Anfrage

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

         In diesem Beispiel ist das Element client_secret enthält das Prozentzeichen (%) gefolgt von Ungültige Hexadezimalzeichen ZY.

         Beispiel 2

         Beispielanfrage 2: In einer Datei übergebene Formulardaten:

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

         Inhalt von form_data.xml:

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

         Beachten Sie in diesem Beispiel, dass das Element password das Prozentzeichen (%) enthält. unverändert in den Formulardaten übergeben werden.

   3. In den beiden obigen Beispielen wurden die Formulardaten, die als Teil der HTTP-Anfrage an Apigee Edge enthält Zeichen, die nicht verwendet werden dürfen.
   4. Daher antwortet Apigee Edge mit 500 Internal Server Error mit dem Fehlercode protocol.http.BadFormData.

Auflösung

1. Achten Sie darauf, dass alle Sonderzeichen in den Schlüsseln und Werten von Formulardaten oder -parametern enthalten sind die als Teil der HTTP-Anforderung des Clients gesendet werden, sind immer codiert, wie unter erläutert. Formulardaten – application/x-www-form-urlencoded.
2. Bei den oben beschriebenen Beispielen können Sie die Probleme so beheben:

   Beispiel 1

   Beispiel 1: Mit der Anfrage übergebene Formulardaten:

   Gültige verwenden Hexadezimalzeichen, die mit dem ASCII-Code für ein bestimmtes Zeichen übereinstimmen. Wenn du beispielsweise das Dollarzeichen ($) senden möchtest, verwende %24 wie unten dargestellt:

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

   Beispiel 2

   Beispielanfrage 2: In einer Datei übergebene Formulardaten:

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

   Inhalt von form_data.xml:

   Verwenden Sie die Methode <ph type="x-smartling-placeholder"></ph> %-encoding für das Prozentzeichen (%) geben an, dass die Datei haben %25 , wie unten gezeigt:

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

Spezifikation

Apigee Edge erwartet, dass die Formulardaten gemäß den folgenden Spezifikationen gesendet werden:

Spezifikation
<ph type="x-smartling-placeholder"></ph> Formulardaten – application/x-www-form-urlencoded

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, gehen Sie zu Muss Diagnosedaten.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgung der obigen Anleitung weiterhin besteht, stellen Sie Folgendes zusammen: Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Name der Organisation
• Name der Umgebung
• Name des API-Proxys
• Vollständigen curl-Befehl zum Reproduzieren des 500 Internal Server Error durch den Fehlercode protocol.http.BadFormData
• Ablaufverfolgungsdatei für API-Anfragen

Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Vollständige Fehlermeldung für fehlgeschlagene Anfragen
• Name der Umgebung
• API-Proxy-Bundle
• Ablaufverfolgungsdatei für API-Anfragen

• NGINX-Zugriffslogs

  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Wo:ORG, ENV und PORT# werden ersetzt durch tatsächliche Werte.

• Systemprotokolle für Message Processor

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

Verweise

• <ph type="x-smartling-placeholder"></ph> Inhaltstypen des Formulars
• <ph type="x-smartling-placeholder"></ph> RFC3986, Abschnitt 2.1: Prozentcodierung
• <ph type="x-smartling-placeholder"></ph> Prozentcodierung
• <ph type="x-smartling-placeholder"></ph> Hexadezimalzeichen