413 Request Entity Too Large - TooBigBody

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

Sintomo

L'applicazione client riceve un codice di stato HTTP 413 Request Entity Too Large con codice di errore protocol.http.TooBigBody come risposta per le chiamate API.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta: 

HTTP/1.1 413 Request Entity Too Large

Inoltre, potresti visualizzare il seguente messaggio di errore: 

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Possibili cause

Questo errore si verifica se le dimensioni del payload inviate dall'applicazione client ad Apigee Edge nell'ambito della richiesta HTTP superano il limite consentito in Apigee Edge .

Di seguito sono riportate le possibili cause di questo errore :

Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili a
Le dimensioni del payload della richiesta superano il limite consentito Le dimensioni del payload inviate dall'applicazione client nell'ambito della richiesta HTTP ad Apigee Edge superano il limite consentito in Apigee Edge. Utenti di cloud pubblico e privato perimetrale
Le dimensioni del payload della richiesta superano il limite consentito dopo la decompressione Le dimensioni del payload inviate in formato compresso dall'applicazione client nell'ambito della richiesta HTTP ad Apigee Edge superano il limite consentito quando viene decompressa da Apigee Edge. 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. Puoi selezionare il filtro Proxy per restringere il codice di errore.
  6. Traccia Codice di errore su Ora.

  7. Seleziona una cella con il codice di guasto protocol.http.TooBigBody e il codice di stato 413, come mostrato di seguito:

  8. Le informazioni sul codice di errore protocol.http.TooBigBody vengono visualizzate come mostrato di seguito:

  9. Fai clic su Visualizza log ed espandi la riga della richiesta non riuscita. Nella finestra Log, annota i dettagli come mostrato di seguito :

    Non compresso

    Scenario 1: payload di richiesta inviato in formato non compresso

    Nella finestra Log, tieni presente i seguenti dettagli:

    • Codice di stato: 413
    • Origine errore: proxy
    • Codice di errore: protocol.http.TooBigBody.
    • Lunghezza richiesta(byte): 15360440 (~15 MB)

    Se l'Origine dell'errore ha il valore proxy, il Codice di errore ha il valore protocol.http.TooBigBody e la Lunghezza della richiesta è superiore a 10 MB, indica che la richiesta HTTP del client ha una dimensione del payload della richiesta maggiore del limite consentito in Apigee.

    Compresso

    Scenario 2: payload di richiesta inviato in formato compresso

    Nella finestra Log, tieni presente i seguenti dettagli:

    • Codice di stato: 413
    • Origine errore: proxy
    • Codice di errore: protocol.http.TooBigBody.
    • Lunghezza richiesta(byte): 15264 (~15 kB)

    Se l'origine dell'errore ha il valore proxy, il codice di errore ha il valore protocol.http.TooBigBody e la lunghezza della richiesta è inferiore a 10 MB, indica che la richiesta HTTP del client ha una dimensione del payload della richiesta inferiore al limite consentito nel suo formato compresso, ma la dimensione del payload è superiore al limite consentito quando non viene compressa da Apigee.

