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
targete o Código da falha forprotocol.http.Response405WithoutAllowHeader, isso indica que o back-end servidor respondeu com o código de status405 Method Not Allowedsem 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 Gatewayou - Se for possível reproduzir o problema, faça a chamada de API para reproduzir o problema -
502 Bad Gatewayerro
- 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 resposta405sem 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.Response405WithoutAllowHeaderetarget, respectivamente, indicando que esse erro foi causado porque o back-end enviou a Código de status da resposta405sem o cabeçalhoAllow.Cabeçalhos de resposta Valor X-Apigee-fault-code protocol.http.Response405WithoutAllowHeaderX-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
502com o código de erro.protocol.http.Response405WithoutAllowHeaderdurante um período específico (se o ocorreu no passado) ou se há alguma solicitação ainda falhando com502: Se você encontrar erros
502com 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.Response405WithoutAllowHeaderX-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.Response405WithoutAllowHeadere A origem da falha tem o valortarget, o que indica que o servidor de back-end respondeu com um código de status405sem o cabeçalhoAllow. Portanto, A Apigee responde com502 Bad Gatewaycom 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
405incluindo a lista de métodos permitidos como parte de um cabeçalhoAllowconforme mostrado abaixo:Allow: HTTP_METHODS
- Por exemplo, se o servidor de back-end permitir
GET,POSTeHEAD, é necessário garantir que o cabeçalhoAllowcontenha 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 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íticaAssignMessage ou a política liftFault e defina o código de status como
405com um cabeçalhoAllowe 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
FaultRulenoTargetEndpoint, que invoca a política ao receber o erro502com 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
405com 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.405paratruepara evitar que o Apigee Edge Gerando um erro502, mesmo que o servidor de back-end responda com405. sem o cabeçalhoAllowusando 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
curlcompleto usado para reproduzir o502 Bad Gatewaycom 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