400 Solicitação inválida - DecompressionFailureAtRequest

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.
  • MAS

  • 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

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 gzip.

Consulte Formato RFC1952 GZIP.

Codificação única diminuir

Esse formato usa a estrutura zlib com o algoritmo de compressão de desinflar.

Consulte RFC1950 e RFC1951.

Codificação múltipla

Codificação múltipla

Por exemplo, nos casos em que a codificação é feita duas vezes, ela pode ser:

  • gzip, desinflar
  • gzip, gzip
  • deflar, gzip
  • deflar, deflar
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:

  1. Faça login na interface do Apigee Edge como usuário com um papel apropriado.
  2. Alterne para a organização em que você quer investigar o problema.

  3. Navegue até a página Analisar > Monitoramento de API > Investigar.
  4. Selecione o período específico em que você observou os erros.
  5. Verifique se o filtro Proxy está definido como Todos.
  6. Trace o Código de falha em relação a Time.
  7. Selecione uma célula com o código de falha messaging.adaptors.http.flow.DecompressionFailureAtRequest, conforme mostrado abaixo:

    ( ver imagem ampliada)

  8. As informações sobre o código de falha messaging.adaptors.http.flow.DecompressionFailureAtRequest são mostradas conforme mostrado abaixo:

    ( ver imagem ampliada)

  9. Clique em Ver registros e expanda a linha que falha com o erro 400.

    ( ver imagem ampliada)

  10. 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.
  11. 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çalho Content-Encoding.

Ferramenta de rastreamento

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de rastreamento e:
    1. Aguarde a ocorrência do erro 400 Bad Request ou
    2. Se você conseguir reproduzir o problema, faça a chamada de API e reproduza 400 Bad Request.
  2. Verifique se a opção Mostrar todos os FlowInfos está ativada:

  3. Selecione uma das solicitações com falha e examine o rastro.
  4. Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.
  5. Normalmente, o erro é encontrado em um fluxo logo após a fase Solicitação recebida do cliente, conforme mostrado abaixo:

    ( ver imagem ampliada)

  6. 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.

  7. Determine o valor do cabeçalho da solicitação Content-Encoding. Para isso, acesse a fase Solicitação recebida do cliente, conforme mostrado abaixo:

    ( ver imagem ampliada)

    Observe que o valor do cabeçalho da solicitação Content-Encoding é realmente gzip.

    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 erro Decompression failure at request.

  8. 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:

    ( ver imagem ampliada)

    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"}}}
  9. Navegue até a fase AX (Dados do Analytics registrados) no rastro e clique nela.

  10. 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:

    ( ver imagem ampliada)

  11. Você verá os valores de X-Apigee-fault-code e X-Apigee-fault-source como messaging.adaptors.http.flow.DecompressionFailureAtRequest e policy, indicando que o formato do payload da solicitação não corresponde à codificação especificada no cabeçalho Content-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:

  1. 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.
  2. 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.

  3. 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 com 400.
  4. Se você encontrar erros 400 com o X-Apigee-fault-code correspondente ao valor de messaging.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

  1. 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.
  2. Se o código de falha for messaging.adaptors.http.flow.DecompressionFailureAtRequest e a Origem da falha tiver o valor policy ou proxy, 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ção Content-Encoding.
  3. É 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:

    1. Se você tiver acesso à mensagem de erro completa recebida do Apigee Edge, consulte faultstring.

      Exemplo de mensagem de erro:

      "faultstring":"Decompression failure at request"
      
    2. 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çalho Content-Encoding.

    Trace

    Para validar usando o Trace:

    1. 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.
    2. 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 erro messaging.adaptors.http.flow.DecompressionFailureAtRequest.

    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:

    1. Determine o valor transmitido ao cabeçalho da solicitação Content-Encoding.
    2. Determine o formato do payload enviado como parte da solicitação.
    3. 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çalho Content-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.zip
      

      A solicitação de amostra acima envia o valor gzip para o cabeçalho Content-Encoding, que é uma codificação compatível no Apigee Edge. No entanto, o payload da solicitação request_payload.zip está no formato ZIP. Portanto, essa solicitação falha com um código de status 400 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.

    1. 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.
    2. Procure o ID da mensagem no log do Processador de mensagens:

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

    3. 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 format
      

      A 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, embora Content-Encoding seja especificado como gzip. Portanto, o Apigee Edge gera a exceção e retorna um código de status 400 com código de falha messaging.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 e Caused 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çalho Content-Encoding de desinflação. Portanto, o Apigee Edge gera a exceção e retorna um código de status 400 com código de falha messaging.adaptors.http.flow.DecompressionFailureAtRequest para aplicativos clientes.

Resolução

  1. 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.
  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
  3. 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 como Content-Encoding: gzip e o payload da solicitação também no formato gzip:
    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 erro 400
  • 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