Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
Sintoma
O aplicativo cliente recebe um código de status HTTP de 400 Bad Request
com código de erro
messaging.adaptors.http.flow.DecompressionFailureAtRequest
como resposta a chamadas de
API.
Mensagem de erro
O aplicativo cliente recebe este código de resposta:
HTTP/1.1 400 Bad Request
Além disso, talvez você veja uma mensagem de erro semelhante à mostrada abaixo:
{ "fault":{ "faultstring":"Decompression failure at request", "detail":{ "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest" } } }
Causas possíveis
Esse erro só ocorrerá se:
- A codificação especificada no cabeçalho da solicitação HTTP
Content-Encoding
é válida e aceita pelo Apigee Edge. - O formato do payload enviado pelo cliente como parte da solicitação HTTP não
corresponde ao formato de codificação especificado no cabeçalho
Content-Encoding
MAS
Isso ocorre porque o Apigee Edge não consegue decodificar o payload usando a codificação especificada, porque o
formato do payload não está no mesmo formato que a codificação especificada no cabeçalho
Content-Encoding
.
Veja alguns exemplos de valores Content-Encoding
aceitos e como o Apigee Edge espera que o formato de payload seja nesses casos:
Cenário | Content-Encoding | Formato de payload esperado |
---|---|---|
Codificação única | gzip | O formato Unix Consulte Formato RFC1952 GZIP. |
Codificação única | diminuir | Esse formato usa a estrutura |
Codificação múltipla | Codificação múltipla Por exemplo, nos casos em que a codificação é feita duas vezes, ela pode ser:
|
Codificação múltipla aplicada ao payload na ordem determinada, conforme aparece no cabeçalho. |
As possíveis causas para esse erro são as seguintes:
Causa | Descrição | Instruções de solução de problemas aplicáveis para |
---|---|---|
O formato do payload da solicitação não corresponde à codificação especificada no cabeçalho Content-Encoding | O formato do payload da solicitação enviado pelo cliente não está codificado ou não corresponde à codificação especificada no cabeçalho Content-Encoding . |
Usuários de nuvens públicas e privadas de borda |
Etapas comuns do diagnóstico
Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:
Monitoramento de APIs
Para diagnosticar o erro usando o monitoramento de APIs:
- Faça login na interface do Apigee Edge como usuário com um papel apropriado.
Alterne para a organização em que você quer investigar o problema.
- Navegue até a página Analisar > Monitoramento de API > Investigar.
- Selecione o período específico em que você observou os erros.
- Verifique se o filtro Proxy está definido como Todos.
- Trace o Código de falha em relação a Time.
Selecione uma célula com o código de falha
messaging.adaptors.http.flow.DecompressionFailureAtRequest
, conforme mostrado abaixo:As informações sobre o código de falha
messaging.adaptors.http.flow.DecompressionFailureAtRequest
são mostradas conforme mostrado abaixo:Clique em Ver registros e expanda a linha que falha com o erro
400
.- Na janela Registros, observe os seguintes detalhes:
- Código de status:
400
- Origem da falha:
proxy
- Código de falha:
messaging.adaptors.http.flow.DecompressionFailureAtRequest
.
- Código de status:
- Se a origem da falha tiver o valor
proxy
, isso indica que o formato do payload da solicitação não correspondeu à codificação compatível especificada no cabeçalhoContent-Encoding
.
Ferramenta de rastreamento
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a sessão de rastreamento
e:
- Aguarde a ocorrência do erro
400 Bad Request
ou - Se você conseguir reproduzir o problema, faça a chamada de API e reproduza
400 Bad Request
.
- Aguarde a ocorrência do erro
Verifique se a opção Mostrar todos os FlowInfos está ativada:
- Selecione uma das solicitações com falha e examine o rastro.
- Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.
Normalmente, o erro é encontrado em um fluxo logo após a fase Solicitação recebida do cliente, conforme mostrado abaixo:
-
Observe os valores das propriedades do trace:
- erro:
Decompression failure at request
- error.class:
com.apigee.rest.framework.BadRequestException
- error.cause:
Not in GZIP format
O error.cause declara que o payload da solicitação NÃO está no formato GZIP. Isso significa que o Apigee Edge esperava que o payload da solicitação estivesse no formato GZIP como seria especificado no cabeçalho
Content-Encoding
. - erro:
Determine o valor do cabeçalho da solicitação
Content-Encoding
. Para isso, acesse a fase Solicitação recebida do cliente, conforme mostrado abaixo:Observe que o valor do cabeçalho da solicitação
Content-Encoding
é realmentegzip
.O trace de amostra acima mostra que a codificação especificada no cabeçalho da solicitação
Content-Encoding
égzip
. No entanto, o payload da solicitação não está no formato GZIP. Portanto, a Apigee não pode descompactar o payload usando o gzip e retorna o erroDecompression failure at request
.- Observe o código de status e a mensagem de erro retornadas pelo Apigee Edge em
para a fase Resposta enviada ao cliente no trace, conforme mostrado abaixo:
Observe os seguintes detalhes do trace:
- Código de status:
400 Bad Request
. - Conteúdo do erro:
{"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}
- Código de status:
Navegue até a fase AX (Dados do Analytics registrados) no rastro e clique nela.
- Role para baixo até a seção Phase Details, Error Headers e determine os valores de X-Apigee-fault-code e X-Apigee-fault-source, conforme mostrado abaixo:
- Você verá os valores de X-Apigee-fault-code e X-Apigee-fault-source
como
messaging.adaptors.http.flow.DecompressionFailureAtRequest
epolicy
, indicando que o formato do payload da solicitação não corresponde à codificação especificada no cabeçalhoContent-Encoding
.Cabeçalhos de resposta Valor X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
X-Apigee-fault-source policy
NGINX
Para diagnosticar o erro usando os registros de acesso do NGINX:
- Se você for um usuário da nuvem privada, poderá usar os registros de acesso do NGINX para
determinar as principais informações sobre os erros HTTP
400
. Verifique os registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Onde:ORG, ENV e PORT# são substituídos por valores reais.
- Pesquise se há erros
400
durante um período específico (se o problema aconteceu anteriormente) ou se há alguma solicitação que ainda falha com400
. Se você encontrar erros
400
com o X-Apigee-fault-code correspondente ao valor demessaging.adaptors.http.flow.DecompressionFailureAtRequest
, determine o valor de X-Apigee-fault-source.Exemplo de erro 400 do registro de acesso do NGINX:
A entrada de amostra acima do registro de acesso do NGINX tem os seguintes valores para X-Apigee-fault-code e X-Apigee-fault-code :
Cabeçalhos de resposta Valor X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
X-Apigee-fault-source policy
Causa: o formato do payload da solicitação não corresponde à codificação especificada no cabeçalho Content-Encoding
Por padrão, o Apigee Edge sempre descompacta o payload se o cabeçalho da solicitação
Content-Encoding
contiver uma
codificação válida. Portanto, espera-se que o formato do payload da solicitação corresponda à codificação especificada no cabeçalho da solicitação Content-Encoding
.
Se houver uma incompatibilidade, você vai receber esse erro.
Diagnóstico
- Determine o código de falha e a origem da falha do erro observado usando o monitoramento da API, a ferramenta de rastreamento ou os registros de acesso do NGINX, conforme explicado nas etapas comuns de diagnóstico.
- Se o código de falha for
messaging.adaptors.http.flow.DecompressionFailureAtRequest
e a Origem da falha tiver o valorpolicy
ouproxy
, isso indica que a solicitação enviada pelo aplicativo cliente tem um payload que não corresponde à codificação compatível especificada no cabeçalho da solicitaçãoContent-Encoding
. É possível determinar a incompatibilidade como parte da solicitação HTTP usando um dos seguintes métodos:
Mensagem de erro
Para validar usando a mensagem de erro, siga estas etapas:
-
Se você tiver acesso à mensagem de erro completa recebida do Apigee Edge, consulte
faultstring
.Exemplo de mensagem de erro:
"faultstring":"Decompression failure at request"
- Na mensagem de erro acima, ele exibe
"Decompression failure at request"
, o que significa que não foi possível descompactar a solicitação usando a codificação especificada no cabeçalhoContent-Encoding
.
Trace
Para validar usando o Trace:
- Determine o valor do cabeçalho da solicitação Content-Encoding e da propriedade error.causa usando o Trace, conforme explicado em Etapas comuns de diagnóstico.
Os valores do trace de amostra são os seguintes:
- Content-Encoding:
gzip
- error.cause:
Not in GZIP format
O valor no cabeçalho da solicitação Content-Encoding é gzip. No entanto, o payload da solicitação não está no formato GZIP (conforme indicado por error.Cause). Portanto, o Apigee Edge responde com
400 Bad Request
e o código de erromessaging.adaptors.http.flow.DecompressionFailureAtRequest
.- Content-Encoding:
Solicitação real
Para validar usando a solicitação real, faça o seguinte:
Se você tiver acesso à solicitação real feita pelo aplicativo cliente, siga estas etapas:
- Determine o valor transmitido ao cabeçalho da solicitação
Content-Encoding
. - Determine o formato do payload enviado como parte da solicitação.
Se o valor do cabeçalho
Content-Encoding
estiver na lista de codificação compatível, mas o formato do payload da solicitação não corresponder à codificação especificada no cabeçalhoContent-Encoding
, essa será a causa do problema.Exemplo de solicitação:
curl -v "http://HOSTALIAS/v1/testgzip"
-H "Content-Encoding: gzip"
-X POST -d @request_payload.zipA solicitação de amostra acima envia o valor
gzip
para o cabeçalhoContent-Encoding
, que é uma codificação compatível no Apigee Edge. No entanto, o payload da solicitaçãorequest_payload.zip
está no formato ZIP. Portanto, essa solicitação falha com um código de status400 Bad Request
e o código de erro:messaging.adaptors.http.flow.DecompressionFailureAtRequest
.
Registros do processador de mensagens
Para validar usando os registros do processador de mensagens:
Se você for um usuário de nuvem privada, poderá usar os registros do processador de mensagens para determinar as principais informações sobre erros HTTP
400
.- Determine o código da mensagem da solicitação com falha usando o monitoramento de APIs, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico.
Procure o ID da mensagem no log do Processador de mensagens:
/opt/apigee/var/log/edge-message-processor/logs/system.log
Uma das seguintes exceções vai aparecer:
Cenário 1
Cenário 1: quando a solicitação de API tem o cabeçalho 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 formatA linha
java.util.zip.ZipException: Not in GZIP format
na mensagem de erro acima indica que o payload da solicitação não é enviado no formato GZIP, emboraContent-Encoding
seja especificado como gzip. Portanto, o Apigee Edge gera a exceção e retorna um código de status400
com código de falhamessaging.adaptors.http.flow.DecompressionFailureAtRequest
para aplicativos clientes.Cenário 2
Cenário 2: quando a solicitação de API tem o cabeçalho 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)As linhas
java.util.zip.ZipException: incorrect header check
eCaused by: java.util.zip.DataFormatException: incorrect header check
na mensagem de erro acima indicam que o payload da solicitação não é enviado no formato de descontinuação e não corresponde à codificação especificada no cabeçalhoContent-Encoding
de desinflação. Portanto, o Apigee Edge gera a exceção e retorna um código de status400
com código de falhamessaging.adaptors.http.flow.DecompressionFailureAtRequest
para aplicativos clientes.
-
Resolução
- Se não houver necessidade do payload de solicitação compactado no fluxo de proxy da API no Apigee Edge
e no servidor de back-end, não transmita o cabeçalho
Content-Encoding
. Se for necessário compactar o payload da solicitação, vá para a etapa 2. - O aplicativo cliente precisa sempre enviar o seguinte:
- Qualquer uma das
codificação compatíveis como o valor do cabeçalho
Content-Encoding
na solicitação - O payload da solicitação no formato compatível para o Apigee Edge corresponde ao formato
de codificação especificado no cabeçalho
Content-Encoding
- Qualquer uma das
codificação compatíveis como o valor do cabeçalho
- No exemplo discutido acima, o payload da solicitação está no formato ZIP, mas o cabeçalho da solicitação especifica
Content-Encoding: gzip
. Para corrigir o problema, envie o cabeçalho da solicitação comoContent-Encoding: gzip
e o payload da solicitação também no formatogzip
:curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
Especificação
O Apigee Edge responde com o código de status 400 Bad Request
com código de erro
messaging.adaptors.http.flow.DecompressionFailureAtRequest
de acordo com as seguintes especificações de
RFC:
Especificação |
---|
RFC 7231, seção 6.5.1 |
RFC 7231, seção 3.1.2.2 |
Se você ainda precisar de ajuda do suporte da Apigee, acesse É necessário coletar informações de diagnóstico.
É necessário coletar informações de diagnóstico
Reúna as seguintes informações de diagnóstico e entre em contato com o suporte do Apigee Edge:
Se você for um usuário da nuvem pública, forneça as seguintes informações:
- Nome da organização
- Nome do ambiente
- Nome do proxy de API
- Completar o comando
curl
usado para reproduzir o erro400
- Arquivo de rastreamento das solicitações de API
Se você for um usuário da nuvem privada, forneça as seguintes informações:
- Concluir a mensagem de erro observada para as solicitações com falha
- Nome do ambiente
- Pacote de proxy de API
- Arquivo de rastreamento das solicitações de API
Registros de acesso do NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Onde:ORG, ENV e PORT# são substituídos por valores reais.
- Registros do sistema do processador de mensagens
/opt/apigee/var/log/edge-message-processor/logs/system.log