502 Gateway inválido - Cabeçalho duplicado

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 502 Bad Gateway 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 502 Bad Gateway

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 resposta HTTP enviada pelo servidor de back-end 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 descobrir que um mesmo cabeçalho específico, isso não tem duplicatas, é enviado mais de uma vez na resposta HTTP enviada pelo servidor de destino/back-end ele responde com 502 Bad Gateway 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 resposta A resposta do servidor de back-end 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 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 protocol.http.DuplicateHeader, conforme mostrado abaixo:

    (ampliar imagem)

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

    (ampliar imagem)

  9. Verifique se o Código de status é 502, como mostrado no exemplo acima.
  10. Clique em Ver registros e expanda a linha da solicitação com falha.
  11. Na janela "Registros", observe os seguintes detalhes:

    • Código de status: 502
    • Origem da falha: target
    • Código da falha:protocol.http.DuplicateHeader.
  12. A Fault Source é target, o que indica que a resposta do servidor de back-end continha cabeçalhos duplicados.

Ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de rastreamento e
    1. Aguarde a ocorrência do erro 502 Bad Gateway ou
    2. Se você puder reproduzir o problema, faça a chamada de API e reproduza 502 Bad Gateway erro
  2. Verifique se a opção Mostrar todas as informações do fluxo está ativada:

  3. Selecione uma das solicitações com falha e examine o trace.
  4. Navegar pelas diferentes fases do trace e localizar onde a falha ocorreu.
  5. Você encontrará o erro normalmente em um fluxo após a solicitação Request enviada ao destino servidor, conforme mostrado abaixo:

    (ampliar imagem)

  6. Anote o valor do erro do trace.

    O rastro de amostra acima mostra o erro como Duplicate Header "Expires". Como o erro for gerado pela Apigee após o envio da solicitação ao servidor de back-end, isso indica que o servidor de back-end enviou o cabeçalho Expires mais de uma vez.

  7. Navegue até a fase AX (Analytics Data Recorded) no trace e clique nela.
  8. Role para baixo até a seção Stage Details - Response Headers (Detalhes da fase - Cabeçalhos de resposta) e determine as de X-Apigee-fault-code e X-Apigee-fault-source, conforme mostrado abaixo:

    (ampliar imagem)

  9. Você vai encontrar os valores de X-Apigee-fault-code e X-Apigee-fault-source como protocol.http.DuplicateHeader e target, indicando que esse erro é causado porque cabeçalhos duplicados foram transmitidos pelo servidor de back-end para o cabeçalho de resposta Expires.
    Cabeçalhos de resposta Valor
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source target
  10. Verifique se você está usando encadeamento de proxy ou seja, se o servidor ou o endpoint de destino está invocando outro proxy na Apigee.

    1. Para determinar isso, volte à fase do servidor Solicitação enviada ao destino. Clique em Mostrar curl.

    2. A janela Curl for Request Sent to Target Server será aberta. Nela, você pode determinar o alias do host do servidor de destino.

    3. Se o alias de host do servidor de destino apontar para um alias de host virtual, então ele é proxy encadeamento. Nesse caso, você precisa repetir todas as etapas acima para o proxy encadeado até a determinar o que realmente está causando o erro 502 Bad Gateway.
    4. Se o alias de host do servidor de destino apontar para seu servidor de back-end, isso indica que seu servidor de back-end está enviando os cabeçalhos duplicados na resposta à Apigee.

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 502.
  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 502 durante um período específico (se o problema tiver acontecido no passado) ou se houver alguma solicitação que ainda esteja falhando com 502:
  4. Se você encontrar erros 502 no X-Apigee-fault-code correspondente ao valor de protocol.http.DuplicateHeader, determinar o valor de X-Apigee-fault-source.

    Exemplo de erro 502 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-source:

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

Causa: cabeçalho duplicado na resposta

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 Fault Source tiver o valor target, isso indica que a resposta enviado pelo servidor de destino contém cabeçalhos duplicados.
  3. É possível determinar o cabeçalho real que é enviado mais de uma vez como parte da resposta usando um dos seguintes métodos:

    Mensagem de erro

    Usar a mensagem de erro:

    1. Se você tiver acesso à mensagem de erro completa recebida do Apigee Edge, consulte para o faultstring. O faultstring contém o nome do 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 foi enviado mais de uma vez, como mostrado em faultstring.

    Solicitação real

    Usando a solicitação real:

    1. Se você não tiver acesso à solicitação real feita ao servidor de destino, acesse o comando curl correspondente Etapa 10.a e Como usar a ferramenta Trace Etapa 10.b.
    2. Se você tiver acesso à solicitação real feita ao aplicativo de servidor de destino, Depois, siga estas etapas:

      1. Faça uma chamada para o servidor de destino.

        Exemplo de solicitação para o servidor de destino usado neste exemplo:

        curl -X GET "https://BACKEND_SERVER_HOST/response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT" -v
        
      2. Verifique a lista de cabeçalhos exibidos na resposta.

        Exemplo de resposta do servidor de destino usado neste exemplo:

        * ...Trimmed...
        > GET /response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT HTTP/2
        > Host: BACKEND_SERVER_HOST
        > User-Agent: curl/7.64.1
        > Accept: */*
        >
        * Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
        < HTTP/2 200
        < date: Fri, 02 Jul 2021 05:29:07 GMT
        < content-type: application/json
        < content-length: 166
        < server: gunicorn/19.9.0
        < Expires: Mon, 21 June 2021 07:28:00 GMT
        < Expires: Mon, 21 June 2021 07:28:00 GMT
        < access-control-allow-origin: *
        < access-control-allow-credentials: true
        <
        ----<Response BODY>------
        * Connection #0 to host httpbin.org left intact
        * Closing connection 0
        

        Na solicitação de exemplo acima, o cabeçalho Expires recebe mais mais de uma vez. Portanto, a solicitação falha com o 502 Bad Gateway e o código de erro: protocol.http.DuplicateHeader.

      3. Se o cabeçalho cujo nome aparece no faultstring aparecer mais de uma vez na resposta do servidor de back-end, essa é a causa do erro. No caso acima, o cabeçalho Expires é enviado mais de uma vez.

Resolução

Corrigir duplicação

Opção 1 [Opção recomendada] Corrija o servidor de back-end para não incluir cabeçalhos duplicados

  1. Analise o motivo pelo qual o servidor de back-end específico enviou o cabeçalho duplicado Expires e verifique se os proxies da API podem aceitar isso. Em na maioria dos casos, não será desejável de acordo com a especificação HTTP RFC7230 (link em inglês).
  2. Se não for desejável, modifique seu aplicativo de servidor de destino 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, verifique se que o servidor de destino transmita o cabeçalho Expires apenas uma vez.
  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 fornece uma propriedade CwC HTTPHeader.<HeaderName> ,que permite aplicativos clientes e destino para enviar 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 duplicatas e vários valores para o cabeçalho Expires.

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Se você for um usuário da nuvem privada, poderá configurar a propriedade para impedir que a Apigee Edge de geração de um erro 502 Bad Gateway, mesmo que a solicitação contenha cabeçalhos duplicados usando o 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 isso para sua organização.

Especificação

A Apigee responde com a resposta de erro 502 Bad Gateway, já que espera que o de back-end se comportaria 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 É 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 502
  • 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