413 Request Entity Too Large - TooBigBody

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Sintomo

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

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta: 

HTTP/1.1 413 Request Entity Too Large

Potresti inoltre visualizzare il seguente messaggio di errore: 

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

Possibili cause

Questo errore si verifica se la dimensione del payload inviata dall'applicazione client ad Apigee Edge come parte La richiesta HTTP è superiore al limite consentito in Apigee Edge .

Di seguito sono riportate le possibili cause di questo errore :

Causa Descrizione Le istruzioni di risoluzione dei problemi applicabili a
La dimensione del payload della richiesta è superiore al limite consentito La dimensione del payload inviata dall'applicazione client come parte della richiesta HTTP ad Apigee Edge è rispetto al limite consentito in Apigee Edge. Utenti perimetrali di cloud pubblici e privati
La dimensione del payload della richiesta supera il limite consentito dopo decompressione La dimensione del payload inviato in formato compresso dall'applicazione client come parte di HTTP ad Apigee Edge supera il limite consentito quando decompresso da Apigee Edge. Utenti perimetrali di cloud pubblici e privati

Passaggi diagnostici 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 ruolo appropriato.

  2. Passa all'organizzazione in cui vuoi esaminare il problema

  3. Vai al menu Analizza > Monitoraggio delle API > Esamina.
  4. Seleziona il periodo di tempo specifico in cui hai osservato gli errori.
  5. Puoi selezionare il filtro Proxy per restringere il codice di errore.
  6. Traccia il codice di errore in base all'ora.

  7. Seleziona una cella che abbia il codice di errore protocol.http.TooBigBody e Codice di stato 413come mostrato di seguito:

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

  9. Fai clic su Visualizza log ed espandi la riga della richiesta non riuscita. Poi, Log, puoi prendere nota dei dettagli come mostrato di seguito :

    Non compresso

    Scenario 1: richiesta di payload inviato in formato non compresso

    Nella finestra Log, prendi nota dei seguenti dettagli:

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

    Se il campo Origine errore ha il valore proxy , il valore Codice di errore ha il valore protocol.http.TooBigBody e Lunghezza della richiesta è superiore a 10 MB, significa che la richiesta HTTP del client ha un dimensione del payload della richiesta superiore al 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 il campo Origine errore ha il valore proxy , il valore Codice di errore ha il valore protocol.http.TooBigBody e la Lunghezza della richiesta è meno di 10 MB, significa che la richiesta HTTP del client ha un la dimensione del payload della richiesta inferiore al limite consentito nel formato compresso, ma la dimensione del payload è superiore al limite consentito se non compresso da Apigee.

Trace

Per diagnosticare l'errore utilizzando lo strumento Trace:

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

  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: richiesta di payload inviato in formato non compresso

    Prendi in considerazione le seguenti informazioni:

    • Codifica dei contenuti: non presente
    • Content-Length: 15360204

    Compresso

    Scenario 2: payload di richiesta inviato in formato compresso

    Prendi in considerazione le seguenti informazioni:

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

  6. In genere troverai l'errore in un flusso successivo al messaggio Richiesta ricevuta da Fase client come illustrato 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 Risposta inviata al cliente e prendi nota dei valori dell'errore nella traccia. La traccia di esempio riportata di seguito mostra:

    • errore: 413 Request Entity Too Large
    • Contenuti relativi all'errore: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. Vai alla fase AX (dati registrati di Analytics) della traccia e fai clic sulla fase.

  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:
      .
    • Le dimensioni effettive del payload della richiesta quando viene inviato in formato non compresso e
    • Le dimensioni del payload della richiesta al momento della decompressione da parte di Apigee, quando il payload viene inviati in formato compresso. Sarà sempre uguale al valore del campo consentito (10 MB) in questo scenario.
    di Gemini Advanced.

    Non compresso

    Scenario 1: richiesta di payload in formato non compresso

    Variabile client.received.content.length: 15360204

    Compresso

    Scenario 2: richiesta di payload in formato compresso

    Variabile client.received.content.length: 10489856

  12. La tabella seguente spiega perché l'errore 413 viene restituito da Apigee in i due scenari in base al valore della variabile client.received.content.length:
    Scenario Valore di client.received.content.length Motivo dell'errore
    Richiedi payload 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 di accesso NGINX:

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

  2. Controlla i log di accesso NGINX:

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

  3. Cerca per vedere se si sono verificati 413 errori durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste che non hanno ancora avuto esito positivo 413.
  4. Se trovi errori 413 con la corrispondenza X-Apigee-fault-code il valore di protocol.http.TooBigBody, quindi determina il valore X-Apigee-fault-source.

    Non compresso

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

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

    Intestazioni della risposta Valore
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    Tieni presente che Lunghezza della richiesta:15360440 (14,6 MB > limite consentito)

    Compresso

    Scenario 2 : dimensione 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-code

    Intestazioni della risposta Valore
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    Prendi nota della Durata della richiesta:15264 (14,9 K < limite consentito)

    In questo scenario, Apigee Edge restituisce 413 anche se La durata della richiesta è inferiore al limite consentito perché la richiesta potrebbe sono stati inviati in formato compresso e la dimensione del payload supera di decompressione da parte di Apigee Edge.

