500 Erro interno do servidor - BadPath

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 de 500 Internal Server Error com o código de erro protocol.http.BadPath como uma 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ê poderá encontrar a seguinte mensagem de erro:

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

Causas possíveis

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

De acordo com as especificações Seção 3 do RFC 3986: componentes da 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 com e sempre tenha uma barra (/).

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

Por exemplo: se target.url tiver o valor https://www.mocktarget.apigee.net?json, esse erro vai ocorrer à medida que path é inválido porque 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 da falha e a origem da falha do 500 Internal Server Error usando os registros de acesso do API Monitoring, da ferramenta Trace ou 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 objeto invalid caminho de conversão.

3. O URL do servidor de back-end é representado pela variável de fluxo target.url na Apigee Borda Esse erro normalmente acontece quando você tenta atualizar o URL do servidor de back-end. (target.url) dinamicamente usando qualquer uma das políticas (dentro de proxy/fluxo compartilhado) 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 erro inválido path e a origem do valor usando um dos seguintes métodos:

   Trace

   Como usar a ferramenta Trace

   Se você capturou um rastro para esse erro, use as etapas explicadas em 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. Em caso afirmativo, descubra a política que modificou ou atualizou o valor de target.url conter um caminho inválido.

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

      
   3. No trace de amostra acima, observe que a política de JavaScript modificou ou atualizou o valor de target.url para conter um caminho inválido.
   4. O target.url tem estes componentes:
      • esquema: https
      • autoridade: mocktarget.apigee.net
      • caminho: ?json

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

   Registros

   Como usar registros no servidor de registros

   1. Se não houver rastreamento para esse erro (um problema intermitente), verifique se você registrou as informações sobre o valor da variável de fluxo target.url, com o uso de políticas como MessageLogging ou Service callout ao seu servidor de registros.
   2. Se você tiver os registros, revise-os
      1. Verifique se target.url tem um caminho inválido.
      2. Veja se é possível determinar as informações sobre qual política foi modificada target.url deve conter um caminho inválido

   Proxy de API

   Como analisar o proxy de API com falha

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

   • A política no proxy de API
   • Quaisquer 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 determina a causa atualizando target.url para ter um caminho inválido.

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

   Amostra 1

   Exemplo 1: política de JavaScript atualizando a variável target.url

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

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

   O valor de url tem estes componentes:

   • esquema: https
   • autoridade: mocktarget.apigee.net
   • caminho: ?json

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

   Amostra 2

   Exemplo 2: política de 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 foi atualizada concatenando o valor https://mocktarget.apigee.net contido em um url e o valor de outra variável path, cujo valor é recuperado de request.header.Path.

   Se você tiver acesso à solicitação ou ao trace 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 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 estes componentes:

   • esquema: https
   • autoridade: mocktarget.apigee.net
   • caminho: ?user

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

   Amostra 3

   Exemplo 3: política AttributionMessage 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>

   Observe que o valor de url tem os seguintes componentes:

   • esquema: https
   • autoridade: mocktarget.apigee.net
   • caminho: ?echo

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

Resolução

De acordo com a especificação do URL RFC 3986, seção 3: componentes de sintaxe, o componente path é obrigatório. e PRECISA sempre 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 um (/).
   1. Em alguns casos, pode não haver um nome de recurso no caminho, então certifique-se de que o o caminho tenha pelo menos uma barra (/).
   2. Se você usa outras variáveis para determinar o valor da variável de fluxo target.url e, em seguida, verifique se outras variáveis não têm um caminho inválido.
   3. Se você executar qualquer operação de string para determinar o valor da variável de fluxo target.url, depois verifique se o resultado ou resultado da string operações não têm um caminho inválido.

2. Nos exemplos discutidos acima, você pode corrigir esse problema conforme explicado abaixo:

   Amostra 1

   Exemplo 1: política de JavaScript atualizando a variável target.url

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

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

   Amostra 2

   Exemplo 2: política de 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);

   Verifique se você está transmitindo um caminho válido, por exemplo: /user como parte da solicitação cabeçalho 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"
   

   Amostra 3

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

   Adicione um caminho válido no elemento <Value> da políticaAssignMessage. Ou seja, substitua o ponto de interrogação (?) por um barra (/) no elemento <Value> e defina-o 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 PRECISA sempre começar com uma barra (/) da seguinte forma: especificações:

   Especificação
   Seção 3 do RFC 3986: componentes da sintaxe
   RFC 3986, seção 3.3: caminho

   Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisa 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 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 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~ENV.PORT#_access_log

     Onde: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