500 Errore interno del server - BadFormData

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X.
info

Sintomo

L'applicazione client riceve un codice di stato HTTP 500 Internal Server Error con il codice di errore protocol.http.BadFormData come risposta per le chiamate API.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 500 Internal Server Error

Inoltre, potresti visualizzare il seguente messaggio di errore:

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

Dati modulo

Prima di entrare nel dettaglio della risoluzione dei problemi, vediamo cosa sono i dati dei moduli.

I dati dei moduli sono le informazioni fornite dall'utente in genere tramite un modulo HTML con elementi come una casella di input di testo, un pulsante o una casella di controllo. I dati del modulo vengono generalmente inviati come una serie di coppie chiave-valore nell'ambito di richieste o risposte HTTP.

Trasmissione dei dati del modulo

  1. Content-Type: application/x-www-form-urlencoded
    • Se le dimensioni dei dati del modulo sono ridotte, i dati vengono inviati come coppie chiave-valore con:
      • I caratteri di entrambe le chiavi codificati in base alle regole spiegate in Forms - Section 17.13.4.1
      • L'intestazione Content-Type: application/x-www-form-urlencoded

      Richiesta di esempio con dati del modulo:

      curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
      
    • Tutti i caratteri non alfanumerici nelle chiavi e nei valori sono codificati in percentuale, ovvero sono rappresentati come una tripletta di caratteri %HH, costituita da un segno di percentuale seguito da due cifre esadecimali che rappresentano il codice ASCII del carattere specifico.
    • Pertanto, anche se il simbolo di percentuale (%) è consentito nei dati del modulo, viene interpretato come l'inizio di una sequenza di escape speciale. Pertanto, se i dati del modulo devono contenere il simbolo di percentuale (%) nella chiave o nel valore, devono essere trasmessi come %25, , che rappresenta il codice ASCII per il carattere simbolo di percentuale (%).
  2. Content-Type: multipart/form-data

    Se vuoi trasmettere grandi quantità di dati binari o testo contenente caratteri non ASCII, puoi inviare i dati con Content-Type: multipart/form-data come spiegato in Forms - Section 17.13.4.2

Possibili cause

Questo errore si verifica se e solo se sono soddisfatte tutte le seguenti condizioni:

  1. La richiesta HTTP inviata dal client ad Apigee Edge contiene:
    1. Content-Type: application/x-www-form-urlencoded e
    2. Dati del modulo con il segno percentuale (%) o il segno percentuale (%) seguito da caratteri esadecimali non validi che non sono consentiti in base a Forms - Section 17.13.4.1.
  2. Il proxy API in Apigee Edge legge i parametri del modulo specifici contenenti caratteri non consentiti da utilizzare nel flusso di richieste utilizzando i criteri ExtractVariables o AssignMessage.

    Ad esempio, se i dati del modulo contengono il simbolo di percentuale (%) così com'è (senza codifica) o il simbolo di percentuale (%) seguito da caratteri esadecimali non validi nella chiave e/o nel valore, viene visualizzato questo errore.

    Ecco le possibili cause di questo errore:

    Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili a
    I parametri del modulo nella richiesta contengono caratteri non consentiti I parametri del modulo passati come parte della richiesta HTTP dal client contengono caratteri non consentiti. Utenti di Edge Public e Private Cloud

Passaggi di diagnostica comuni

Utilizza uno dei seguenti strumenti/tecniche per diagnosticare questo errore:

Monitoraggio delle API

