500 Errore interno del server - BadFormData

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X.
informazioni

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 nei dettagli della risoluzione di questo problema, vediamo cosa sono i dati dei moduli.

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

Trasmissione dati modulo

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

      Esempio di richiesta con i 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 in chiavi e valori sono con codifica in percentuale, ovvero sono rappresentati come terzine di caratteri %HH, composte da un segno percentuale seguito da due cifre esadecimali che rappresentano il codice ASCII del carattere specifico.
    • Di conseguenza, anche se il segno 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 segno percentuale (%) nella chiave o nel valore, devono essere trasmessi come %25, , che rappresenta il codice ASCII per il carattere del segno percentuale (%).
  2. Tipo di contenuto: 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 Moduli - Sezione 17.13.4.2

Possibili cause

Questo errore si verifica solo se vengono 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 non consentiti in base a Moduli - Sezione 17.13.4.1.
  2. Il proxy API in Apigee Edge legge i parametri specifici del modulo contenenti caratteri che non possono essere utilizzati nel flusso di richiesta mediante il criterio ExtractVariables o MigrateMessage.

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

    Di seguito sono riportate le possibili cause di questo errore:

    Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili a
    I parametri modulo nella richiesta contengono caratteri non consentiti I parametri del modulo passati come parte della richiesta HTTP dal client contengono tutti i caratteri che non è consentito utilizzare. Utenti di cloud pubblico e privato perimetrale

Passaggi di diagnosi più comuni

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

Monitoraggio delle API

Per diagnosticare l'errore utilizzando il monitoraggio delle API:

  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 riscontrato gli errori.
  5. Traccia Codice di errore su Ora.

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

    (visualizza immagine ingrandita)

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

    (visualizza immagine ingrandita)

  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 errore: proxy
    • Codice di errore: protocol.http.BadFormData
    • Norme sui guasti: extractvariables/EV-ExtractFormParams
  10. Se l'Origine errore è proxy, il Codice di errore è protocol.http.BadFormData e il campo Criterio di errore non è vuoto, significa che l'errore si è verificato mentre il criterio specifico indicato in Criterio di errore leggeva o estraeva i dati del modulo (parametri del modulo), che contengono caratteri non consentiti.
  11. In questo esempio, X-Apigee-fault-policy è extractvariables/EV- ExtractFormParams, , il che significa che il criterio ExtractVariables denominato EV-ExtractFormParams non è riuscito durante la lettura o l'estrazione dei parametri form.

Strumento Traccia

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita la sessione di traccia e:
    • Attendi che si verifichi l'errore 500 Internal Server Error oppure
    • Se riesci a riprodurre il problema, esegui la chiamata API per riprodurlo 500 Internal Server Error
  2. Assicurati che l'opzione Mostra tutte le FlowInfos sia abilitata:

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

    Nella traccia di esempio precedente, tieni presente che l'errore si è verificato nel criterio ExtractVariables denominato EV-ExtractFormParams.

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

  7. Prendi nota dei valori di quanto segue dalla traccia:

    errore: Bad Form Data

    stato: 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 non consentiti.
    • Il valore dello stato PROXY_REQ_FLOW, indica che l'errore si è verificato nel flusso di richiesta del proxy API.
  8. Vai alla fase AX (Analytics Data Recorded) della traccia e fai clic.
  9. Scorri verso il basso fino alla sezione Dettagli fase - Intestazioni degli 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 mentre il criterio specifico indicato in X-Apigee-fault-policy leggeva o estraeva i dati del modulo (parametri del modulo), che contenevano caratteri non consentiti per l'utilizzo.

    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 il criterio ExtractVariables denominato EV-ExtractFormParams ha avuto esito negativo durante la lettura o l'estrazione dei parametri form.

NGINX

Per diagnosticare l'errore utilizzando i log degli accessi di NGINX:

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

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

  3. Cerca per vedere se si sono verificati errori 500 con il codice di errore protocol.http.BadFormData durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non riuscire con 500.
  4. Se riscontri 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 degli accessi di NGINX:

    La voce di esempio sopra riportata dal log degli accessi di 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 protocol.http.BadFormData, policy rispettivamente e X-Apigee-fault-policy non sono vuoti. Ciò indica che l'errore si è verificato mentre il criterio specifico indicato in X-Apigee-fault-policy, leggeva o estraeva i dati del modulo (parametri del modulo), che contenevano caratteri X-Apigee-fault-policy, per l'utilizzo.
  6. In questo esempio, X-Apigee-fault-policy è extractvariables/EV- ExtractFormParams, , il che significa che il criterio ExtractVariables denominato EV-ExtractFormParams non è riuscito durante la lettura dei parametri del modulo.

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

