400 Richiesta errata - DecompressionFailureAtRequest

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 400 Bad Request con codice di errore messaging.adaptors.http.flow.DecompressionFailureAtRequest in risposta all'API chiamate.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 400 Bad Request

Inoltre, potresti visualizzare un messaggio di errore simile a quello mostrato di seguito:

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

Possibili cause

Questo errore si verifica solo se:

• La codifica specificata nell'intestazione della richiesta HTTP Content-Encoding è valido e supportata da Apigee Edge,

MA

• Il formato del payload inviato dal client come parte della richiesta HTTP corrisponde al formato di codifica specificato nell'intestazione Content-Encoding

Questo perché Apigee Edge non riesce a decodificare il payload utilizzando la codifica specificata, poiché del payload non sia nello stesso formato della codifica specificata nel Intestazione Content-Encoding.

Ecco alcuni esempi di valori Content-Encoding supportati e di come Apigee Edge prevede che il formato del payload sia in questi casi:

Scenario	Content-Encoding	Formato payload previsto
Codifica singola	gzip	Il formato Unix gzip. Consulta Formato GZIP RFC1952.
Codifica singola	sgonfiare	Questo formato utilizza la struttura zlib con algoritmo di compressione deflate. Vedi RFC1950 e . RFC1951.
Codifica multipla	Codifica multipla Ad esempio, nei casi in cui la codifica viene eseguita due volte, i casi possono essere: gzip, deflate gzip, gzip deflate, gzip sgonfiare, sgonfiare	Più codifiche applicate al payload nell'ordine dato come appare nell'intestazione.

Le possibili cause di questo errore sono le seguenti:

Causa	Descrizione	Le istruzioni di risoluzione dei problemi applicabili a
Il formato del payload della richiesta non corrisponde alla codifica specificata nell'intestazione Content-Encoding	Il formato del payload della richiesta inviato dal client non è codificato o corrispondono alla codifica specificata nell'intestazione Content-Encoding.	Utenti perimetrali di cloud pubblici e privati

Passaggi diagnostici comuni

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

Causa: il formato del payload della richiesta non corrisponde alla codifica specificata nell'intestazione Content-Encoding

Per impostazione predefinita, Apigee Edge decomprime sempre il payload se l'intestazione della richiesta Content-Encoding contiene un valore valido e un supportata. Pertanto, si prevede che il formato del payload della richiesta deve corrispondere alla codifica specificata nell'intestazione della richiesta Content-Encoding. In caso di mancata corrispondenza, viene visualizzato questo errore.

Diagnosi

1. Determinare il codice di errore e l'origine errore per l'errore osservato utilizzando l'API Monitoraggio, log di accesso dello strumento Trace o NGINX come spiegato in Passaggi comuni per la diagnosi.
2. Se il codice di errore è messaging.adaptors.http.flow.DecompressionFailureAtRequest e Origine errore ha il valore policy o proxy, questo valore indica che la richiesta inviata dall'applicazione client ha un payload che non corrisponde codifica supportata specificata nell'intestazione della richiesta Content-Encoding.