Causa: la dimensione del payload della richiesta è superiore al limite consentito

Diagnosi

  1. Determina il codice di errore, l'origine errore e la dimensione payload richiesta per il osservato utilizzando i log di accesso di monitoraggio delle API, dello strumento di tracciamento o di NGINX, come spiegato in Passaggi di diagnostica comuni nello scenario n. 1 (non compresso).
  2. Se il campo Origine errore ha il valore policy o proxy, allora indica che la dimensione del payload della richiesta inviata dall'applicazione client ad Apigee è maggiore di il limite consentito in Apigee Edge.
  3. Verifica le dimensioni del payload specificate nel passaggio 1.
  4. Puoi anche convalidare se la dimensione del payload della richiesta è maggiore di Limite consentito di 10 MB di 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, esegui la seguenti passaggi:
      1. Verifica le dimensioni del payload passato nella richiesta.
      2. Se noti che la dimensione del payload è superiore alla dimensione consentito in Apigee Edge, questa è la causa del problema.

        3. Esempio di richiesta:

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

        In questo caso, le dimensioni del file test15mbfile sono di circa 15 MB. Se usi altri client, recupera i log del client per scoprire la dimensione del payload inviato.

Risoluzione

Vai a Risoluzione.

Causa: la dimensione del payload della richiesta supera il limite consentito dopo la decompressione

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