Per diagnosticare l'errore utilizzando API Monitoring:

  1. Accedi alla UI di Apigee Edge come utente con un ruolo appropriato.
  2. Passa all'organizzazione in cui vuoi esaminare il problema.

  3. Vai alla pagina Analizza > Monitoraggio API > Esamina.
  4. Seleziona il periodo di tempo specifico in cui hai osservato gli errori.
  5. Traccia il codice di errore rispetto al tempo.

  6. Seleziona una cella con il codice di errore protocol.http.BadFormData come mostrato di seguito:

    (visualizza immagine più grande)

  7. Le informazioni sul codice di errore protocol.http.BadFormData vengono visualizzate come mostrato di seguito:

    (visualizza immagine più grande)

  8. Fai clic su Visualizza log ed espandi la riga della richiesta non riuscita.

  9. Nella finestra Log, prendi nota dei seguenti dettagli:
    • Codice di stato: 500
    • Origine del guasto: proxy
    • Codice guasto: protocol.http.BadFormData
    • Norme relative ai guasti: extractvariables/EV-ExtractFormParams
  10. Se Fault Source è proxy, Fault Code è protocol.http.BadFormData e Fault Policy non è vuoto, significa che l'errore si è verificato durante la lettura o l'estrazione dei dati del modulo (parametri del modulo) da parte del criterio specifico indicato in Fault Policy, che contiene caratteri non consentiti.
  11. In questo esempio, X-Apigee-fault-policy è extractvariables/EV- ExtractFormParams, , il che significa che la policy ExtractVariables denominata EV-ExtractFormParams non è riuscita a leggere o estrarre i parametri del modulo.

Strumento Traccia

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Attiva l'opzione Traccia sessione e una delle seguenti opzioni:
    • Attendi che si verifichi l'errore 500 Internal Server Error oppure
    • Se riesci a riprodurre il problema, effettua la chiamata API per riprodurlo 500 Internal Server Error
  2. Assicurati che l'opzione Mostra tutte le informazioni sul flusso sia abilitata:

  3. Seleziona una delle richieste non riuscite ed esamina la traccia.
  4. Esamina le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.
  5. L'errore si trova in genere in uno dei criteri, come mostrato di seguito:

    Nella traccia di esempio riportata sopra, tieni presente che l'errore si è verificato nella policy ExtractVariables denominata EV-ExtractFormParams.

  6. Vai al flusso denominato Error (Errore) dopo il criterio specifico non riuscito:

  7. Prendi nota dei valori seguenti dalla traccia:

    Errore: Bad Form Data

    state: PROXY_REQ_FLOW

    error.class: com.apigee.rest.framework.BadRequestException

    • Il valore dell'errore Bad Form Data indica che i parametri del modulo contenevano alcuni caratteri il cui utilizzo non è consentito.
    • Il valore dello stato PROXY_REQ_FLOW, indica che l'errore si è verificato nel flusso di richieste del proxy API.
  8. Vai alla fase AX (dati di Analytics registrati) nella traccia e fai clic sulla fase.
  9. Scorri verso il basso fino alla sezione Dettagli fase - Intestazioni errori e determina i valori di X-Apigee-fault-code, X-Apigee-fault-source e X-Apigee-fault-policy come mostrato di seguito:

  10. Tieni presente che i valori di X-Apigee-fault-code e X-Apigee-fault-source sono rispettivamente protocol.http.BadFormData e policy e X-Apigee-fault-policy non è vuoto. Ciò indica che l'errore si è verificato durante la lettura o l'estrazione dei dati del modulo (parametri del modulo) da parte delle norme specifiche indicate in X-Apigee-fault-policy, che contenevano caratteri non consentiti.

    Intestazioni della risposta Valore
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  11. In questo esempio, X-Apigee-fault-policy è extractvariables/EV- ExtractFormParams, , il che significa che la policy ExtractVariables denominata EV-ExtractFormParams non è riuscita a leggere o estrarre i parametri del modulo.

NGINX