3. Puoi determinare la mancata corrispondenza come parte della richiesta HTTP utilizzando uno dei seguenti metodo:

   Messaggio di errore

   Per eseguire la convalida utilizzando il messaggio di errore:

   1. Se hai accesso al messaggio di errore completo ricevuto da Apigee Edge, consulta il faultstring.

      Esempio di messaggio di errore:

      "faultstring":"Decompression failure at request"
      

   2. Nel messaggio di errore riportato sopra, viene visualizzato "Decompression failure at request", che implica che la richiesta non possono essere decompressi utilizzando la codifica specificata nel Content-Encoding intestazione.

   Trace

   Per eseguire la convalida utilizzando Trace:

   1. Determina il valore dell'intestazione della richiesta Content-Encoding e proprietà error.cause utilizzando Trace come spiegato in Passaggi comuni della diagnostica.

   2. I valori della traccia di esempio sono i seguenti:

      • Codifica dei contenuti: gzip
      • error.cause: Not in GZIP format

      Il valore nell'intestazione della richiesta Content-Encoding è gzip; tuttavia, il payload della richiesta non è in formato GZIP (come indicato da error.cause). Pertanto, Apigee Edge risponde 400 Bad Request e codice di errore messaging.adaptors.http.flow.DecompressionFailureAtRequest.

   Richiesta effettiva

   Per eseguire la convalida utilizzando la richiesta effettiva:

   Se hai accesso alla richiesta effettiva effettuata dal client dell'applicazione, segui questi passaggi:

   1. Determina il valore passato all'intestazione della richiesta Content-Encoding.
   2. Determina il formato del payload inviato come parte della richiesta.

   3. Se il valore dell'intestazione Content-Encoding è nell'elenco di supportata, ma il formato del payload della richiesta non corrispondono alla codifica specificata nell'intestazione Content-Encoding, questa è la causa del problema.

      Esempio di richiesta:

      curl -v "http://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.zip
      

      La richiesta di esempio riportata sopra invia il valore gzip al Content-Encoding, che è un'intestazione . supportata in Apigee Edge. Tuttavia, il payload della richiesta request_payload.zip è in formato ZIP. Pertanto, questa richiesta non riesce con il codice di stato 400 Bad Request e il codice di errore: messaging.adaptors.http.flow.DecompressionFailureAtRequest.

   Log del processore di messaggi

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

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

   1. Determinare l'ID messaggio della richiesta non riuscita utilizzando API Monitoring, lo strumento Trace o NGINX, come spiegato nella sezione Passaggi di diagnostica comuni.

   2. Cerca l'ID messaggio nel log del processore di messaggi:

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

   3. Verrà visualizzata una delle seguenti eccezioni:

      Scenario 1

      Scenario 1: quando la richiesta API ha l'intestazione Content-Encoding: gzip

      2021-07-28 10:21:16,861  NIOThread@0 ERROR HTTP.SERVER -
      HTTPServer$Context.onInputException() : Message id:rt-57-1
      SSLClientChannel[Accepted: Remote:192.168.199.8:8443
      Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0
      bytesWritten=28764 age=2739893ms  lastIO=0ms
      isOpen=true.onExceptionRead exception: {}
      java.util.zip.ZipException: Not in GZIP format
      
      2021-07-28 10:21:16,862  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW -
      AbstractRequestListener.onException() : Request:POST, uri:/test,
      message Id:rt-57-1, exception:java.util.zip.ZipException: Not in GZIP format,
      context:Context@71ea5ac input=ClientInputChannel(SSLClientChannel[Accepted:
      Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1
      bytesRead=0 bytesWritten=28764 age=2739894ms  lastIO=0ms  isOpen=true)
      2021-07-28 10:21:16,862  NIOThread@0 INFO  HTTP.SERVICE -
      ExceptionHandler.handleException() :
      Exception java.util.zip.ZipException: Not in GZIP format occurred while writing
      to channel null
      2021-07-28 10:21:16,863  NIOThread@0 INFO  HTTP.SERVICE -
      ExceptionHandler.handleException() : Exception trace:
      java.util.zip.ZipException: Not in GZIP format
      

      La riga java.util.zip.ZipException: Not in GZIP format nel messaggio di errore precedente indica che la richiesta il payload non viene inviato in formato GZIP anche se il file Content-Encoding è specificato come gzip. Pertanto, Apigee Edge genera l'eccezione restituisce un codice di stato 400 con codice di errore messaging.adaptors.http.flow.DecompressionFailureAtRequest alle applicazioni client.

      Scenario 2

      Scenario 2: quando la richiesta API ha l'intestazione Content-Encoding: deflate

      2021-07-28 15:26:31,893  NIOThread@1 ERROR HTTP.SERVER -
      HTTPServer$Context.onInputException() : Message id:rt-47875-1
      SSLClientChannel[Accepted: Remote:192.168.199.8:8443
      Local:192.168.81.72:45954]@29276 useCount=1 bytesRead=0
      bytesWritten=37230 age=3498856ms  lastIO=1ms
      isOpen=true.onExceptionRead exception: {}
      java.util.zip.ZipException: incorrect header check
                        ….
      Caused by: java.util.zip.DataFormatException: incorrect header check
             ..
      2021-07-28 15:26:31,894  NIOThread@1 ERROR ADAPTORS.HTTP.FLOW -
      AbstractRequestListener.onException() : Request:POST, uri:/test,
      message Id:rrt-47875-1, exception:java.util.zip.ZipException:
      incorrect header check, context:Context@69b3ac45
      input=ClientInputChannel(SSLClientChannel[Accepted:
      Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276
      useCount=1 byt	esRead=0 bytesWritten=37230 age=3498856ms
      lastIO=1ms  isOpen=true)
      

      Le linee java.util.zip.ZipException: incorrect header check e Caused by: java.util.zip.DataFormatException: incorrect header check nel messaggio di errore riportato sopra indicano che il payload della richiesta non è stato inviato deflate e non corrisponde alla codifica specificata nel Content-Encoding di deflate. Pertanto, Apigee Edge genera l'eccezione e restituisce un codice di stato 400 con codice di errore messaging.adaptors.http.flow.DecompressionFailureAtRequest alle applicazioni client.

Risoluzione

1. Se non è necessario il payload delle richieste compresse nel flusso proxy API in Apigee Edge e nel server di backend, non passare l'intestazione Content-Encoding. Se è necessario comprimere il payload della richiesta, vai al passaggio 2.
2. Assicurati che l'applicazione client invii sempre quanto segue:
   • Uno degli supportata come valore per l'intestazione Content-Encoding nel richiesta
   • Il payload della richiesta nel formato supportato per Apigee Edge corrisponde alla codifica formato specificato nell'intestazione Content-Encoding
3. Nell'esempio discusso sopra, il payload della richiesta è in formato ZIP ma l'intestazione della richiesta specifica Content-Encoding: gzip. Puoi risolvere il problema inviando la richiesta come Content-Encoding: gzip e il payload della richiesta anche in gzip formato:

   curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
   

Specifica

Apigee Edge risponde con il codice di stato 400 Bad Request con un codice di errore messaging.adaptors.http.flow.DecompressionFailureAtRequest in base al seguente RFC specifiche:

Specifica
RFC 7231, sezione 6.5.1
RFC 7231, sezione 3.1.2.2

Se hai ancora bisogno di aiuto dall'assistenza Apigee, vai a 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 400
• 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 ambiente
• Bundle proxy API
• File di traccia per le richieste API

• 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