500 Interner Serverfehler – BadFormData

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 500 Internal Server Error mit dem Fehlercode protocol.http.BadFormData als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

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 dieses Problems befassen, wollen wir uns ansehen, was Formulardaten sind.

Formulardaten sind die Informationen, die der Nutzer in der Regel über ein HTML-Formular mit Elementen wie einem Texteingabefeld, einer Schaltfläche oder einem Kästchen bereitstellt. Die Formulardaten werden in der Regel als Reihe von Schlüssel/Wert-Paaren im Rahmen von HTTP-Anfragen oder -Antworten gesendet.

Übertragung von Formulardaten

1. Content-Type: application/x-www-form-urlencoded
   • Wenn die Größe der Formulardaten gering ist, werden die Daten als Schlüssel/Wert-Paare mit Folgendem gesendet:
     • Die Zeichen in beiden Schlüsseln sind gemäß den Regeln in Formulare – Abschnitt 17.13.4.1 codiert.
     • Der Header 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üsseln und Werten werden prozentcodiert. Das heißt, sie werden als Zeichentriplett %HH dargestellt, das aus einem Prozentzeichen gefolgt von zwei Hexadezimalziffern besteht, die den ASCII-Code des jeweiligen Zeichens darstellen.
   • Auch wenn das Prozentzeichen (%) in den Formulardaten zulässig ist, wird es als Beginn einer speziellen Escape-Sequenz interpretiert. Wenn die Formulardaten also das Prozentzeichen (%) im Schlüssel oder Wert enthalten müssen, sollte es als %25, übertragen werden. Das ist der ASCII-Code für das Prozentzeichen (%).
2. Content-Type: multipart/form-data

   Wenn Sie große Mengen an Binärdaten oder Text mit Nicht-ASCII-Zeichen übertragen möchten, können Sie die Daten mit Content-Type: multipart/form-data senden, wie in Formulare – Abschnitt 17.13.4.2 beschrieben.

Mögliche Ursachen

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

1. Die HTTP-Anfrage, die vom Client an Apigee Edge gesendet wird, enthält Folgendes:
   1. Content-Type: application/x-www-form-urlencoded und
   2. Formulardaten mit dem Prozentzeichen (%) oder dem Prozentzeichen (%), gefolgt von ungültigen Hexadezimalzeichen, die nicht gemäß der Formulare – Abschnitt 17.13.4.1 zulässig sind.

2. Der API-Proxy in Apigee Edge liest die spezifischen Formularparameter, die alle Zeichen enthalten, die nicht mit der ExtractVariables- oder der AssignMessage-Richtlinie im Anfrageablauf verwendet werden dürfen.

   Dieser Fehler tritt beispielsweise auf, wenn die Formulardaten das Prozentzeichen (%) unverändert (ohne Codierung) oder das Prozentzeichen (%) gefolgt von ungültigen Hexadezimalzeichen im Schlüssel und/oder Wert enthalten.

   Mögliche Ursachen für diesen Fehler:

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

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Verfahren, 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 mit API-Monitoring, dem Trace-Tool oder NGINX-Zugriffsprotokollen, wie in Häufige Diagnoseschritte beschrieben.
2. Wenn der Fehlercode protocol.http.BadFormData ist, die Fehlerquelle den Wert proxy oder policy hat und die Fehlerrichtlinie nicht leer ist, bedeutet dies,dass die in der Fehlerrichtlinie angegebene Richtlinie beim Lesen oder Extrahieren der Formulardaten (Formularparameter) fehlgeschlagen ist.
3. Sehen Sie sich die in der Fault Policy (Fehlerrichtlinie) angegebene Richtlinie an und ermitteln Sie die folgenden Informationen:
   1. Quelle:Legen Sie fest, ob die Richtlinie die Daten aus der Anfrage oder Antwort liest oder extrahiert.
   2. Formularparameter:Bestimmen Sie die spezifischen Formularparameter, die in der Richtlinie gelesen werden.

      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 oben genannten ExtractVariables-Richtlinie gilt Folgendes:

      • Quelle: request

        Dies wird durch das <Source>-Element angegeben.

      • Formularparameter:username und password

        Dies wird durch das <Pattern> -Element innerhalb des <FormParam>-Elements angegeben.

      Dies weist darauf hin, dass die Formularparameter username und/oder password, die vom Client als Teil der HTTP-Anfrage an Apigee Edge übergeben wurden, Zeichen enthalten, 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 oben genannten ExtractVariables-Richtlinie gilt Folgendes:

      • Quelle: request

        Dies wird durch das Attribut source im Element <Copy> angegeben.

      • Formularparameter:username und password

        Dies wird durch das Attribut name im Element <FormParam> angegeben.

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

