500 Erro interno do servidor - BadPath

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 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 este código de resposta:

HTTP/1.1 500 Internal Server Error

Além disso, talvez você veja a seguinte mensagem de erro:

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

Causas possíveis

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

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

1. A sintaxe do 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 uma barra (/) e sempre ter 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 (/), o Apigee Edge responderá com 500 Internal Server Error e o 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 porque o path é considerado inválido,já que ele começa com um ponto de interrogação (?) em vez de uma barra (/).

Causa	Descrição	Instruções de solução de problemas aplicáveis para
O URL do servidor de back-end (target.url) tem um caminho inválido	O componente de caminho no URL do servidor de back-end representado pela variável de fluxo target.url começa com um ponto de interrogação (?) em vez de uma barra (/).	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:

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 de 500 Internal Server Error usando os registros de acesso do NGINX, da ferramenta de rastreamento ou do Monitoring de API, conforme explicado em Etapas comuns de diagnóstico.
2. Se o Código de 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 na Apigee Edge. Este erro geralmente ocorre 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 caminho inválido e a origem do valor usando um dos métodos a seguir:

   Trace

   Como usar a ferramenta Trace

   Se você capturou um rastro para esse erro, use as etapas explicadas em Como usar a ferramenta de rastreamento 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 para conter um caminho inválido.

      O rastro de exemplo que mostra a política JavaScript atualizou a variável de fluxo target.url

      
   3. No exemplo de trace acima, observe que a política de JavaScript modificou ou atualizou o valor de target.url para conter um caminho inválido.
   4. Observe que a target.url tem os seguintes componentes:
      • esquema: https
      • autoridade: mocktarget.apigee.net
      • caminho:?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 trace para esse erro (um problema intermitente), verifique se você registrou as informações sobre o valor da variável de fluxo target.url usando políticas como MessageLogging ou Service callout para o servidor de registros.
   2. Se você tiver os registros, revise-os e
      1. Verifique se target.url tem um caminho inválido.
      2. Tente determinar as informações sobre qual política modificou target.url para 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 desse erro, analise 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 os seguintes itens:

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

5. Analise a política específica com atenção (por exemplo, AttributionMessage ou JavaScript) que modifica ou atualiza a variável de fluxo target.url e determine a causa da atualização de target.url para que ela tenha um caminho inválido.

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

   Amostra 1

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

   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..

   Observe que o valor do url tem os seguintes 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álido. Portanto, o Apigee Edge retorna 500 Internal Server Error com o código de erro protocol.http.BadPath.

   Amostra 2

   Amostra 2: Política de JavaScript atualizando a variável target.url com base no valor no 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 ao concatenar 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 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.

   Portanto:

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

   Observe que o valor do target.url tem os seguintes 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álido. Portanto, o 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á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 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 uma barra (/).
   1. Em alguns casos, pode ser que você não tenha um nome de recurso no caminho. Portanto, verifique se ele 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 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, verifique se o resultado ou resultado das operações de string não tem um caminho inválido.

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

   Amostra 1

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

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

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

   Amostra 2

   Amostra 2: Política de JavaScript atualizando a variável target.url com base no valor no 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 da 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"
   

   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 uma 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 componente path no URL do servidor de back-end PRECISA sempre começar com uma barra (/) de acordo com as especificações a seguir:

   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 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 da API
   • Completar o comando curl usado para reproduzir o 500 Internal Server Error com o código de erro protocol.http.BadPath
   • 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~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: meta