Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

413 Request Entity Too Large - TooBigBody

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

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 inviato dall'applicazione client ad Apigee Edge nell'ambito della richiesta HTTP sono superiori al limite consentito in Apigee Edge .

Ecco le possibili cause di questo errore :

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Le dimensioni del payload della richiesta sono superiori al limite consentito	Le dimensioni del payload inviato dall'applicazione client come parte della richiesta HTTP ad Apigee Edge sono superiori al limite consentito in Apigee Edge.	Utenti di Edge Public e Private Cloud
Le dimensioni del payload della richiesta superano il limite consentito dopo la decompressione	La dimensione del payload inviato in formato compresso dall'applicazione client nell'ambito della richiesta HTTP ad Apigee Edge è superiore al limite consentito quando viene decompresso da Apigee Edge.	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:

Accedi alla UI di Apigee Edge come utente con un ruolo appropriato.
Passa all'organizzazione in cui vuoi esaminare il problema.
Vai alla pagina Analizza > Monitoraggio API > Esamina.
Seleziona il periodo di tempo specifico in cui hai osservato gli errori.
Puoi selezionare il filtro Proxy per restringere il codice di errore.
Traccia il codice di errore rispetto al tempo.
Seleziona una cella con Fault Code (Codice errore) protocol.http.TooBigBody e Status Code (Codice di stato) 413come mostrato di seguito:
Le informazioni sul codice di errore protocol.http.TooBigBody vengono visualizzate come mostrato di seguito:
Fai clic su Visualizza log ed espandi la riga della richiesta non riuscita. Quindi, dalla finestra Log, prendi nota dei dettagli come mostrato di seguito :
Non compresso

Scenario 1: payload della richiesta inviato in formato non compresso

Nella finestra Log, prendi nota dei seguenti dettagli:
- Codice di stato: 413
- Origine del guasto: proxy
- Codice errore: protocol.http.TooBigBody.
- Lunghezza della richiesta(byte): 15360440 (~15 MB)
Se Fault Source ha il valore proxy, Fault Code ha il valore protocol.http.TooBigBody e Request Length è superiore a 10 MB, significa che la richiesta HTTP dal client ha una dimensione del payload della richiesta superiore al limite consentito in Apigee.
Compresso

Scenario n. 2: payload della richiesta inviato in formato compresso

Nella finestra Log, prendi nota dei seguenti dettagli:
- Codice di stato: 413
- Origine del guasto: proxy
- Codice errore: protocol.http.TooBigBody.
- Lunghezza richiesta(byte): 15264 (~15 kB)
Se Fault Source ha il valore proxy, Fault Code ha il valore protocol.http.TooBigBody e Request Length è inferiore a 10 MB, significa che la richiesta HTTP dal client ha una dimensione del payload della richiesta inferiore al limite consentito nel formato compresso, ma la dimensione del payload è superiore al limite consentito quando viene decompresso da Apigee.

Traccia

Per diagnosticare l'errore utilizzando lo strumento Trace:

Attiva l'opzione Traccia sessione e
- Attendi che si verifichi l'errore 413 Request Entity Too Large o
- Se riesci a riprodurre il problema, effettua la chiamata API e riproduci l'errore 413 Request Entity Too Large.
Assicurati che l'opzione Mostra tutte le informazioni sul flusso sia attivata.
Seleziona una delle richieste non riuscite ed esamina la traccia.
Vai alla fase Richiesta ricevuta dal cliente.
Non compresso

Scenario 1: payload della richiesta inviato in formato non compresso

Tieni presente le seguenti informazioni:
- Content-Encoding:non presente
- Content-Length: 15360204
Compresso

Scenario n. 2: payload della richiesta inviato in formato compresso

