502 Bad Gateway - 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 502 Bad Gateway 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 502 Bad Gateway

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 dal server di destinazione/backend ad Apigee Edge come parte della risposta HTTP sono superiori al limite consentito in Apigee Edge.

Ecco le possibili cause dell'errore:

Passaggi di diagnostica comuni

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

Causa: le dimensioni del payload della risposta sono superiori al limite consentito

Diagnosi

1. Determina il codice di errore, l'origine dell'errore e le dimensioni del payload di risposta per l'errore osservato utilizzando API Monitoring, lo strumento Trace o i log di accesso NGINX come spiegato in Passaggi comuni per la diagnosi con lo scenario n. 1.
2. Se l'origine dell'errore ha il valore target, significa che le dimensioni del payload della risposta inviata dal server di destinazione/backend ad Apigee sono superiori al limite consentito in Apigee Edge.
3. Verifica le dimensioni del payload della risposta 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 circa 10 MB, il limite consentito, è possibile che il payload della risposta venga passato in formato compresso. Vai a Causa: le dimensioni del payload della risposta superano il limite consentito dopo la decompressione.
4. Verifica che le dimensioni del payload della risposta siano effettivamente superiori al limite consentito di 10 MB controllando la risposta effettiva seguendo questi passaggi:
   1. Se non hai accesso alla richiesta effettiva inviata al server di destinazione/backend, vai a Risoluzione.
   2. Se hai accesso alla richiesta effettiva inviata al server di destinazione/backend, esegui i seguenti passaggi:
      1. Se sei un utente di cloud pubblico/cloud privato, invia una richiesta direttamente al server di backend dal server di backend stesso o da qualsiasi altra macchina da cui ti è consentito inviare la richiesta al server di backend.
      2. Se sei un utente di Private Cloud, puoi anche inviare la richiesta al server di backend da uno dei Message Processor.
      3. Verifica le dimensioni del payload passato nella risposta controllando l'intestazione Content-Length.
      4. Se le dimensioni del payload superano il limite consentito in Apigee Edge, questo è il motivo del problema.

   Esempio di risposta dal server di backend:

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>

   Nell'esempio precedente, puoi notare che Content-Length: 11534336 (which is ~11 MB) è la causa di questo errore, in quanto supera il limite consentito in Apigee Edge.

Risoluzione

Fai riferimento alla sezione Risoluzione.

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

Se il payload della risposta viene inviato in formato compresso e l'intestazione della risposta Content-Encoding è impostata su gzip, , Apigee decomprime il payload della risposta. Durante il processo di decompressione, se Apigee rileva che le dimensioni del payload sono superiori al limite consentito in Apigee Edge, interrompe l'ulteriore decompressione e risponde immediatamente con 502 Bad Gateway e il codice di errore protocol.http.TooBigBody.

Diagnosi

1. Determina il codice di errore,l'origine dell'errore e le dimensioni del payload di risposta 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.
2. Se Fault Source ha il valore target, significa che le dimensioni del payload di risposta inviato dall'applicazione di destinazione/backend ad Apigee sono maggiori del limite consentito in Apigee Edge.
3. Verifica le dimensioni del payload della risposta 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 pari al limite consentito di circa 10 MB, è possibile che il payload della risposta venga trasmesso in formato compresso. In questo caso, controlla le dimensioni non compresse del payload della risposta compressa.
4. Puoi verificare se la risposta dalla destinazione/dal backend è stata inviata in formato compresso e se la dimensione non compressa era superiore al limite consentito utilizzando uno dei seguenti metodi:

   Traccia

   Utilizzo dello strumento Traccia:

   1. Se hai acquisito una traccia per la richiesta non riuscita, consulta i passaggi descritti in Traccia e
      1. Determina il valore di target.received.content.length
      2. Verifica se la richiesta del client conteneva l'intestazione Content-Encoding: gzip
   2. Se il valore di target.received.content.length è vicino al limite consentito di 10 MB e l'intestazione della risposta Content-Encoding: gzip, allora questa è la causa dell'errore.

   Richiesta effettiva

   Utilizzo della richiesta effettiva:

   1. Se non hai accesso alla richiesta effettiva inviata al server di destinazione/backend, vai a Risoluzione.
   2. Se hai accesso alla richiesta effettiva inviata al server di destinazione/backend, esegui i seguenti passaggi:
      1. Verifica le dimensioni del payload passato nella risposta insieme all'intestazione Content-Encoding inviata nella risposta.
      2. Se noti che l'intestazione della risposta Content-Encoding è impostata su gzip e le dimensioni non compresse del payload sono superiori al limite consentito in Apigee Edge, questo è il motivo dell'errore.

         Risposta di esempio ricevuta dal server di backend:

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>

         Nell'esempio precedente, l'intestazione Content-Encoding: gzip viene inviata e le dimensioni del file testzippedfile.gz nella risposta sono inferiori al limite, tuttavia le dimensioni del file decompresso testzippedfile erano circa 15 MB.

   Log del processore di messaggi

   Utilizzo dei log del processore di messaggi:

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

   2. Controllare i log del processore di messaggi

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

   3. Cerca per verificare se si sono verificati errori 502 durante un periodo di tempo specifico (se il problema si è verificato in passato) o se alcune richieste continuano a non riuscire con 502. Puoi utilizzare le seguenti stringhe di ricerca:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. Troverai righe da system.log simili a quelle mostrate di seguito (TotalRead e chunkCount potrebbero variare nel tuo caso):

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      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 2571

      Ciò implica che le dimensioni del payload di risposta sono superiori a 10 MB e Apigee genera l'errore quando le dimensioni iniziano a superare il limite di 10 MB con il codice di errore protocol.http.TooBigBody

Risoluzione

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.

1. 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.
2. Se sei un utente di Private Cloud , potresti aver modificato il limite massimo 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à HTTPResponse.body.buffer.limit sia stata aggiornata con un nuovo valore nei processori di messaggi.

1. Sulla macchina processore di messaggi, cerca la proprietà HTTPResponse.body.buffer.limit nella directory /opt/apigee/edge-message- processor/conf e controlla il valore impostato come mostrato di seguito:

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. Il risultato di esempio del comando precedente è il seguente:

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

3. Nell'output di esempio riportato sopra, nota che la proprietà HTTPResponse.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 502
• File di traccia per le richieste API
• Output completo della risposta dal server di destinazione/backend insieme alle dimensioni del payload

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 502
• Output completo della risposta dal server di destinazione/backend insieme alle dimensioni del payload

• 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