500 Erro interno do servidor - BadPath

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um código de status HTTP 500 Internal Server Error com o código de erro protocol.http.BadPath como resposta para chamadas de API.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 500 Internal Server Error

Além disso, você pode receber a seguinte mensagem de erro:

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

Causas possíveis

Esse erro ocorre se o URL de solicitação do servidor de back-end, representado pela variável de fluxo target.url, contiver um path que começa com um ponto de interrogação (?) em vez de uma barra (/), o que é inválido.

De acordo com as especificações RFC 3986, seção 3: componentes de sintaxe e RFC 3986, seção 3.3: caminho:

1. A sintaxe de URI tem os seguintes componentes:

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. O componente path é obrigatório e precisa começar e sempre ter uma barra (/).

Portanto, se o URL de solicitação do servidor de back-end tiver um componente path que começa com um ponto de interrogação (?) em vez de uma barra (/), o Apigee Edge vai responder com 500 Internal Server Error e o código de erro protocol.http.BadPath.

Por exemplo, se o target.url tiver o valor https://www.mocktarget.apigee.net?json, esse erro vai ocorrer porque o path será considerado inválido, já que começa com um ponto de interrogação (?) em vez de uma barra (/).

Etapas comuns do diagnóstico

Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:

Causa: o URL do servidor de back-end (target.url) tem um caminho inválido

Diagnóstico

1. Determine o código de falha e a origem da falha para 500 Internal Server Error usando o API Monitoring, 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.BadPath e a Origem da falha tiver o valor target, isso indica que o URL do servidor de back-end tem um caminho inválido.

3. O URL do servidor de back-end é representado pela variável de fluxo target.url no Apigee Edge. Esse erro geralmente ocorre se você tentar atualizar o URL do servidor de back-end (target.url) dinamicamente usando qualquer uma das políticas (no fluxo compartilhado/proxy) no fluxo de solicitação de destino, de modo que ele tenha um caminho inválido.

4. Determine se a variável de fluxo target.url realmente tem um caminho inválido e a origem do valor dela usando um dos seguintes métodos:

   Trace

   Como usar a ferramenta Trace

   Se você capturou um trace desse erro, siga as etapas explicadas em Como usar a ferramenta Trace e

   1. Verifique se target.url tem um caminho inválido, ou seja, se ele começa com um ponto de interrogação (?) em vez de uma barra (/).

   2. Se sim, descubra a política que modificou ou atualizou o valor de target.url para conter um caminho inválido.

      Exemplo de rastreamento mostrando que a política de JavaScript atualizou a variável de fluxo target.url

      
   3. No rastreamento de exemplo acima, observe que a política do JavaScript modificou ou atualizou o valor de target.url para conter um caminho inválido.
   4. O target.url tem os seguintes componentes:
      • scheme: https
      • authority: mocktarget.apigee.net
      • path: ?json

      O caminho começa com um ponto de interrogação (?) em vez de uma barra (/), portanto, ele é inválido.

   Registros

   Como usar registros no servidor de registros

   1. Se você não tiver um rastreamento para esse erro (um problema intermitente), verifique se registrou as informações sobre o valor da variável de fluxo target.url, usando políticas como MessageLogging ou ServiceCallout no seu servidor de registros.
   2. Se você tiver os registros, analise-os e
      1. Verifique se target.url tem um caminho inválido e
      2. Determine qual política modificou target.url para conter um caminho inválido.

   Proxy de API

   Analisar o proxy de API com falha

   Se você não tiver um rastreamento ou registros desse erro, revise o proxy de API com falha para determinar o que modificou ou atualizou a variável de fluxo target.url para conter um caminho inválido. Verifique se:

   • A política no proxy de API
   • Todos os fluxos compartilhados invocados do proxy