Tieni presente le seguenti informazioni:
- Content-Encoding: gzip
- Content-Length: 14969
- Content-Type: application/x-gzip
Esamina le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.
In genere, l'errore si verifica in un flusso dopo la fase Richiesta ricevuta dal client, come mostrato di seguito:
Prendi nota del valore dell'errore dalla traccia. La traccia di esempio riportata sopra mostra:
- Errore: Body buffer overflow
- error.class: com.apigee.errors.http.user.RequestTooLarge
Vai a Response Sent to Client (Risposta inviata al client) e prendi nota dei valori dell'errore dalla traccia. La traccia di esempio riportata di seguito mostra:
- Errore: 413 Request Entity Too Large
- Contenuti errore: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
Vai alla fase AX (Analytics Data Recorded) nella traccia e fai clic.
Nella sezione Dettagli fase, scorri verso il basso fino a Variabili lette.
Determina il valore della variabile client.received.content.length , che indica:
- Le dimensioni effettive del payload della richiesta quando viene inviato in formato non compresso e
- Le dimensioni del payload della richiesta dopo la decompressione da parte di Apigee, quando il payload viene inviato in formato compresso. Sarà sempre uguale al valore del limite consentito (10 MB) in questo scenario.
Nota:potrebbe essere presente un'intestazione di errore Content-Length che indica le dimensioni del payload di errore e non del payload della richiesta. Per questo errore dobbiamo considerare il valore specificato nella variabile client.received.content.length .

Non compresso

Scenario 1: payload della richiesta in formato non compresso

Variabile client.received.content.length: 15360204

Compresso

Scenario 2: payload della richiesta in formato compresso

Variabile client.received.content.length: 10489856

La tabella seguente spiega perché Apigee restituisce l'errore 413 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 dopo la decompressione Nota:le dimensioni effettive del payload dopo la decompressione potrebbero essere molto superiori a 10 MB. Tuttavia, Apigee interrompe la decompressione non appena le dimensioni dei dati non compressi superano il limite di 10 MB (limite predefinito) e risponde con l'errore.

NGINX

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

Se sei un utente di Private Cloud, puoi utilizzare i log di accesso NGINX per determinare le informazioni chiave sugli errori HTTP 413.
Controlla i log di accesso di NGINX:

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

Nota:sostituisci ORG, ENV e PORT# con i valori effettivi.
Cerca per verificare se si sono verificati errori 413 durante un periodo di tempo specifico (se il problema si è verificato in passato) o se alcune richieste continuano a non riuscire con 413.

Se trovi errori 413 con X-Apigee-fault-code che corrisponde al valore di protocol.http.TooBigBody, determina il valore di X-Apigee-fault-source.

Non compresso

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

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

Nota Lunghezza richiesta: 15360440 (14,6 MB > limite consentito)

Compresso

Scenario 2 : dimensioni del payload della richiesta in formato compresso

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

Nota: 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 dopo la decompressione da parte di Apigee Edge.

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

Diagnosi

Determina Fault Code, Fault Source e Request Payload Size per l'errore osservato utilizzando API Monitoring, Trace Tool o i log di accesso NGINX, come spiegato in Passaggi comuni per la diagnosi con lo scenario n. 1 (non compresso).
Se Fault Source ha il valore policy o proxy, significa che le dimensioni del payload della richiesta inviata dall'applicazione client ad Apigee sono superiori al limite consentito in Apigee Edge.
Verifica le dimensioni del payload della richiesta come determinato nel passaggio 1.
- Se la dimensione del payload è superiore al limite consentito di 10 MB, questo è il motivo dell'errore.
- Se le dimensioni del payload sono inferiori al limite consentito di 10 MB, è possibile che il payload della richiesta venga passato in formato compresso. Vai a Causa: le dimensioni del payload della richiesta superano il limite consentito dopo la decompressione
Puoi anche verificare se le dimensioni del payload della richiesta sono effettivamente superiori al 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 le dimensioni del payload superano il limite consentito in Apigee Edge, questo è il motivo del problema.

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 l'ulteriore decompressione e risponde immediatamente con 413 Request Entity Too Large con codice di errore protocol.http.TooBigBody.

Diagnosi

Determina Fault Code, Fault Source, e Request Payload size per l'errore osservato utilizzando API Monitoring, Trace Tool o i log di accesso NGINX come spiegato in Passaggi comuni per la diagnosi con lo scenario n. 2 (compresso).
Se Fault Source ha il valore policy o proxy, significa che le dimensioni del payload della richiesta inviato dall'applicazione client ad Apigee sono superiori al limite consentito in Apigee Edge.
Verifica le dimensioni del payload della richiesta come determinato nel passaggio 1.
- Se la dimensione del payload è superiore al limite consentito di 10 MB, questo è il motivo dell'errore.
- Se le dimensioni del payload sono inferiori al limite consentito di 10 MB, è possibile che il payload della richiesta venga passato in formato compresso. In questo caso, controlla le dimensioni non compresse del payload della richiesta compressa.
Puoi verificare se la richiesta del client è stata inviata in formato compresso e se la dimensione non compressa era superiore al limite consentito utilizzando uno dei seguenti metodi:
Traccia