Diagnosi

  1. Determina il codice di errore, l'origine errore e la dimensione del payload della richiesta per l'errore osservato utilizzando i log di monitoraggio delle API, strumento di tracciamento o accesso NGINX, come spiegato in Passaggi di diagnostica comuni nello scenario n. 2 (compresso).
  2. Se il campo Origine errore ha il valore policy o proxy, Ciò indica che la dimensione del payload della richiesta inviata dall'applicazione client ad Apigee è maggiore rispetto al limite consentito in Apigee Edge.
  3. Verifica le dimensioni del payload come stabilito nel passaggio 1.
    • Se la dimensione del payload > Questa è la causa dell'errore.
    • Se la dimensione del payload < di 10 MB, è possibile che la richiesta il payload viene passato in formato compresso. In questo caso, controlla la dimensione non compressa del per le richieste compresse.
  4. Puoi verificare se la richiesta dal client è stata inviata in formato compresso e la dimensione non compressa era superiore al limite consentito utilizzando uno dei seguenti valori: metodo:

    Trace

    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 dal client conteneva il valore Content-Encoding: gzip intestazione
    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, è 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, esegui la seguenti passaggi:
      1. Verifica la dimensione del payload passato nella richiesta insieme alla Intestazione Content-Encoding inviata nella richiesta.

      2. Verifica se la dimensione non compressa del payload è superiore alla limite consentito in Apigee Edge

        Esempio di richiesta:

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

        Nel caso precedente, le dimensioni del file test15mbfile.gz sono inferiori al limite massimo. tuttavia, le dimensioni del file non compresso test15mbfile sono di circa 15 MB e l'intestazione Content-Encoding è gzip.

        Se utilizzi un altro client, recupera i log del client per scoprire la dimensione del payload 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 principali sugli errori HTTP 413.

    2. Controlla i log del processore di messaggi:

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

    3. Controlla se si sono verificati 413 errori durante un periodo di tempo specifico (se problema si è verificato in passato) o se sono presenti richieste che non vanno ancora a buon fine con 413.

      Puoi utilizzare le seguenti stringhe di ricerca:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Troverai righe da system.log simili alla seguente (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 il numero totale byte letti > 10 MB, si ferma e stampa la seguente riga: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Implica che la Dimensione payload della richiesta sia superiore a 10 MB e Apigee genera l'errore RequestTooLarge quando le dimensioni iniziano a superare il limite di 10 MB con codice di errore protocol.http.TooBigBody

Risoluzione

Correggi dimensioni

Opzione 1 [consigliata]: correggi l'applicazione client per non inviare una dimensione del payload superiore a limite consentito

  1. Analizza il motivo per cui il client specifico invia richieste / dimensioni del payload superiori a quanto consentito come definito in Limiti.

  2. Se non è auspicabile, modifica l'applicazione client in modo che invii richiesta / payload sia inferiore al limite consentito.

    Nell'esempio discusso sopra, puoi risolvere il problema trasmettendo un file di dimensioni inferiori, supponiamo che test5mbfile (con dimensioni di 5 MB) abbia come mostrato di seguito: 

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

  3. Se preferisci inviare una richiesta/un payload di importo superiore al limite consentito, vai a le opzioni successive.

Pattern URL firmato

Opzione 2 [consigliata]: utilizza un pattern URL firmato in un callout Java Apigee

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

Streaming

Opzione 3 : usa lo streaming

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

CwC

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

Utilizza questa opzione solo se non puoi usare nessuna delle opzioni consigliate, in quanto problemi di prestazioni se la dimensione predefinita viene aumentata.

Apigee offre CwC, che consente di aumentare il limite di dimensione del payload per le richieste e le risposte. Per maggiori dettagli, consulta Impostare il limite per le 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 payload di dimensioni superiori a il limite consentito come documentato per Request/response size in Limiti di Apigee Edge.

  1. Se sei un utente del cloud pubblico, il limite massimo per richieste e risposte la dimensione del payload è quella documentata per Request/response size in Limiti di Apigee Edge.
  2. Se sei un utente di Private Cloud , potresti aver modificato il valore predefinito limite per le dimensioni del payload di richiesta e risposta (anche se non è una pratica consigliata). Per determinare la dimensione massima del payload di richiesta, segui le istruzioni riportate in Come controllare il limite attuale.

Come si controlla il limite attuale?

Questa sezione spiega come verificare che la proprietà HTTPRequest.body.buffer.limit è stato aggiornato con un nuovo valore per i processori di messaggi.

  1. Cerca la proprietà sul computer HTTPRequest.body.buffer.limit nella directory /opt/apigee/edge-message- processor/conf e controlla quale valore è stato impostato utilizzando il seguente codice : 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Il risultato di esempio dal comando precedente è il seguente: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. Nell'output di esempio precedente, nota che la proprietà HTTPRequest.body.buffer.limit è stato impostato con il valore 10m in http.properties.

    Questo indica che il limite per la dimensione del payload della richiesta configurato in Apigee per i servizi privati Cloud è di 10 MB.

Se hai ancora bisogno di aiuto dall'assistenza Apigee, vai a Devi raccogliere dati diagnostici.

Raccogliere dati diagnostici

Raccogli le seguenti informazioni diagnostiche e contatta l'assistenza Apigee Edge:

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

  • Nome organizzazione
  • Nome ambiente
  • Nome proxy API
  • Completa il comando curl 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
  • Completa il comando curl 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 valori effettivi.

  • Log di sistema del processore di messaggi /opt/apigee/var/log/edge-message-processor/logs/system.log