Per diagnosticare l'errore utilizzando i log di accesso NGINX:

  1. Se sei un utente di Private Cloud, puoi utilizzare i log di accesso NGINX per determinare le informazioni chiave su HTTP 500 Internal Server Error.
  2. Controlla i log di accesso di NGINX:

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

  3. Cerca se sono presenti errori 500 con codice di errore protocol.http.BadFormData durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono ancora presenti richieste non riuscite con 500.
  4. Se trovi errori 500 con X-Apigee-fault-code corrispondente al valore di protocol.http.BadFormData, determina il valore di X-Apigee-fault-source e X-Apigee-fault-policy.

    Esempio di errore 500 dal log di accesso NGINX:

    La voce di esempio riportata sopra del log di accesso NGINX ha i seguenti valori per X-Apigee-fault-code e X-Apigee-fault-source:

    Intestazioni Valore
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  5. Tieni presente che i valori di X-Apigee-fault-code, X-Apigee-fault-source sono rispettivamente protocol.http.BadFormData e policy e X-Apigee-fault-policy non è vuoto. Ciò indica che l'errore si è verificato durante la lettura o l'estrazione dei dati del modulo (parametri del modulo) da parte delle norme specifiche indicate in X-Apigee-fault-policy, che contenevano caratteri non consentiti.
  6. In questo esempio, X-Apigee-fault-policy è extractvariables/EV- ExtractFormParams, , il che significa che la policy ExtractVariables denominata EV-ExtractFormParams non è riuscita durante la lettura dei parametri del modulo.

Causa: i parametri del modulo nella richiesta contengono caratteri non consentiti

Diagnosi

  1. Determina Fault Code, Fault Source e Fault Policy per 500 Internal Server Error utilizzando il monitoraggio API, lo strumento Trace o i log di accesso NGINX come spiegato in Passaggi comuni per la diagnosi.
  2. Se Fault Code è protocol.http.BadFormData, Fault Source ha il valore proxy o policy e Fault Policy non è vuoto, significa che il criterio specificato in Fault Policy non è riuscito durante la lettura o l'estrazione dei dati del modulo (parametri del modulo).
  3. Esamina le norme indicate in Norme sui guasti e determina le seguenti informazioni:
    1. Origine:determina se la norma legge o estrae i dati dalla richiesta o dalla risposta.
    2. Parametri del modulo:determina i parametri specifici del modulo che vengono letti nel criterio.

      Esempio 1

      Esempio 1: criterio ExtractVariables che estrae i parametri del modulo:

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

      Nelle norme ExtractVariables riportate sopra:

      • Fonte: request

        Ciò è indicato dall'elemento <Source>

      • Parametri del modulo: username e password

        Ciò è indicato dall'elemento <Pattern> all'interno dell'elemento <FormParam>

      Ciò indica che i parametri del modulo username e/o password passati come parte della richiesta HTTP dal client ad Apigee Edge contengono caratteri il cui utilizzo non è consentito.

      Esempio 2

      Esempio 2: criteri AssignMessage che copiano i parametri del modulo:

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

      Nelle norme ExtractVariables riportate sopra:

      • Origine: request

        Ciò è indicato dall'attributo source nell'elemento <Copy>

      • Parametri del modulo: username e password

        Ciò è indicato dall'attributo name nell'elemento <FormParam>.

      Ciò indica che i parametri del modulo username o password o entrambi passati come parte della richiesta HTTP dal client ad Apigee Edge contengono caratteri il cui utilizzo non è consentito.

  4. Controlla se sono presenti caratteri non consentiti nei parametri del modulo identificati nel passaggio 3 utilizzando uno dei seguenti metodi:

    Strumento Traccia

    Per eseguire la convalida utilizzando lo strumento Traccia:

    1. Se hai acquisito la traccia per la richiesta non riuscita come spiegato in Passaggi comuni per la diagnosi, seleziona una delle richieste non riuscite.
    2. Se hai stabilito che i parametri del modulo contenenti caratteri non consentiti fanno parte della richiesta HTTP nel passaggio 3 precedente, allora
      1. Vai alla fase Richiesta ricevuta dal cliente.
      2. Scorri verso il basso fino alla sezione Dettagli della fase e rivedi i Contenuti richiesti.

        ( visualizza immagine più grande)

      3. Nell'esempio precedente, tieni presente che il parametro del modulo password contiene il simbolo di percentuale (%).
      4. Poiché il simbolo di percentuale (%) viene utilizzato anche per la codifica percentuale dei caratteri speciali, non può essere utilizzato così com'è nei dati del modulo.
      5. Pertanto, Apigee Edge risponde con 500 Internal Server Error con il codice di errore protocol.http.BadFormData.

    Richiesta effettiva

    Per convalidare utilizzando la richiesta effettiva:

    1. Se non hai accesso alla richiesta effettiva inviata al server di destinazione, vai a Risoluzione.
    2. Se hai accesso alla richiesta effettiva inviata ad Apigee Edge, segui questi passaggi:
      1. Esamina i contenuti dei dati del modulo e verifica se contengono caratteri che non sono consentiti, ad esempio il segno di percentuale (%) o il segno di percentuale (%) seguito da caratteri esadecimali non validi.

        Esempio 1

        Richiesta di esempio n. 1: dati del modulo inclusi nella richiesta

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

        In questo esempio, tieni presente che l'elemento client_secret contiene il simbolo di percentuale (%) seguito da caratteri esadecimali non validi ZY.

        Esempio 2

        Richiesta di esempio n. 2: dati del modulo passati in un file:

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

        Contenuto di form_data.xml:

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

        In questo esempio, tieni presente che l'elemento password contiene il simbolo di percentuale (%), che non deve essere trasmesso così com'è nei dati del modulo.

    3. Nei due esempi precedenti, i dati del modulo inviati nell'ambito della richiesta HTTP ad Apigee Edge contengono caratteri il cui utilizzo non è consentito.
    4. Pertanto, Apigee Edge risponde con 500 Internal Server Error con il codice di errore protocol.http.BadFormData.

