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 502 Bad Gateway
com o código de erro protocol.http.Response405WithoutAllowHeader
como uma resposta para chamadas de API.
Mensagem de erro
O aplicativo cliente recebe este código de resposta:
HTTP/1.1 502 Bad Gateway
Além disso, talvez você veja 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 código de status 405 Method Not Allowed
sem o cabeçalho Allow
.
De acordo com a especificação
RFC 7231, seção 6.5.5: método 405 não permitido (link em inglês), espera-se que o servidor de origem
PRECISA gerar e enviar um campo de cabeçalho Allow
em uma resposta 405
contendo uma
lista dos métodos com suporte atual do recurso de destino. Caso contrário, a Apigee responde com 502 Bad Gateway
e o código de 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 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 Edge como um 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.
Trace o Código de falha em relação a Time.
Selecione uma célula que tenha o código de falha
protocol.http.Response405WithoutAllowHeader
, conforme mostrado abaixo:As informações sobre o código de falha
protocol.http.Response405WithoutAllowHeader
são mostradas conforme mostrado abaixo:Clique em Ver registros e abra uma das solicitações com falha para conferir mais informações.
- Na janela Registros, observe os seguintes detalhes:
- Código de status:
502
- Origem da falha:
target
- Código de falha:
protocol.http.Response405WithoutAllowHeader
.
- Código de status:
- Se a Origem da falha for
target
e o Código de falha forprotocol.http.Response405WithoutAllowHeader
, isso indica que o servidor de back-end respondeu com o código de status405 Method Not Allowed
sem o cabeçalhoAllow
.
Ferramenta de rastreamento
Para diagnosticar o erro usando a ferramenta Trace:
- 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
- Aguarde a ocorrência do erro
Verifique se a opção Mostrar todos os FlowInfos está ativada:
- Selecione uma das solicitações com falha e examine o rastro.
- Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.
Você vai encontrar o erro normalmente em um fluxo após a fase Solicitação enviada para o servidor de destino, conforme mostrado abaixo:
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 resposta405
sem o cabeçalhoAllow
.- Navegue até a fase AX (Dados do Analytics registrados) no rastreamento e clique nela.
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:
- Você verá os valores de X-Apigee-fault-code e X-Apigee-fault-source como
protocol.http.Response405WithoutAllowHeader
etarget
, respectivamente, indicando que esse erro foi causado porque o back-end enviou o código de status de resposta405
sem o cabeçalhoAllow
.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:
- 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
. 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.
- Pesquise se há algum erro
502
com o códigoprotocol.http.Response405WithoutAllowHeader
durante um período específico (se o problema aconteceu anteriormente) ou se ainda há alguma solicitação com falha com502
. Se você encontrar erros
502
com o X-Apigee-fault-code correspondente ao valor deprotocol.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
Causa: resposta 405 sem o cabeçalho "Allow" do servidor de back-end
Diagnóstico
- Determine o código de falha e a origem da falha do
502 Bad Gateway
usando o monitoramento de APIs, a ferramenta de rastreamento ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico. - Se o código de falha for
protocol.http.Response405WithoutAllowHeader
e a origem da falha tiver o valortarget
, isso indica que o servidor de back-end respondeu com um código de status405
sem o cabeçalhoAllow
. Portanto, a Apigee responde com502 Bad Gateway
com o código de erroprotocol.http.Response405WithoutAllowHeader
.
Resolução
Use um dos seguintes métodos para resolver o problema:
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":
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çalhoAllow
, conforme mostrado abaixo:Allow: HTTP_METHODS
- Por exemplo, se o servidor de back-end permitir os métodos
GET
,POST
eHEAD
, será necessário garantir que o cabeçalhoAllow
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:
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çalhoAllow
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>
Crie um
FaultRule
noTargetEndpoint
, que invoca a política ao receber o erro502
com o código de erroprotocol.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>
- Salve essas alterações em uma nova revisão do proxy de API e implante a revisão.
- Faça as chamadas de API e verifique se você está recebendo o código de status
405
com o cabeçalhoAllow
.
Configurar propriedade
Opção 3: configurar a propriedade no processador de mensagens para impedir que o Apigee Edge retorne o erro 502
- Se você for um usuário da nuvem privada, poderá atualizar a propriedade
HTTP.ignore.allow_header.for.405
paratrue
a fim de evitar que o Apigee Edge gere um erro502
, mesmo que o servidor de back-end responda com o código de status405
sem o cabeçalhoAllow
usando o guia de instruções: Como configurar o cabeçalho "ignorar permitir" para a propriedade 405 em processadores de mensagens. - Se você for 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 com
o cabeçalho Allow
de acordo com as seguintes 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 solução recomendada é corrigir o servidor de back-end para enviar o código de status 405
com o cabeçalho Allow
e aderir à especificação
RFC 7231, seção 6.5.5: método 405 não permitido (em inglês).
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 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 o502 Bad Gateway
com o código de erroprotocol.http.Response405WithoutAllowHeader
- 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
- Arquivo de rastreamento das 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