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
protocol.http.DuplicateHeader
como resposta para 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":"Duplicate Header \"Expires\"", "detail":{ "errorcode":"protocol.http.DuplicateHeader" } } }
Causas possíveis
Esse erro vai ocorrer se um cabeçalho HTTP específico que não tem permissão para ter cópias no Apigee Edge aparecer mais de uma vez com valores iguais ou diferentes como parte da solicitação HTTP enviada pelo cliente para o Apigee Edge.
De acordo com a
RFC 7230, seção 3.2.2: ordem dos campos, um remetente NÃO pode gerar vários campos de cabeçalho com o mesmo nome de campo em uma mensagem, a menos que o valor inteiro desse campo seja definido como uma lista separada por vírgulas [por exemplo, #(values)] ou o campo de cabeçalho é uma exceção bem 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
.
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 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:
- Faça login na interface do Apigee Edge como usuário com um papel apropriado.
Alterne para a organização em que você quer investigar o problema.
- Navegue até a página Analisar > Monitoramento de API > Investigar.
- Selecione o período específico em que você observou os erros.
- Verifique se o filtro "Proxy" está definido como Todos.
- Trace o Código de falha em relação a Time.
Selecione uma célula com o código de falha
protocol.http.DuplicateHeader
, conforme mostrado abaixo:As informações sobre o código de falha
protocol.http.DuplicateHeader
são mostradas abaixo:- Clique em Ver registros e expanda a linha da solicitação com falha.
- Na janela Registros, observe 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
apigee
ouMP
e o Código de falha tiver o valorprotocol.http.DuplicateHeader
, isso indica que a solicitação HTTP do cliente continha cabeçalhos duplicados.
Ferramenta de rastreamento
NGINX
Para diagnosticar o erro usando os 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 os 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 aconteceu anteriormente) ou se há alguma solicitação que ainda falha com400
. Se você encontrar erros
400
com o X-Apigee-fault-code correspondente ao valor deprotocol.http.DuplicateHeader
, 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-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
- Determine o código de falha e a Origem da falha do erro observado com os registros de acesso do Monitoring da API ou do NGINX, conforme explicado em Etapas comuns de diagnóstico.
- Se a Origem da falha tiver o valor
apigee
ouMP
, 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 enviado mais de uma vez como parte da solicitação usando um dos métodos a seguir:
Mensagem de erro
Como usar a mensagem de erro
Se você tiver acesso à mensagem de erro completa recebida do Apigee Edge, consulte
faultstring
. Ofaultstring
conté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 ver que o cabeçalho
Expires
é enviado mais de uma vez, conforme visto nofaultstring
.
Solicitação real
Usar a solicitação real
Se você tiver acesso à solicitação real feita pelo aplicativo cliente, siga estas etapas:
- Verifique a lista de cabeçalhos transmitidos na solicitação.
- Se você achar que um cabeçalho específico 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"
Na solicitação de exemplo acima, o cabeçalho
Expires
é enviado mais de uma vez. Portanto, essa solicitação falha com o erro400 Bad Request
e o código do erro:protocol.http.DuplicateHeader
.- Como alternativa, se você tiver acesso aos registros do cliente, poderá verificar se tem 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] Corrigir o aplicativo cliente para não incluir cabeçalhos duplicados
- Analisar por que o cliente específico enviou um cabeçalho duplicado. Por exemplo,
Expires
no caso acima. Verifique se os proxies da API aceitam o cabeçalho duplicado. Normalmente, ele não é desejável de acordo com a especificação HTTP RFC7230 (em inglês). - Se não for o caso, modifique o aplicativo cliente para não enviar cabeçalhos duplicados.
No exemplo discutido acima, percebe-se que o cabeçalho
Expires
é enviado duas vezes com o mesmo valor, o que não é desejável. Para corrigir o problema, transmita o cabeçalhoExpires
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 Opção 2 usando a propriedade CwC.
CwC
Opção 2: como usar a propriedade CwC
A Apigee fornece uma propriedade de
CwC HTTPHeader.<HeaderName>
,que permite que aplicativos
clientes e servidores de destino enviem cabeçalhos duplicados para proxies de API no Apigee Edge.
Propriedade da CwC | Valores |
---|---|
HTTPHeader.<HeaderName> |
allowDuplicates,multivalued |
Por exemplo, a propriedade a seguir pode ser definida nos processadores de mensagens para permitir cópias e
múltiplos valores para o cabeçalho Expires
.
HTTPHeader.Expires=allowDuplicates, multiValued
- Se você for um usuário de 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 Como 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 de RFC:
Especificação |
---|
RFC 7230, seção 3.2.2: ordem dos campos |
RFC 7230, seção 3.2 Campos de cabeçalho |
Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisamos coletar informações de diagnóstico.
É necessário coletar informações de diagnóstico
Reúna 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 de API
- Completar o comando
curl
usado para reproduzir o erro400
- 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
- Conclua o comando
curl
usado para reproduzir o erro400
- 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