500 Interner Serverfehler – BadFormData

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Symptom

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

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 auf die Fehlerbehebung für dieses Problem eingehen, sehen wir uns einmal an, 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 angibt. Die Formulardaten werden im Rahmen von HTTP-Anfragen oder -Antworten normalerweise als eine Reihe von Schlüssel/Wert-Paaren gesendet.

Formulardatenübertragung

1. Content-Type: application/x-www-form-urlencoded
   • Wenn die Formulardaten klein sind, werden die Daten als Schlüssel/Wert-Paare mit folgenden Elementen gesendet:
     • Die Zeichen in beiden Schlüsseln, die gemäß den in Formulare – Abschnitt 17.13.4.1 erläuterten Regeln codiert werden
     • Den 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 sowohl in Schlüsseln als auch in Werten werden prozentcodiert, d. h., sie werden als Zeichendreieck %HH dargestellt, das aus einem Prozentzeichen gefolgt von zwei Hexadezimalziffern besteht, die den ASCII-Code des jeweiligen Zeichens darstellen.
   • Obwohl das Prozentzeichen (%) in 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, sollten sie als %25, übertragen werden. Dies ist der ASCII-Code für das Prozentzeichen (%).
2. Inhaltstyp: 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 der Methode Content-Type: multipart/form-data senden. Eine Erläuterung hierzu finden Sie unter 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 vom Client an Apigee Edge gesendet wird, enthält:
   1. Content-Type: application/x-www-form-urlencoded und
   2. Formulardaten mit dem Prozentzeichen (%) oder dem Prozentzeichen (%), gefolgt von ungültigen Hexadezimalzeichen, die gemäß Formularen – Abschnitt 17.13.4.1 nicht zulässig sind.

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

   Wenn die Formulardaten beispielsweise das Prozentzeichen (%) unverändert (ohne Codierung) oder das Prozentzeichen (%) gefolgt von ungültigen Hexadezimalzeichen im Schlüssel und/oder Wert enthalten, wird dieser Fehler zurückgegeben.

   Mögliche Ursachen für diesen Fehler:

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

Allgemeine Diagnoseschritte

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

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

Diagnose

1. Bestimmen Sie den Fehlercode, die Fehlerquelle und die Fehlerrichtlinie für 500 Internal Server Error mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte erläutert.
2. Wenn der Fehlercode protocol.http.BadFormData lautet, die Fehlerquelle den Wert proxy oder policy hat und die Fehlerrichtlinie nicht leer ist, weist dies darauf hin,dass die in der Fehlerrichtlinie angegebene Richtlinie beim Lesen oder Extrahieren der Formulardaten (Formularparameter) fehlgeschlagen ist.
3. Prüfen Sie die in der Fehlerrichtlinie angegebene Richtlinie und ermitteln Sie die folgenden Informationen:
   1. Quelle:Ermitteln Sie, ob die Richtlinie die Daten aus einer 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 obigen ExtractVariables-Richtlinie:

      • Quelle: request

        Dies wird durch das Element <Source> angezeigt.

      • Formularparameter: username und password

        Dies wird durch das Element <Pattern> im Element <FormParam> angegeben.

      Dies zeigt an, dass die Formularparameter username und/oder password, die als Teil der HTTP-Anfrage des Clients an Apigee Edge übergeben werden, Zeichen enthalten, die nicht verwendet werden dürfen.

      Beispiel 2

      Beispiel 2: ConfirmMessage-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 im Element <Copy> angegeben.

      • Formularparameter: username und password

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

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

4. Prüfen Sie mit einer der folgenden Methoden, ob Zeichen in den in Schritt 3 identifizierten Formularparametern 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 erläutert erfasst haben, wählen Sie eine der fehlgeschlagenen Anfragen aus.
   2. Wenn Sie festgestellt haben, dass die Formularparameter, die nicht zulässige Zeichen enthalten, Teil der HTTP-Anfrage in Schritt 3 sind, dann gilt:
      1. Gehen Sie zur Phase Anfrage vom Client erhalten.

      2. Scrollen Sie nach unten zum Abschnitt Phasendetails und überprüfen Sie den Anfrageinhalt.

         ( 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 in den Formulardaten nicht unverändert verwendet werden.
      5. Daher antwortet Apigee Edge mit 500 Internal Server Error und dem Fehlercode protocol.http.BadFormData.

   Tatsächliche Anfrage

   So validieren Sie mithilfe der tatsächlichen Anfrage:

   1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage an den Zielserver haben, wechseln Sie zu Lösung.
   2. Wenn Sie Zugriff auf die eigentliche Anfrage an Apigee Edge haben, führen Sie die folgenden Schritte aus:
      1. Prüfen Sie, ob die Inhalte der Formulardaten Zeichen enthalten, 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 in einer Datei übergeben:

         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 als Teil einer HTTP-Anfrage vom Client gesendet werden, immer wie unter Form Data – application/x-www-form-urlencoded erläutert codiert sind.
2. Bei den oben beschriebenen Beispielen können Sie die Probleme so beheben:

   Beispiel 1

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

   Verwenden Sie gültige Hexadezimalzeichen, die mit dem ASCII-Code eines bestimmten Zeichens übereinstimmen. Wenn Sie beispielsweise das Dollarzeichen ($) senden möchten, verwenden Sie %24 so:

   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 in einer Datei übergeben:

   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 (%), um die Datei so zu ändern, dass sie %25 enthält:

   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
Formulardaten – application/x-www-form-urlencoded

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie den Abschnitt Diagnoseinformationen müssen erfasst werden.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen und wenden Sie sich 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
• Führen Sie den Befehl curl aus, der zum Reproduzieren von 500 Internal Server Error mit dem Fehlercode protocol.http.BadFormData verwendet wurde.
• Ablaufverfolgungsdatei für die API-Anfragen

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

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

• NGINX-Zugriffslogs

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

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

• Systemprotokolle von Message Processor

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

Verweise

• Inhaltstypen für Formulare
• RFC3986, Abschnitt 2.1: Prozentcodierung
• Prozentcodierung
• Hexadezimalzeichen