400 Solicitação inválida - DecompressionFailureAtRequest

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

  • 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

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

Consulte Formato GZIP RFC1952.

Codificação única deflar

Esse formato usa a estrutura zlib com o algoritmo de redução de compactação.

Consulte RFC1950 e RFC1951.

Codificação múltipla

Codificação múltipla

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

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

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

  3. Navegue até o menu Analisar > Monitoramento de APIs > 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. Compare Código de falha com Time.
  7. Selecione uma célula que tenha o código de falha messaging.adaptors.http.flow.DecompressionFailureAtRequest como mostrados abaixo:

    ( ver imagem maior)

  8. Informações sobre o código de falha messaging.adaptors.http.flow.DecompressionFailureAtRequest é exibido conforme mostrado abaixo:

    ( ver imagem maior)

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

    ( ver imagem maior)

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

Ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

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

  3. Selecione uma das solicitações com falha e examine o trace.
  4. Navegar pelas diferentes fases do trace e localizar a falha o incidente.
  5. Normalmente, você encontra o erro em um fluxo logo após a fase Solicitação recebida do cliente, conforme mostrado abaixo:

    ( ver imagem maior)

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

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

    ( ver imagem maior)

    O valor do cabeçalho de solicitação Content-Encoding é de fato gzip.

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

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

    ( ver imagem maior)

    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 (Analytics Data Recorded) no trace e clicar nele.

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

    ( ver imagem maior)

  11. Você vai encontrar os valores de X-Apigee-fault-code e X-Apigee-fault-source como messaging.adaptors.http.flow.DecompressionFailureAtRequest e policy, indicando que o formato de payload da solicitação não correspondeu ao 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 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 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 tiver acontecido no passado) ou se houver alguma solicitação que ainda esteja falhando com 400:
  4. Se você encontrar erros 400 no X-Apigee-fault-code correspondendo ao valor de messaging.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

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

    1. 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"
      
    2. 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 no Content-Encoding.

    Trace

    Para validar usando o Trace:

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

    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:

    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 com suporte à codificação, 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
      

      O exemplo de solicitação acima envia o valor gzip para o cabeçalho Content-Encoding, que é um codificação compatível no Apigee Edge. No entanto, o payload da solicitação request_payload.zip está no formato ZIP. Portanto, a 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 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.

    1. 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.
    2. Pesquise o ID da mensagem no registro do processador de mensagens:

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

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

      A 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âmetro Content-Encoding é 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 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 e Caused 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çalho Content-Encoding do deflate. 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 aos aplicativos clientes.

Resolução

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