Per eseguire la convalida utilizzando lo strumento Traccia:
1. Se hai acquisito una traccia per la richiesta non riuscita, consulta i passaggi descritti in Traccia 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 è maggiore di 10 MB, il limite consentito e l'intestazione della richiesta Content-Encoding: gzip, allora questo è il motivo dell'errore.
Richiesta effettiva

Per convalidare utilizzando la richiesta effettiva:
1. Se non hai accesso alla richiesta effettiva effettuata dall'applicazione client, vai alla sezione Risoluzione.
2. Se hai accesso alla richiesta effettiva effettuata dall'applicazione client, segui questi passaggi:
  1. Verifica le dimensioni 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
    
    Nell'esempio precedente, il file test15mbfile.gz è inferiore al limite di dimensioni; tuttavia, le dimensioni del file decompresso test15mbfile sono 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 inviato e se l'intestazione Content-Encoding è impostata su gzip.
Log del processore di messaggi

Per la convalida utilizzando i log del processore di messaggi:

Nota: le istruzioni in questa sezione sono solo per gli utenti di Edge Private Cloud.
1. Se sei un utente di 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 eventuali errori 413 durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono ancora presenti richieste non riuscite con 413.
  
  Puoi utilizzare le seguenti stringhe di ricerca:
  grep -ri "chunkCount"
  grep -ri "RequestTooLarge"
4. Troverai righe di 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 determina che i byte letti totali sono > 10 MB, si arresta e stampa la seguente riga:
  Message is too large. TotalRead 10489856 chunkCount 2570
  Ciò implica che la dimensione del 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
  
  Nota:vedrai la riga precedente nei log del processore di messaggi, anche se invii il payload della richiesta in formato non compresso. L'unica differenza è che TotalRead conterrà le dimensioni effettive del payload della richiesta in questo scenario.

Risoluzione

Dimensioni fisse

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

Analizza il motivo per cui il client specifico invia dimensioni di richiesta / payload superiori al limite consentito come definito in Limiti.
Se non è auspicabile, modifica l'applicazione client in modo che invii richieste / payload di dimensioni inferiori al limite consentito.

Nell'esempio discusso in precedenza, 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
```
Se è auspicabile e vuoi inviare una richiesta/payload superiore al limite consentito, vai alle opzioni successive.

Pattern URL firmato

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

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

Streaming

Opzione 3 : utilizza lo streaming

Se il proxy API deve gestire richieste e/o risposte di dimensioni molto grandi, puoi abilitare lo streaming in Apigee.

CwC

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

Questa opzione deve essere utilizzata solo quando non è possibile utilizzare nessuna delle opzioni consigliate, in quanto potrebbero verificarsi problemi di prestazioni se le dimensioni predefinite vengono aumentate.

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

Limiti

Apigee prevede che l'applicazione client e il server di backend non inviino dimensioni del payload superiori al limite consentito, come documentato per Request/response size in Limiti di Apigee Edge.

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

Come faccio a controllare 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.

Sulla macchina processore di messaggi, cerca la proprietà HTTPRequest.body.buffer.limit nella directory /opt/apigee/edge-message- processor/conf e controlla il valore impostato utilizzando il seguente comando:
```
grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
```

Il risultato di esempio del comando precedente è il seguente:

/opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

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

Ciò indica che il limite per le dimensioni del payload della richiesta configurato in Apigee per Private Cloud è 10 MB.

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

Deve raccogliere informazioni diagnostiche

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
Comando curl completo utilizzato per riprodurre l'errore 413
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 organizzazione
Nome ambiente
Bundle proxy API
File di traccia per le richieste API non riuscite
Comando curl completo utilizzato per riprodurre l'errore 413
Log di accesso 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

413 Request Entity Too Large - TooBigBody

Sintomo

Messaggio di errore

Possibili cause

Passaggi di diagnostica comuni

Monitoraggio delle API

Non compresso

Compresso

Traccia

Non compresso

Compresso

Non compresso

Compresso

NGINX

Non compresso

Compresso

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

Diagnosi

Risoluzione

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

Diagnosi

Traccia

Richiesta effettiva

Log del processore di messaggi

Risoluzione

Dimensioni fisse

Pattern URL firmato

Streaming

CwC

Limiti

Come faccio a controllare il limite attuale?

Deve raccogliere informazioni diagnostiche