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

Monitoramento de APIs

Para diagnosticar o erro usando o monitoramento de APIs:

1. Faça login na interface do Edge como um usuário com um papel apropriado.

2. Alterne para a organização em que você quer investigar o problema.

   
3. Navegue até a página Analisar > Monitoramento de API > Investigar.
4. Selecione o período específico em que você observou os erros.

5. Trace o Código de falha em relação a Time.

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

   

7. As informações sobre o código de falha protocol.http.Response405WithoutAllowHeader são mostradas conforme mostrado abaixo:

   

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

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

Ferramenta de rastreamento

Para diagnosticar o erro usando a ferramenta Trace:

1. Ative a sessão de rastreamento e
   • Aguarde a ocorrência do erro 502 Bad Gateway ou
   • Se você conseguir reproduzir o problema, faça a chamada de API para reproduzi-lo: erro 502 Bad Gateway

2. Verifique se a opção Mostrar todos os FlowInfos está ativada:

   
3. Selecione uma das solicitações com falha e examine o rastro.
4. Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.

5. Você vai encontrar o erro normalmente em um fluxo após a fase Solicitação enviada para o servidor de destino, conforme mostrado abaixo:

   

6. Observe o valor do erro do trace.

   O trace 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 servidor de back-end, ele 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 rastreamento e clique nela.

8. Role para baixo até a seção Cabeçalhos de erro / resposta no painel Detalhes da fase e determine os valores de X-Apigee-fault-code e X-Apigee-fault-source, conforme mostrado abaixo:

   
9. Você verá os valores de X-Apigee-fault-code e X-Apigee-fault-source como protocol.http.Response405WithoutAllowHeader e target, respectivamente, indicando que esse erro foi causado porque o back-end enviou o código de status de 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 os 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 os 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 protocol.http.Response405WithoutAllowHeader durante um período específico (se o problema aconteceu anteriormente) ou se ainda há alguma solicitação com falha com 502.

4. Se você encontrar erros 502 com o X-Apigee-fault-code correspondente ao valor de protocol.http.Response405WithoutAllowHeader, determine o valor da X-Apigee-fault-source..

   Exemplo de erro 502 no 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.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

Servidor de back-end

Opção 1: corrigir 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: 405 Method Not Allowed e envia com o código de 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 os métodos GET, POST e HEAD, será necessário garantir que o cabeçalho Allow os contenha da seguinte maneira:

   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" do proxy de API:

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

1. Crie uma política, como a políticaAssignMessage ou a política de destaque, e defina o código de status como 405 com o cabeçalho Allow e uma mensagem personalizada.

   Exemplo de política AttributionMessage para enviar 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 de TargetEndpoint com 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 revisão.
4. Faça as chamadas de API e verifique se você está recebendo o código de status 405 com o cabeçalho Allow.

Configurar propriedade

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

1. Se você for um usuário da nuvem privada, poderá atualizar a propriedade HTTP.ignore.allow_header.for.405 para true a fim de evitar que o Apigee Edge gere um erro 502, mesmo que o servidor de back-end responda com o código de status 405 sem o cabeçalho Allow usando o guia de instruções: Como configurar o cabeçalho "ignorar permitir" para a propriedade 405 em processadores de mensagens.
2. Se você for um usuário da nuvem pública , entre em contato com o suporte do Apigee Edge