Traccia

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita la sessione di traccia e
    • Attendi che si verifichi l'errore 413 Request Entity Too Large oppure
    • Se riesci a riprodurre il problema, effettua la chiamata API e riproduci l'errore 413 Request Entity Too Large

  2. Assicurati che l'opzione Mostra tutte le informazioni sul flusso sia attivata.

  3. Seleziona una delle richieste non riuscite ed esamina la traccia.
  4. Vai alla fase Richiesta ricevuta dal client.

    Non compresso

    Scenario 1: payload di richiesta inviato in formato non compresso

    Prendi nota delle seguenti informazioni:

    • Content-Encoding: non presente
    • Content-Length: 15360204

    Compresso

    Scenario 2: payload di richiesta inviato in formato compresso

    Prendi nota delle seguenti informazioni:

    • Codifica dei contenuti: gzip
    • Content-Length: 14969
    • Tipo di contenuto: application/x-gzip
  5. Naviga tra le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.

  6. In genere, l'errore si verifica in un flusso successivo alla fase Richiesta ricevuta dal client, come mostrato di seguito:

  7. Prendi nota del valore dell'errore della traccia. La traccia di esempio riportata sopra mostra:
    • errore: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. Vai a Response sent to Client (Risposta inviata al client) e prendi nota dei valori dell'errore della traccia. La traccia di esempio riportata di seguito mostra:

    • errore: 413 Request Entity Too Large
    • Contenuto dell'errore: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. Vai alla fase AX (Analytics Data Recorded) della traccia e fai clic su quest'ultima.

  10. Nella sezione Dettagli fase, scorri verso il basso fino a Lettura variabili.

  11. Determina il valore della variabile client.received.content.length , che indica:
    • La dimensione effettiva del payload della richiesta quando viene inviato in formato non compresso.
    • Le dimensioni del payload della richiesta al momento della decompressione da parte di Apigee, quando il payload viene inviato in formato compresso. In questo scenario, il valore sarà sempre uguale al valore del limite consentito (10 MB).

    Non compresso

    Scenario 1: payload di richiesta in formato non compresso

    Variabile client.received.content.length: 15360204

    Compresso

    Scenario 2: payload di richieste in formato compresso

    Variabile client.received.content.length: 10489856

  12. La tabella seguente spiega perché l'errore 413 viene restituito da Apigee nei due scenari in base al valore della variabile client.received.content.length:
    Scenario Valore di client.received.content.length Motivo dell'errore
    Payload della richiesta in formato non compresso ~15 MB Dimensioni > limite consentito di 10 MB.
    Payload della richiesta in formato compresso ~10 MB

    Limite di dimensioni superato al momento della decompressione

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 sugli errori HTTP 413.

  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 413 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 413.
  4. Se riscontri errori 413 con X-Apigee-fault-code corrispondente al valore di protocol.http.TooBigBody, determina il valore di X-Apigee-fault-source.

    Non compresso

    Scenario 1 : richiesta di dimensioni del payload in formato non compresso

    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 della risposta Valore
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    Prendi nota della Lunghezza richiesta: 15360440 (14,6 MB > limite consentito)

    Compresso

    Scenario 2 : richiesta di dimensioni del payload in formato compresso

    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 della risposta Valore
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    Prendi nota della Lunghezza richiesta: 15264 (14.9 K < limite consentito)

    In questo scenario, Apigee Edge restituisce 413 anche se la lunghezza della richiesta è inferiore al limite consentito perché la richiesta potrebbe essere stata inviata in formato compresso e le dimensioni del payload superano il limite al momento della decompressione da parte di Apigee Edge.

Causa: le dimensioni del payload della richiesta superano il limite consentito

Diagnostica

  1. Determina il codice di errore, l'origine dell'errore e la dimensione payload della richiesta per l'errore osservato utilizzando i log di accesso di API Monitoring, Trace Tool o NGINX, come spiegato nella sezione Passaggi comuni di diagnosi per lo scenario n. 1 (non compresso).
  2. Se l'Origine dell'errore ha il valore policy o proxy, questo indica che la dimensione del payload della richiesta inviata dall'applicazione client ad Apigee è superiore al limite consentito in Apigee Edge.
  3. Verifica le dimensioni del payload come stabilito nel passaggio 1.
  4. Puoi anche verificare se le dimensioni del payload della richiesta superano effettivamente il limite consentito di 10 MB controllando la richiesta effettiva seguendo questi passaggi:
    1. Se non hai accesso alla richiesta effettiva effettuata dall'applicazione client, vai a Risoluzione.
    2. Se hai accesso alla richiesta effettiva effettuata dall'applicazione client, segui questi passaggi:
      1. Verifica le dimensioni del payload passato nella richiesta.
      2. Se noti che le dimensioni del payload superano il limite consentito in Apigee Edge, allora questa è la causa del problema.

        3. Esempio di richiesta:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        Nel caso precedente, le dimensioni del file test15mbfile sono di circa 15 MB. Se utilizzi un altro client, recupera i log del client per individuare le dimensioni del payload inviate.

