502 Gateway inválido - Resposta 405 sem cabeçalho de permissão

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 502 Bad Gateway com o erro código protocol.http.Response405WithoutAllowHeader 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, você poderá encontrar a seguinte mensagem de erro:

{
   "fault":{
      "faultstring":"Received 405 Response without Allow Header",
      "detail":{
         "errorcode":"protocol.http.Response405WithoutAllowHeader"
      }
   }
}

Causas possíveis

Esse erro ocorrerá se o servidor de back-end responder com o status 405 Method Not Allowed. sem o cabeçalho Allow.

De acordo com a especificação RFC 7231, seção 6.5.5: 405 Method Not Allowed, é esperado que o servidor de origem PRECISA gerar e enviar um campo de cabeçalho Allow em uma resposta 405 que contenha uma lista dos métodos suportados no momento do recurso de destino. Caso contrário, a Apigee responde com 502 Bad Gateway e o código do erro protocol.http.Response405WithoutAllowHeader.

Causa Descrição Instruções de solução de problemas aplicáveis para
Resposta 405 sem o cabeçalho "Allow" do servidor de back-end O servidor de back-end que está processando a solicitação de API responde com o código de status 405 sem o cabeçalho Allow. 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 Edge como um usuário com um para o papel apropriado.
  2. Alterne para a organização na qual você deseja investigar o problema.

    lista suspensa da organização
  3. Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
  4. Selecione o período específico em que você observou os erros.
  5. Compare Código de falha com Time.

  6. Selecione uma célula que contenha o código de falha protocol.http.Response405WithoutAllowHeader, conforme mostrado abaixo:

  7. Informações sobre o código de falha protocol.http.Response405WithoutAllowHeader é exibido conforme mostrado abaixo:

  8. Clique em Ver registros e abra uma das solicitações com falha para ver mais informações.

  9. Na janela Registros, observe os seguintes detalhes:
    • Código de status: 502
    • Origem da falha: target
    • Código da falha:protocol.http.Response405WithoutAllowHeader.
  10. Se a Origem da falha for target e o Código da falha for protocol.http.Response405WithoutAllowHeader, isso indica que o back-end servidor respondeu com o código de status 405 Method Not Allowed sem o Allow.

Ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative o sessão de trace e
    • Aguarde a ocorrência do erro 502 Bad Gateway ou
    • Se for possível reproduzir o problema, faça a chamada de API para reproduzir o problema - 502 Bad Gateway erro
  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 onde a falha ocorreu.
  5. Você encontrará o erro normalmente em um fluxo após a Request enviada to target server. fase, conforme mostrado abaixo:

  6. Anote o valor do erro do trace.

    O rastro de amostra acima mostra o erro como Received 405 Response without Allow Header. Como o erro é gerado pela Apigee depois que a solicitação é enviada ao back-end isso indica que o servidor de back-end enviou o código de status de resposta 405 sem o cabeçalho Allow.

  7. Navegue até a fase AX (dados do Analytics registrados) no trace e clique nela.
  8. Role para baixo até a seção Cabeçalhos de erro / resposta em Detalhes da fase. e determinar os de X-Apigee-fault-code e X-Apigee-fault-source, conforme mostrado abaixo:

  9. Os valores de X-Apigee-fault-code e X-Apigee-fault-source aparecerão como protocol.http.Response405WithoutAllowHeader e target, respectivamente, indicando que esse erro foi causado porque o back-end enviou a Código de status da resposta 405 sem o cabeçalho Allow.
    Cabeçalhos de resposta Valor
    X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
    X-Apigee-fault-source target

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 os informações importantes sobre erros HTTP 502.
  2. Verifique os registros de acesso do NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
    

    Onde:ORG, ORG e PORT# são substituídos por valores reais.

  3. Pesquise se há algum erro 502 com o código de erro. protocol.http.Response405WithoutAllowHeader durante um período específico (se o ocorreu no passado) ou se há alguma solicitação ainda falhando com 502:
  4. Se você encontrar erros 502 com o X-Apigee-fault-code que corresponde ao de protocol.http.Response405WithoutAllowHeader, depois determine 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- código de falha e X-Apigee-fault-source:

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

Causa: resposta 405 sem o cabeçalho "Allow" do servidor de back-end