Diagnostica

  1. Determina il codice di errore, l'origine del errore e il criterio di errore per 500 Internal Server Error utilizzando il monitoraggio delle API, lo strumento Trace o i log degli accessi NGINX come spiegato nella sezione Passaggi comuni di diagnosi.
  2. Se il Codice di errore è protocol.http.BadFormData, Origine errore ha il valore proxy o policy e il Criterio di errore non è vuoto, significa che il criterio specificato in Criterio di errore non è riuscito durante la lettura o l'estrazione dei dati del modulo (parametri del modulo).
  3. Esamina le norme indicate nelle Norme relative ai guasti e determina le seguenti informazioni:
    1. Origine: determina se il criterio legge o estrae i dati dalla richiesta o dalla risposta.
    2. Parametri modulo: determinano i parametri specifici del modulo che vengono letti nel criterio.

      Esempio 1

      Esempio 1: criterio ExtractVariables che estrae i parametri 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>
            

      Nella norma ExtractVariables sopra riportata:

      • Fonte: request

        Questo è indicato dall'elemento <Source>

      • Parametri modulo: username e password

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

      Indica che i parametri del modulo username e/o password passati come parte della richiesta HTTP dal client ad Apigee Edge contengono caratteri che non è consentito utilizzare.

      Esempio 2

      Esempio 2: criterio di AssegnaMessage che copia 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>
            

      Nella norma ExtractVariables sopra riportata:

      • Origine: request

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

      • Parametri 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 che non possono essere utilizzati.

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

    Strumento Traccia

    Per eseguire la convalida utilizzando lo strumento Trace:

    1. Se hai acquisito la traccia per la richiesta non riuscita come spiegato nei passaggi di diagnostica comuni, seleziona una delle richieste con esito negativo.
    2. Se hai stabilito che i parametri del modulo contenenti caratteri che non possono essere utilizzati fanno parte della richiesta HTTP nel passaggio 3 riportato sopra, allora
      1. Vai alla fase Richiesta ricevuta dal client.
      2. Scorri verso il basso fino alla sezione Dettagli fase ed esamina la sezione Richiedi contenuti.

        ( visualizza immagine ingrandita)

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

    Richiesta effettiva

    Per eseguire la convalida 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 effettuata ad Apigee Edge, esegui questi passaggi:
      1. Esamina i contenuti dei dati del modulo e controlla se contengono caratteri che non è possibile utilizzare, ad esempio il segno percentuale (%) o il segno percentuale (%) seguito da caratteri esadecimali non validi.

        Esempio 1

        Richiesta di esempio n. 1: dati del modulo come parte della 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 segno 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
        

        Contenuti 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 segno percentuale (%), che non deve essere passato così com'è nei dati del modulo.

    3. Nei due esempi precedenti, i dati del modulo inviati come parte della richiesta HTTP ad Apigee Edge contengono caratteri che non è consentito utilizzare.
    4. Di conseguenza, 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 del modulo o dei parametri inviati come parte della richiesta HTTP dal client siano sempre codificati come spiegato in Dati del modulo - application/x-www-form-urlcoded.
  2. Per gli esempi illustrati sopra, puoi risolvere i problemi nel seguente modo:

    Esempio 1

    Esempio n. 1: dati del modulo trasmessi come parte della richiesta:

    Utilizza caratteri esadecimali validi corrispondenti al codice ASCII per un carattere specifico. Ad esempio, se vuoi inviare il simbolo del dollaro ($), usa %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
    

    Contenuti di form_data.xml:

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

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

Specifiche

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

Specifiche
Dati del modulo - application/x-www-form-urlcoded

Se hai ancora bisogno di aiuto dall'Assistenza Apigee, vai a Devi raccogliere informazioni diagnostiche.

Devi raccogliere dati diagnostici

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

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

  • Nome dell'organizzazione.
  • Nome ambiente
  • Nome proxy API
  • Comando curl completo 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 Private Cloud, fornisci le seguenti informazioni:

  • Messaggio di errore completo osservato per le richieste non riuscite
  • Nome ambiente
  • Bundle di 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