Risoluzione

Vai a Risoluzione.

Causa: le dimensioni del payload della richiesta superano il limite consentito dopo la decompressione

Se il payload della richiesta viene inviato in formato compresso e l'intestazione della richiesta Content-Encoding è impostata su gzip, Apigee decomprime il payload della richiesta. Durante il processo di decompressione, se Apigee rileva che le dimensioni del payload sono superiori a 10 MB, il limite consentito, interrompe un'ulteriore decompressione e risponde immediatamente con 413 Request Entity Too Large con il codice di errore protocol.http.TooBigBody.

Diagnostica

  1. Determina il codice di errore, l'origine dell'errore e la dimensione payload della richiesta per l'errore osservato utilizzando i log di accesso dell'API, Trace Tool o NGINX, come spiegato nella sezione Passaggi comuni di diagnosi con lo scenario n. 2 (compresso).
  2. Se l'Origine dell'errore ha il valore policy o proxy, questo indica che la dimensione del payload della richiesta inviata dall'applicazione client ad Apigee è superiore al limite consentito in Apigee Edge.
  3. Verifica le dimensioni del payload della richiesta come stabilito nel passaggio 1.
    • Se le dimensioni del payload superano il limite consentito di 10 MB, allora questa è la causa dell'errore.
    • Se la dimensione del payload è inferiore a 10 MB rispetto al limite consentito, è possibile che il payload della richiesta venga passato in formato compresso. In questo caso, controlla le dimensioni non compresse del payload della richiesta compressa.
  4. Per verificare se la richiesta del client è stata inviata in formato compresso e se le dimensioni non compresse sono superiori al limite consentito, utilizza uno dei seguenti metodi:

    Traccia

    Per eseguire la convalida utilizzando lo strumento Trace:

    1. Se hai acquisito una traccia per la richiesta non riuscita, fai riferimento ai passaggi descritti in Trace e
      1. Determina il valore della variabile client.received.content.length .
      2. Verifica se la richiesta del client conteneva l'intestazione Content-Encoding: gzip
    2. Se il valore della variabile client.received.content.length è superiore a 10 MB, al limite consentito e all'intestazione della richiesta Content-Encoding: gzip, questa è la causa dell'errore.

    Richiesta effettiva

    Per eseguire la convalida utilizzando la richiesta effettiva:

    1. Se non hai accesso alla richiesta effettiva effettuata dall'applicazione client, vai a Risoluzione.
    2. Se hai accesso alla richiesta effettiva effettuata dall'applicazione client, segui questi passaggi:
      1. Verifica la dimensione del payload passato nella richiesta insieme all'intestazione Content-Encoding inviata nella richiesta.

      2. Verifica se le dimensioni non compresse del payload superano il limite consentito in Apigee Edge

        Richiesta di esempio:

        curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v

        Nel caso precedente, il file test15mbfile.gz è inferiore al limite di dimensioni; tuttavia, la dimensione del file non compresso test15mbfile è di circa 15 MB e l'intestazione Content-Encoding è gzip.

        Se utilizzi un altro client, recupera i log del client per scoprire le dimensioni del payload inviate e se l'intestazione Content-Encoding è impostata su gzip.

    Log del processore di messaggi

    Per eseguire la convalida utilizzando i log del processore di messaggi:

    1. Se sei un utente Private Cloud, puoi utilizzare i log del processore di messaggi per determinare le informazioni chiave sugli errori HTTP 413.

    2. Controlla i log del processore di messaggi:

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

    3. Cerca per vedere se si sono verificati errori 413 durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non funzionare con 413.

      Puoi utilizzare le seguenti stringhe di ricerca:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Troverai righe da system.log simili alle seguenti (TotalRead e chunkCount potrebbero variare nel tuo caso): 
      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
    5. Durante il processo di decompressione, non appena il processore di messaggi stabilisce che il totale dei byte letti è maggiore di 10 MB, si interrompe e stampa la riga seguente: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Ciò implica che la dimensione payload della richiesta è superiore a 10 MB e Apigee genera l'errore RequestTooLarge quando la dimensione inizia a superare il limite di 10 MB con codice di errore protocol.http.TooBigBody

