Esta é a documentação do Apigee Edge.
Acesse
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 à API
chamadas.
Mensagem de erro
O aplicativo cliente recebe o seguinte código de resposta:
HTTP/1.1 400 Bad Request
Além disso, uma mensagem de erro semelhante a esta pode aparecer:
{ "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 de solicitação HTTP
Content-Encoding
é válido e com suporte do Apigee Edge, - O formato de payload enviado pelo cliente como parte da solicitação HTTP não
corresponder ao formato de codificação especificado no cabeçalho
Content-Encoding
MAS
Isso ocorre porque o Apigee Edge não decodifica o payload usando a codificação especificada, já que o
do payload não está no mesmo formato da codificação especificada no
Cabeçalho Content-Encoding
.
Estes são alguns exemplos de valores Content-Encoding
compatíveis e como a Apigee Edge
espera que o formato do payload seja nos casos a seguir:
Cenário | Content-Encoding | Formato de payload esperado |
---|---|---|
Codificação única | gzip | O formato Unix Consulte Formato GZIP RFC1952. |
Codificação única | deflar | 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, pode ser:
|
Várias codificação são aplicadas ao payload na ordem determinada, conforme aparece no cabeçalho. |
Estas são as possíveis causas desse erro:
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 é codificado ou não
correspondam à codificação especificada no cabeçalho Content-Encoding . |
Usuários de nuvem pública e privada 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 a API Monitoring:
- Faça login na interface do Apigee Edge como usuário com um para o papel apropriado.
Alterne para a organização na qual você deseja investigar o problema.
- Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
- Selecione o período específico em que você observou os erros.
- Verifique se o filtro Proxy está definido como Todos.
- Compare Código de falha com Time.
Selecione uma célula que tenha o código de falha
messaging.adaptors.http.flow.DecompressionFailureAtRequest
como mostrados abaixo:Informações sobre o código de falha
messaging.adaptors.http.flow.DecompressionFailureAtRequest
é exibido conforme mostrado abaixo:Clique em Ver registros e expanda a linha que apresenta falha com o erro
400
.- Na janela Registros, observe os seguintes detalhes:
- Código de status:
400
- Origem da falha:
proxy
- Código da falha:
messaging.adaptors.http.flow.DecompressionFailureAtRequest
.
- Código de status:
- Se a Origem da falha tiver o valor
proxy
, isso indica que o formato de payload da solicitação não correspondeu com suporte especificada no cabeçalhoContent-Encoding
.
Ferramenta Trace
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a sessão de trace.
e:
- Aguarde a ocorrência do erro
400 Bad Request
ou - Se você puder reproduzir o problema, faça a chamada de API e reproduza-o
400 Bad Request
:
- Aguarde a ocorrência do erro
Verifique se Mostrar todos os FlowInfos está ativado:
- Selecione uma das solicitações com falha e examine o trace.
- Navegar pelas diferentes fases do trace e localizar a falha o incidente.
Normalmente, você encontra o erro 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 afirma 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, navegue até a fase Solicitação recebida do cliente, como mostrado abaixo:O valor do cabeçalho de solicitação
Content-Encoding
é de fatogzip
.A amostra de trace acima mostra que a codificação especificada no cabeçalho da solicitação
Content-Encoding
égzip
; No entanto, a carga útil da solicitação não está no formato GZIP. Portanto, a Apigee não pode descompactar o payload usando gzip e retorna o erroDecompression failure at request
.- Observe o código de status e a mensagem de erro retornados pelo Apigee Edge navegando
para a fase Response Sent to Client 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 (Analytics Data Recorded) no trace e clicar nele.
- Role para baixo até a seção Phase Details, Error Headers e determinar os valores de X-Apigee-fault-code e X-Apigee-fault-source conforme mostrado abaixo:
- Você vai encontrar os valores de X-Apigee-fault-code e X-Apigee-fault-source
como
messaging.adaptors.http.flow.DecompressionFailureAtRequest
epolicy
, indicando que o formato de payload da solicitação não correspondeu ao 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 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 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 tiver acontecido no passado) ou se houver alguma solicitação que ainda esteja falhando com400
: Se você encontrar erros
400
no X-Apigee-fault-code correspondendo ao valor demessaging.adaptors.http.flow.DecompressionFailureAtRequest
, Depois, determine o valor de X-Apigee-fault-source.Exemplo de erro 400 do registro de acesso do NGINX:
O exemplo de entrada do registro de acesso do NGINX acima 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, a Apigee Edge sempre descompacta o payload se o cabeçalho da solicitação
Content-Encoding
contém um(a)
com suporte. Portanto, o formato do payload da solicitação
precisa corresponder à codificação especificada no cabeçalho de solicitação Content-Encoding
.
Se houver incompatibilidade, você receberá esse erro.
Diagnóstico
- Determine o código da falha e a fonte da falha do erro observado usando a API registros de acesso do Monitoring, da ferramenta Trace ou do NGINX, conforme explicado em Etapas comuns de diagnóstico.
- Se o Código da falha for
messaging.adaptors.http.flow.DecompressionFailureAtRequest
e o A Origem da falha tem o valorpolicy
ouproxy
, então esse indica que a solicitação enviada pelo aplicativo cliente tem payload que não corresponde ao codificação compatível especificada no cabeçalho de solicitaçãoContent-Encoding
. É possível determinar a incompatibilidade como parte da solicitação HTTP usando uma das opções a seguir métodos:
Mensagem de erro
Para validar usando a mensagem de erro:
-
Se você tiver acesso à mensagem de erro completa recebida do Apigee Edge, consulte o
faultstring
.Exemplo de mensagem de erro:
"faultstring":"Decompression failure at request"
- A mensagem de erro acima mostra
"Decompression failure at request"
, que implica que a solicitação não pôde ser descompactado usando a codificação especificada noContent-Encoding
.
Trace
Para validar usando o Trace:
- Determine o valor do cabeçalho de solicitação Content-Encoding e os Propriedade error.cause usando Trace conforme explicado nas Etapas comuns de diagnóstico.
Os valores do trace de amostra são os seguintes:
- Codificação de conteúdo:
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 código do erromessaging.adaptors.http.flow.DecompressionFailureAtRequest
.- Codificação de conteúdo:
Solicitação real
Para validar usando a solicitação real:
Se você tiver acesso à solicitação real feita pelo cliente e execute as seguintes 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 com suporte à codificação, 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.zipO exemplo de solicitação acima envia o valor
gzip
para o cabeçalhoContent-Encoding
, que é um codificação compatível no Apigee Edge. No entanto, o payload da solicitaçãorequest_payload.zip
está no formato ZIP. Portanto, a 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 registros do processador de mensagens:
Se você for um usuário da nuvem privada, poderá usar os registros do processador de mensagens. para determinar as principais informações sobre erros HTTP
400
.- Determinar o ID da mensagem da solicitação com falha usando a API Monitoring, a ferramenta Trace ou do NGINX, conforme explicado nas Etapas comuns de diagnóstico.
Pesquise o ID da mensagem no registro do processador de mensagens:
/opt/apigee/var/log/edge-message-processor/logs/system.log
Você verá uma das seguintes exceções:
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 a solicitação não é enviado no formato GZIP, embora o parâmetroContent-Encoding
é 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
aos 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 a carga útil da solicitação não foi enviada no deflar e não corresponder à codificação especificada no CabeçalhoContent-Encoding
do deflate. Portanto, o Apigee Edge gera a exceção e retorna um código de status400
com código de falhamessaging.adaptors.http.flow.DecompressionFailureAtRequest
aos aplicativos clientes.
-
Resolução
- Se não for necessário o payload de solicitação compactado no fluxo do proxy de 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. - Verifique se o aplicativo cliente sempre envia o seguinte:
- Qualquer um dos
com suporte como o valor do cabeçalho
Content-Encoding
na solicitação - O payload da solicitação para o Apigee Edge no formato compatível corresponde à codificação
formato especificado no cabeçalho
Content-Encoding
- Qualquer um dos
com suporte 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 uma solicitação cabeçalho comoContent-Encoding: gzip
e o payload da solicitação também emgzip
formato: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 o código de erro
messaging.adaptors.http.flow.DecompressionFailureAtRequest
conforme o seguinte RFC
especificações:
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
Colete as informações de diagnóstico a seguir 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 da API
- Comando
curl
completo usado para reproduzir o erro400
- Arquivo de rastreamento para as solicitações de API
Se você for um usuário da nuvem privada, forneça estas informações:
- Mensagem de erro completa observada para as solicitações com falha
- Nome do ambiente
- Pacote de proxy de API
- Arquivo de rastreamento para as 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