Diagnóstico

  1. Determinar o código da falha e a origem da falha para 502 Bad Gateway. usando o monitoramento de APIs, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico.
  2. Se o Código da falha for protocol.http.Response405WithoutAllowHeader e A origem da falha tem o valor target, o que indica que o servidor de back-end respondeu com um código de status 405 sem o cabeçalho Allow. Portanto, A Apigee responde com 502 Bad Gateway com o código do erro. protocol.http.Response405WithoutAllowHeader.

Resolução

Use um dos seguintes métodos para resolver o problema:

Servidor de back-end

Opção 1: corrija o servidor de back-end para enviar o código de status 405 com o cabeçalho "Allow":

  1. Verifique se o servidor de back-end sempre segue a especificação RFC 7231, seção 6.5.5: método 405 não permitido e envia com o status 405 incluindo a lista de métodos permitidos como parte de um cabeçalho Allow conforme mostrado abaixo:

    Allow: HTTP_METHODS
    
  2. Por exemplo, se o servidor de back-end permitir GET, POST e HEAD, é necessário garantir que o cabeçalho Allow contenha da seguinte forma:
    Allow: GET, POST, HEAD
    

Gerenciamento de falhas

Opção 2: usar o tratamento de falhas para enviar o código de status 405 com o cabeçalho "Allow" da sua API proxy:

Se o servidor de back-end retornar o código de status 405 sem o Allow cabeçalho, use o tratamento de falhas para responder com o código de status 405 e o Allow do proxy de API da seguinte maneira:

  1. Crie uma política, como Política AttributionMessage ou a política liftFault e defina o código de status como 405 com um cabeçalho Allow e um mensagem.

    Exemplo de política AttributionMessage para enviar o erro 405 com o cabeçalho "Allow":

    <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-405WithAllowHeader">
        <DisplayName>AM-405WithAllowHeader</DisplayName>
        <Set>
            <Payload contentType="application/json">{"Specified method is not allowed. Please use one of the methods mentioned in the Allow header."}</Payload>
            <StatusCode>405</StatusCode>
            <ReasonPhrase>Method Not Allowed</ReasonPhrase>
        </Set>
        <Add>
            <Headers>
                <Header name="Allow">GET, POST, HEAD</Header>
            </Headers>
        </Add>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>
    
  2. Crie um FaultRule no TargetEndpoint, que invoca a política ao receber o erro 502 com o código de erro protocol.http.Response405WithoutAllowHeader.

    Exemplo de configuração do TargetEndpoint mostrando FaultRule:

    <TargetEndpoint name="default">
    ...
        <FaultRules>
           <FaultRule name="405WithoutAllowHeader">
                <Step>
                    <Name>AM-405WithAllowHeader</Name>
                </Step>
                <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition>
            </FaultRule>
        </FaultRules>
    
  3. Salve essas alterações em uma nova revisão do proxy de API e implante-a.
  4. Faça as chamadas de API e verifique se você está recebendo o código de status 405 com a Cabeçalho Allow.

Configurar propriedade

Opção 3: configurar a propriedade no processador de mensagens para impedir que o Apigee Edge retornando o erro 502

  1. Se você for usuário da nuvem privada, poderá atualizar a propriedade HTTP.ignore.allow_header.for.405 para true para evitar que o Apigee Edge Gerando um erro 502, mesmo que o servidor de back-end responda com 405. sem o cabeçalho Allow usando o Guia de instruções: Configuração do cabeçalho "ignorar permissão" para a propriedade 405 em processadores de mensagens.
  2. Se você é um usuário da nuvem pública , entre em contato com o suporte do Apigee Edge

Especificação

A Apigee espera a resposta 405 Method Not Allowed do servidor de back-end junto com o cabeçalho Allow de acordo com estas especificações:

Especificação
RFC 7231, seção 6.5.5: método 405 não permitido
RFC 7231, seção 7.4.1: permitir

Pontos principais a observar

A solução recomendada é corrigir o servidor de back-end para enviar o código de status 405 com o cabeçalho Allow e aderir às especificações RFC 7231, seção 6.5.5: método 405 não permitido.

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

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações: 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 da API
  • Comando curl completo usado para reproduzir o 502 Bad Gateway com o código de erro protocol.http.Response405WithoutAllowHeader
  • 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~ORG.PORT#_access_log
    

    Onde:ORG, ORG 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
    

Referências

Tratamento de falhas na Apigee