Risoluzione

Correggi dimensione

Opzione 1 [consigliata]: correggi l'applicazione client in modo che non invii dimensioni del payload superiori al limite consentito

  1. Analizza il motivo per cui il client specifico ha inviato le dimensioni della richiesta / del payload oltre il limite consentito come definito in Limiti.

  2. Se non è appropriato, modifica la tua applicazione client in modo che invii una dimensione della richiesta / del payload inferiore al limite consentito.

    Nell'esempio discusso sopra, puoi risolvere il problema passando un file di dimensioni inferiori, ad esempio test5mbfile (con dimensioni pari a 5 MB), come mostrato di seguito: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v

  3. Se è opportuno e vuoi inviare una richiesta/payload superiore al limite consentito, vai alle opzioni successive.

Pattern URL firmato

Opzione 2 [consigliata]: utilizza il pattern di URL firmati all'interno di un JavaCallout Apigee

Per payload superiori a 10 MB, Apigee consiglia di utilizzare un pattern URL firmato all'interno di un JavaCallout di Apigee, illustrato dall'esempio Edge Callout: Signed URL Generator su GitHub.

live streaming

Opzione 3 : utilizza lo streaming

Se il tuo proxy API deve gestire richieste e/o risposte molto grandi, puoi abilitare i flussi di dati in Apigee.

CwC

Opzione 4 : utilizza la proprietà CwC per aumentare il limite del buffer

Questa opzione deve essere utilizzata solo se non è possibile utilizzare nessuna delle opzioni consigliate, in quanto potrebbero verificarsi problemi di prestazioni se viene aumentata la dimensione predefinita.

Apigee fornisce una proprietà CwC che consente di aumentare il limite di dimensione del payload di richieste e risposte. Per maggiori dettagli, consulta Impostare il limite di dimensioni dei messaggi sul router o sul processore di messaggi

Limiti

Apigee si aspetta che l'applicazione client e il server di backend non inviino dimensioni dei payload superiori al limite consentito come documentato per Request/response size in Apigee Edge Limits.

  1. Se sei un utente del cloud pubblico, il limite massimo per le dimensioni del payload di richiesta e risposta è come documentato per Request/response size in Limiti di Apigee Edge.
  2. Se sei un utente Private Cloud , potresti aver modificato il limite predefinito per le dimensioni del payload delle richieste e delle risposte (anche se non è una pratica consigliata). Puoi determinare il limite massimo della dimensione del payload delle richieste seguendo le istruzioni in Come verificare il limite attuale.

Come si controlla il limite attuale?

Questa sezione spiega come verificare che la proprietà HTTPRequest.body.buffer.limit sia stata aggiornata con un nuovo valore nei processori di messaggi.

  1. Nel computer del processore di messaggi, cerca la proprietà HTTPRequest.body.buffer.limit nella directory /opt/apigee/edge-message- processor/conf e controlla quale valore è stato impostato utilizzando il seguente comando: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Il risultato di esempio del comando riportato sopra è il seguente: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. Nell'output di esempio riportato sopra, nota che la proprietà HTTPRequest.body.buffer.limit è stata impostata con il valore 10m in http.properties.

    Questo indica che il limite per le dimensioni del payload delle richieste configurate in Apigee per il cloud privato è di 10 MB.

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

Devi raccogliere dati diagnostici

Raccogli le seguenti informazioni diagnostiche e poi 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 l'errore 413
  • 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 dell'organizzazione.
  • Nome ambiente
  • Bundle del proxy API
  • File di traccia per le richieste API non riuscite
  • Comando curl completo utilizzato per riprodurre l'errore 413

  • 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