4. Prüfen Sie mit einer der folgenden Methoden, ob in den in Schritt 3 ermittelten Formularparametern Zeichen verwendet werden, die nicht zulässig sind:

   Trace-Tool

   So validieren Sie mit dem Trace-Tool:

   1. Wenn Sie den Trace für die fehlgeschlagene Anfrage wie unter Allgemeine Diagnoseschritte beschrieben erfasst haben, wählen Sie eine der fehlgeschlagenen Anfragen aus.
   2. Wenn Sie festgestellt haben, dass die Formularparameter, die Zeichen enthalten, die nicht zulässig sind, Teil der HTTP-Anfrage in Schritt 3 oben sind, dann
      1. Rufen Sie die Phase Anfrage vom Kunden erhalten auf.

      2. Scrollen Sie nach unten zum Abschnitt Phasendetails und sehen Sie sich die Inhaltsanfrage an.

         ( größeres Bild ansehen)

         
      3. Beachten Sie, dass im obigen Beispiel der Formularparameter password das Prozentzeichen (%) enthält.
      4. Da das Prozentzeichen (%) auch für die Prozentcodierung der Sonderzeichen verwendet wird, kann es nicht unverändert in den Formulardaten verwendet werden.
      5. Daher antwortet Apigee Edge mit 500 Internal Server Error und dem Fehlercode protocol.http.BadFormData.

   Tatsächliche Anfrage

   So validieren Sie die Anfrage:

   1. Wenn Sie keinen Zugriff auf die tatsächliche Anfrage an den Zielserver haben, fahren Sie mit Lösung fort.
   2. Wenn Sie Zugriff auf die tatsächliche Anfrage an Apigee Edge haben, führen Sie die folgenden Schritte aus:
      1. Prüfen Sie den Inhalt der Formulardaten und sehen Sie nach, ob er Zeichen enthält, die nicht verwendet werden dürfen, z. B. das Prozentzeichen (%) oder das Prozentzeichen (%) gefolgt von 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"
         

         Beachten Sie in diesem Beispiel, dass das Element client_secret das Prozentzeichen (%) gefolgt von ungültigen Hexadezimalzeichen ZY enthält.

         Beispiel 2

         Beispielanfrage 2: Formulardaten, die in einer Datei übergeben werden:

         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, das nicht unverändert in den Formulardaten übergeben werden sollte.

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

Auflösung

1. Achten Sie darauf, dass alle Sonderzeichen in den Schlüsseln und Werten von Formulardaten oder Parametern, die vom Client als Teil der HTTP-Anfrage gesendet werden, immer wie unter Formulardaten – application/x-www-form-urlencoded beschrieben codiert werden.
2. Bei den oben genannten Beispielen können Sie die Probleme so beheben:

   Beispiel 1

   Beispiel 1: Formulardaten, die als Teil der Anfrage übergeben werden:

   Verwenden Sie gültige hexadezimale Zeichen, die dem ASCII-Code für ein bestimmtes Zeichen entsprechen. Wenn Sie beispielsweise das Dollarzeichen ($) senden möchten, verwenden Sie %24, wie unten gezeigt:

   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: Formulardaten, die in einer Datei übergeben werden:

   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 Prozentcodierung für das Prozentzeichen (%). Ändern Sie die Datei also so, dass sie %25 enthält, 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:

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden 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ändiger curl-Befehl, der zum Reproduzieren des 500 Internal Server Error mit dem Fehlercode protocol.http.BadFormData verwendet wird
• Trace-Datei für die API-Anfragen

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

• Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
• Name der Umgebung
• API-Proxy-Bundle
• Trace-Datei für die API-Anfragen

• NGINX-Zugriffslogs

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

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

• Systemprotokolle des Message Processors

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

Verweise

• Inhaltstypen für Formulare
• RFC3986, Abschnitt 2.1: Prozentcodierung
• Prozentuale Codierung
• Hexadezimale Zeichen