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:
- Faça login na interface do Edge como um usuário com um para o papel apropriado.
Alterne para a organização na qual você deseja investigar o problema.
- Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
- Selecione o período específico em que você observou os erros.
Compare Código de falha com Time.
Selecione uma célula que contenha o código de falha
protocol.http.Response405WithoutAllowHeader
, conforme mostrado abaixo:Informações sobre o código de falha
protocol.http.Response405WithoutAllowHeader
é exibido conforme mostrado abaixo:Clique em Ver registros e abra uma das solicitações com falha para ver mais informações.
- Na janela Registros, observe os seguintes detalhes:
- Código de status:
502
- Origem da falha:
target
- Código da falha:
protocol.http.Response405WithoutAllowHeader
.
- Código de status:
- Se a Origem da falha for
target
e o Código da falha forprotocol.http.Response405WithoutAllowHeader
, isso indica que o back-end servidor respondeu com o código de status405 Method Not Allowed
sem oAllow
.
Ferramenta Trace
Para diagnosticar o erro usando a ferramenta Trace:
- 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
- Aguarde a ocorrência do erro
Verifique se Mostrar todos os FlowInfos está ativado:
- Selecione uma das solicitações com falha e examine o trace.
- Navegar pelas diferentes fases do trace e localizar onde a falha ocorreu.
Você encontrará o erro normalmente em um fluxo após a Request enviada to target server. fase, conforme mostrado abaixo:
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 resposta405
sem o cabeçalhoAllow
.- Navegue até a fase AX (dados do Analytics registrados) no trace e clique nela.
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:
- Os valores de X-Apigee-fault-code e X-Apigee-fault-source aparecerão como
protocol.http.Response405WithoutAllowHeader
etarget
, respectivamente, indicando que esse erro foi causado porque o back-end enviou a Código de status da 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 registros de acesso do NGINX:
- 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
. 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ó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 com502
: Se você encontrar erros
502
com o X-Apigee-fault-code que corresponde ao deprotocol.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
- 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. - Se o Código da falha for
protocol.http.Response405WithoutAllowHeader
e A origem da falha tem o valortarget
, o que 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 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":
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çalhoAllow
conforme mostrado abaixo:Allow: HTTP_METHODS
- Por exemplo, se o servidor de back-end permitir
GET
,POST
eHEAD
, é necessário garantir que o cabeçalhoAllow
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:
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çalhoAllow
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>
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 do TargetEndpoint mostrando 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.
- Faça as chamadas de API e verifique se você está recebendo o código de status
405
com a CabeçalhoAllow
.
Configurar propriedade
Opção 3: configurar a propriedade no processador de mensagens para impedir que o Apigee Edge retornando o erro 502
- Se você for usuário da nuvem privada, poderá atualizar a propriedade
HTTP.ignore.allow_header.for.405
paratrue
para evitar que o Apigee Edge Gerando um erro502
, mesmo que o servidor de back-end responda com405
. sem o cabeçalhoAllow
usando o Guia de instruções: Configuração do cabeçalho "ignorar permissão" para a propriedade 405 em processadores de mensagens. - 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 o502 Bad Gateway
com o código de erroprotocol.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