Você está lendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. info
Sintoma
O aplicativo cliente recebe um código de status HTTP 400 Bad Request com o 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, você pode observar uma mensagem de erro semelhante à mostrada abaixo:
{
"fault":{
"faultstring":"Duplicate Header \"Expires\"",
"detail":{
"errorcode":"protocol.http.DuplicateHeader"
}
}
}Causas possíveis
Esse erro ocorre quando um cabeçalho HTTP específico que não pode ter cópias no Apigee Edge aparece mais de uma vez com valores iguais ou diferentes como parte da solicitação HTTP enviada por o cliente para o Apigee Edge.
De acordo com
RFC 7230, seção 3.2.2: ordem de campo, um remetente NÃO DEVE gerar vários campos de cabeçalho
com o mesmo nome de campo em uma mensagem, a menos que o valor do campo inteiro para esse
campo de cabeçalho seja definido como uma lista separada por vírgulas, [ou seja, #(values)] ou o campo de cabeçalho seja uma
exceção conhecida. Se o Apigee Edge encontrar um cabeçalho específico, que não pode ter
cópias, mais de uma vez na solicitação HTTP enviada pelo cliente, ele
responderá com 400 Bad Request e o código de erro
protocol.http.DuplicateHeader.
Confira 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 da nuvem pública e privada do Edge |
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 da Apigee Edge como um usuário com um papel apropriado.
Mude para a organização em que você quer investigar o problema.

- Acesse a página Analisar > Monitoramento de APIs > Investigar.
- Selecione o período específico em que você observou os erros.
- Verifique se o filtro de proxy está definido como Todos.
- Trace o código de falha em relação ao tempo.
Selecione uma célula que tenha o código de falha
protocol.http.DuplicateHeaderconforme mostrado abaixo:
As informações sobre o código de falha
protocol.http.DuplicateHeadersão mostradas abaixo:
- Clique em Ver registros e expanda a linha da solicitação com falha.
- Na janela Registros, anote os seguintes detalhes:
- Código de status:
400 - Origem da falha:
apigee - Código de falha:
protocol.http.DuplicateHeader.
- Código de status:
- Se a origem da falha tiver o valor
apigeeouMPe o código de falha tiver o valorprotocol.http.DuplicateHeader, isso indica que a solicitação HTTP do cliente continha cabeçalhos duplicados.
Ferramenta Trace
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 informações principais sobre erros HTTP
400. Verifique os registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_logEm que: ORG, ENV e PORT# são substituídos por valores reais.
- Pesquise para ver se há erros
400durante um período específico (se o problema aconteceu no passado) ou se ainda há solicitações com falha400. Se você encontrar erros
400com o X-Apigee-fault-code correspondente ao valor deprotocol.http.DuplicateHeader, então determine o valor de X-Apigee-fault-source.Exemplo de erro 400 do registro de acesso do NGINX:
A entrada de exemplo acima do registro de acesso do NGINX tem os seguintes valores para X-Apigee- fault-code e X-Apigee-fault-source:
Cabeçalhos de resposta Valor X-Apigee-fault-code protocol.http.DuplicateHeaderX-Apigee-fault-source MP
Causa: cabeçalho duplicado na solicitação
Diagnóstico
- Determine o código de falha e a origem da falha do erro observado usando o Monitoramento de APIs ou os registros de acesso do NGINX, conforme explicado em Etapas comuns do diagnóstico.
- Se a origem da falha tiver o valor
apigeeouMP, isso indica que a solicitação enviada pelo aplicativo cliente para a Apigee contém cabeçalhos duplicados. É possível determinar o cabeçalho real que é enviado mais de uma vez como parte da solicitação usando um dos seguintes métodos:
Mensagem de erro
Usando a mensagem de erro
Se você tiver acesso à mensagem de erro completa recebida do Apigee Edge, então consulte o
faultstring. Ofaultstringcontém o nome do cabeçalho que foi enviado mais de uma vez.Exemplo de mensagem de erro:
"faultstring":"Duplicate Header \"Expires\""
- Na mensagem de erro acima, é possível observar que o cabeçalho
Expiresé enviado mais de uma vez, conforme mostrado nafaultstring.
Solicitação real
Usando a solicitação real
Se você tiver acesso à solicitação real feita pelo aplicativo cliente, então siga estas etapas:
- Verifique a lista de cabeçalhos transmitidos na solicitação.
- Se você encontrar um cabeçalho específico que aparece mais de uma vez na solicitação com o mesmo valor ou valores diferentes , essa é a causa do 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"
No exemplo de solicitação acima, o cabeçalho
Expiresé enviado mais de uma vez. Portanto, essa solicitação falha com o400 Bad Requesterro e the error code:protocol.http.DuplicateHeader.- Como alternativa, se você tiver acesso aos registros do cliente, poderá verificar se há 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 [recomendada]: corrigir o aplicativo cliente para não incluir cabeçalhos duplicados
- Analise o motivo pelo qual o cliente específico envia um cabeçalho duplicado. Por exemplo,
Expiresno caso acima. Verifique se os proxies de API podem aceitar o cabeçalho duplicado. Normalmente, isso não é desejável de acordo com a especificação HTTP RFC7230. - Se não for desejável, modifique o aplicativo cliente para não enviar cabeçalhos duplicados.
No exemplo discutido acima, é notado que o cabeçalho
Expiresé enviado duas vezes com o mesmo valor, o que não é desejável. É possível corrigir o problema transmitindo oExpirescabeçalho apenas uma vez, conforme mostrado abaixo:curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
- Se for desejável e você quiser permitir os cabeçalhos duplicados, acesse a opção 2: usar a propriedade CwC.
CwC
Opção 2: usar a propriedade CwC
A Apigee fornece uma
propriedade CwC HTTPHeader.<HeaderName> ,que permite que aplicativos clientes
e servidores de destino enviem cabeçalhos duplicados para proxies de API no Apigee Edge.
| Propriedade CwC | Valores |
|---|---|
HTTPHeader.<HeaderName> |
allowDuplicates,multivalued |
Por exemplo, a propriedade a seguir pode ser definida nos processadores de mensagens para permitir duplicados e
vários valores para o cabeçalho Expires.
HTTPHeader.Expires=allowDuplicates, multiValued
- Se você for um usuário da nuvem privada, poderá configurar a propriedade para impedir que o
Apigee Edge gere um erro
400 Bad Request, mesmo que a solicitação contenha cabeçalhos duplicados usando o guia de instruções para configurar processadores de mensagens para usar cabeçalhos duplicados. - Se você for um usuário da nuvem pública, entre em contato com o suporte do Apigee Edge para configurar essa propriedade para 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 da RFC:
| Especificação |
|---|
| RFC 7230, seção 3.2.2: ordem de campo |
| RFC 7230, seção 3.2: campos de cabeçalho |
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
- Comando
curlcompleto usado para reproduzir o erro400 - Arquivo de trace para as solicitações de API
Se você for um usuário da nuvem privada, forneça as seguintes informações:
- Mensagem de erro completa observada para as solicitações com falha
- Nome do ambiente
- Pacote de proxy de API
- Comando
curlcompleto usado para reproduzir o erro400 - Arquivo de trace para as solicitações de API
Registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_logEm que: 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