Risoluzione

  1. Assicurati che tutti i caratteri speciali nelle chiavi e nei valori dei dati o dei parametri del modulo inviati come parte della richiesta HTTP dal client siano sempre codificati come spiegato in Dati del modulo - application/x-www-form-urlencoded.
  2. Per gli esempi discussi in precedenza, puoi risolvere i problemi nel seguente modo:

    Esempio 1

    Esempio 1: dati del modulo passati come parte della richiesta:

    Utilizza caratteri esadecimali validi che corrispondono al codice ASCII di un carattere specifico. Ad esempio, se vuoi inviare il simbolo del dollaro ($), utilizza %24 come mostrato di seguito:

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

    Esempio 2

    Richiesta di esempio n. 2: dati del modulo passati in un file:

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

    Contenuto di form_data.xml:

    Utilizza la codifica percentuale per il segno di percentuale (%), ovvero modifica il file in modo che contenga %25 come mostrato di seguito:

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

Specifica

Apigee Edge prevede che i dati del modulo vengano inviati in base alle seguenti specifiche:

Specifica
Dati del modulo - application/x-www-form-urlencoded

Se hai ancora bisogno di assistenza da parte dell'assistenza Apigee, vai a Informazioni di diagnostica da raccogliere.

Deve raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e poi contatta l'assistenza Apigee Edge:

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:

  • Nome organizzazione
  • Nome ambiente
  • Nome del proxy API
  • Completa il comando curl utilizzato per riprodurre 500 Internal Server Error con il codice di errore protocol.http.BadFormData
  • File di traccia per le richieste API

Se sei un utente di Private Cloud, fornisci le seguenti informazioni:

  • Messaggio di errore completo osservato per le richieste non riuscite
  • Nome ambiente
  • Bundle proxy API
  • File di traccia per le richieste API
  • Log degli accessi NGINX

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

    Dove: ORG, ENV e PORT# vengono sostituiti con i valori effettivi.

  • Log di sistema del processore di messaggi

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

Riferimenti