5. Examine cuidadosamente a política específica (por exemplo, AssignMessage ou JavaScript) que modifica ou atualiza a variável de fluxo target.url e determine a causa da atualização de target.url para ter um caminho inválido.

   Confira alguns exemplos de políticas que atualizam a variável de fluxo target.url de maneira incorreta para conter um caminho inválido que causa esse erro.

   Exemplo 1

   Exemplo 1: atualização da política de JavaScript da variável target.url

   var url = "https://mocktarget.apigee.net?json"
   context.setVariable("target.url", url);

   No exemplo acima, observe que a variável de fluxo target.url é atualizada com o valor https://mocktarget.apigee.net?json contido em outra variável url..

   O valor do url tem os seguintes componentes:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?json

   O caminho começa com um ponto de interrogação (?) em vez de uma barra (/), o que é inválido. Portanto, o Apigee Edge retorna 500 Internal Server Error com o código de erro protocol.http.BadPath.

   Exemplo 2

   Exemplo 2: política JavaScript atualizando a variável target.url com base no valor do cabeçalho da solicitação

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   No exemplo acima, observe que a variável de fluxo target.url é atualizada concatenando o valor https://mocktarget.apigee.net contido em uma variável url e o valor de outra variável path, cujo valor é recuperado de request.header.Path.

   Se você tiver acesso à solicitação ou ao rastreamento real, poderá verificar o valor real transmitido para request.header.Path.

   Exemplo de solicitação feita pelo usuário

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   Neste exemplo, o caminho do cabeçalho não é enviado como parte da solicitação. Portanto, o valor da variável path na política de JavaScript é null.

   Então:

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   O valor de target.url tem os seguintes componentes:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?user

   O caminho começa com um ponto de interrogação (?) em vez de uma barra (/), o que é inválido. Portanto, o Apigee Edge retorna 500 Internal Server Error com o código de erro protocol.http.BadPath.

   Exemplo 3

   Exemplo 3: política AssignMessage atualizando a variável target.url

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net?echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   O valor de url tem os seguintes componentes:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?echo

   Neste exemplo, o caminho começa com um ponto de interrogação (?) em vez de uma barra (/), o que é inválido. Portanto, o Apigee Edge retorna 500 Internal Server Error com o código de erro protocol.http.BadPath.

Resolução

De acordo com a especificação de URL RFC 3986, seção 3: componentes de sintaxe, o componente path é obrigatório e sempre precisa começar com "/". Siga as etapas abaixo para corrigir esse problema:

1. Verifique se o URL do servidor de back-end, representado pela variável de fluxo target.url, sempre tem um caminho válido e sempre começa com uma barra (/).
   1. Em alguns casos, talvez não haja um nome de recurso no caminho. Nesse caso, verifique se o caminho tem pelo menos uma barra (/).
   2. Se você usar outras variáveis para determinar o valor da variável de fluxo target.url, verifique se elas não têm um caminho inválido.
   3. Se você realizar operações de string para determinar o valor da variável de fluxo target.url, verifique se o resultado ou o resultado das operações de string não tem um caminho inválido.

2. Nos exemplos discutidos acima, você pode corrigir esse problema da seguinte forma:

   Exemplo 1

   Exemplo 1: atualização da política de JavaScript da variável target.url

   Use uma barra (/) em vez de um ponto de interrogação (?) na variável url para corrigir esse problema, como mostrado abaixo:

   var url = "https://mocktarget.apigee.net/json"
   context.setVariable("target.url", url);

   Exemplo 2

   Exemplo 2: política JavaScript atualizando a variável target.url com base no valor do cabeçalho da solicitação

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   Transmita um caminho válido, por exemplo: /user como parte do cabeçalho de solicitação Path para corrigir esse problema, conforme mostrado abaixo:

   Exemplo de solicitação:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   Exemplo 3

   Exemplo 3: política AssignMessage atualizando a variável target.url

   Adicione um caminho válido no elemento <Value> da política AssignMessage. Ou seja, substitua o ponto de interrogação (?) por uma barra (/) no elemento <Value> e defina como https://mocktarget.apigee.net/echo para corrigir esse problema, conforme mostrado abaixo:

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   Especificação

   O Apigee Edge espera que o path componente no URL do servidor de back-end SEMPRE comece com uma barra (/) , de acordo com as seguintes especificações:

   Especificação
   RFC 3986, seção 3: componentes de sintaxe
   RFC 3986, seção 3.3: caminho

   Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisa de 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, reúna as seguintes 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 de API
   • Comando curl completo usado para reproduzir o 500 Internal Server Error com o código de erro protocol.http.BadPath
   • Arquivo de rastreamento para as solicitações de API

   Se você for um usuário da nuvem privada, forneça as seguintes 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~ENV.PORT#_access_log

     Em que:ORG, ENV 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

   Variáveis de fluxo: destino