400 Solicitação inválida - duplicateHeader

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 protocol.http.DuplicateHeader como resposta para chamadas de API.

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":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

Causas possíveis

Esse erro ocorre se um cabeçalho HTTP específico que não tem permissão para ter cópias na Apigee Edge, aparece mais de uma vez com valores iguais ou diferentes como parte da solicitação HTTP enviada pelo o cliente para o Apigee Edge.

De acordo com RFC 7230, seção 3.2.2: ordem de campo, um remetente NÃO PODE gerar vários cabeçalhos. campos com o mesmo nome de campo em uma mensagem, a menos que o valor inteiro desse campo cabeçalho é definido como uma lista separada por vírgulas, [ou seja, #(values)] ou se o campo de cabeçalho for um uma exceção bem conhecida. Se o Apigee Edge encontrar um cabeçalho específico, ele não poderá duplicatas, mais de uma vez na solicitação HTTP enviada pelo cliente, responde com 400 Bad Request e o código de erro protocol.http.DuplicateHeader.

Estas são as possíveis causas desse erro:

Causa Descrição Instruções de solução de problemas aplicáveis para
Cabeçalho duplicado na solicitação A solicitação HTTP do aplicativo cliente para a Apigee contém cabeçalhos duplicados. 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 uma função apropriada.
  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 protocol.http.DuplicateHeader conforme mostrado abaixo:

  8. As informações sobre o código de falha protocol.http.DuplicateHeader são exibido conforme mostrado abaixo:

  9. Clique em Ver registros e expanda a linha da solicitação com falha.
  10. Na janela Registros, observe os seguintes detalhes:
    1. Código de status: 400
    2. Origem da falha: apigee
    3. Código da falha:protocol.http.DuplicateHeader.
  11. Se a Origem da falha tiver o valor apigee ou MP e o Código da falha tiver o valor protocol.http.DuplicateHeader, o que indica que a solicitação HTTP o cliente continha cabeçalhos duplicados.

Ferramenta Trace

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 ocorreu no passado) ou se há alguma solicitação ainda falhando com 400:
  4. Se você encontrar erros 400 no X-Apigee-fault-code correspondente ao valor de protocol.http.DuplicateHeader, então determinar o valor de X-Apigee-fault-source.

    Exemplo de erro 400 do registro de acesso do NGINX:

    O exemplo de entrada acima do registro de acesso do NGINX tem os seguintes valores para X-Apigee- código de falha e X-Apigee-fault-source:

    Cabeçalhos de resposta Valor
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source MP

Causa: cabeçalho duplicado na solicitação

Diagnóstico

  1. Determine o código da falha e a fonte da falha do erro observado usando a API Monitoring ou registros de acesso do NGINX, conforme explicado nas Etapas comuns de diagnóstico.
  2. Se a Origem da falha tiver o valor apigee ou MP, esse indica que a solicitação enviada pelo aplicativo cliente à Apigee contém e cabeçalhos de cache válidos.
  3. É possível determinar o cabeçalho real enviado mais de uma vez como parte da solicitação usando o um dos seguintes métodos:

    Mensagem de erro

    Uso da mensagem de erro

    1. Se você tiver acesso à mensagem de erro completa recebida do Apigee Edge, consulte o faultstring. O faultstring contém cabeçalho que foi enviado mais de uma vez.

      Exemplo de mensagem de erro:

      "faultstring":"Duplicate Header \"Expires\""
      
    2. Na mensagem de erro acima, é possível ver que o cabeçalho Expires está enviado mais de uma vez, como mostrado em faultstring.

    Solicitação real

    Usando a solicitação real

    1. Se você tiver acesso à solicitação real feita pelo aplicativo cliente, siga estas etapas:

      1. Verifique a lista de cabeçalhos transmitidos na solicitação.
      2. Se você perceber que um cabeçalho específico aparece mais de uma vez no solicitação com o mesmo valor ou valores diferentes , essa é a causa para este erro.

      Exemplo de solicitação:

      curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
      

      Na solicitação de exemplo acima, o cabeçalho Expires é enviado mais de uma vez. Portanto, essa solicitação falha com o erro 400 Bad Request e código do erro: protocol.http.DuplicateHeader.

    2. Como alternativa, se você tiver acesso aos registros do cliente, poderá verificar informações sobre a solicitação real feita ao Apigee Edge e determinar o cabeçalho que é enviado mais de uma vez.

Resolução

Corrigir duplicação

Opção 1 [Opção recomendada] Corrija o aplicativo cliente para não incluir cabeçalhos duplicados

  1. Analise o motivo pelo qual o cliente específico enviou um cabeçalho duplicado. Por exemplo: Expires no caso acima. Verifique se os proxies da API podem aceitar o cabeçalho duplicado. Normalmente, não é desejável de acordo com a especificação HTTP RFC7230 (link em inglês).
  2. Se não for desejável, modifique seu aplicativo cliente para não enviar cabeçalhos duplicados.

    No exemplo discutido acima, o cabeçalho Expires foi enviado duas vezes com o mesmo valor, o que não é desejável. Para corrigir o problema, passe o valor-chave Cabeçalho Expires apenas uma vez, conforme mostrado abaixo:

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
    
  3. Se for desejável e você quiser permitir os cabeçalhos duplicados, vá para Opção 2: usar a propriedade CwC.

CwC

Opção 2 usando a propriedade CwC

A Apigee oferece um Propriedade HTTPHeader.<HeaderName> do CwC ,que permite ao cliente e servidores de destino para enviar cabeçalhos duplicados a proxies de API no Apigee Edge.

Propriedade da CwC Valores
HTTPHeader.<HeaderName> allowDuplicates,multivalued

Por exemplo, a propriedade a seguir pode ser configurada nos processadores de mensagens para permitir duplicatas e diversos valores para o cabeçalho Expires.

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Se você for usuário da nuvem privada, poderá configurar a propriedade para impedir o Apigee Edge não gere um erro 400 Bad Request, mesmo que a solicitação contém cabeçalhos duplicados usando o atributo Guia de instruções sobre como configurar processadores de mensagens para usar cabeçalhos duplicados
  2. Se você for um usuário da nuvem pública, entre em contato com o suporte do Apigee Edge para configurar essa propriedade da sua organização.

Especificação

A Apigee espera que o aplicativo cliente não envie cabeçalhos duplicados como parte da solicitação. de acordo com as seguintes especificações de RFC:

Especificação
RFC 7230, seção 3.2.2: ordem dos campos
Campos de cabeçalho da RFC 7230, seção 3.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
  • Conclua o comando curl que você usou para reproduzir o erro 400.
  • 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