500 Erro interno do servidor - EmptyPath

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.EmptyPath 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":"Request path cannot be empty",
      "detail":{
         "errorcode":"protocol.http.EmptyPath"
      }
   }
}

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 um caminho vazio.

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 ter sempre uma barra. (/), mesmo que não haja outros caracteres como parte do caminho.

Portanto, se o URL de solicitação do servidor de back-end não tiver o atributo path ou seja, ele nem tem uma barra (/), então a Apigee O Edge responde com 500 Internal Server Error e um código de erro. protocol.http.EmptyPath.

Por exemplo: se target.url tiver o valor https://www.mocktarget.apigee.net, esse erro vai ocorrer à medida que path O componente está vazio ou faltando.

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 vazio	O URL do servidor de back-end representado pela variável de fluxo target.url tem um caminho vazio.	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:

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

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.EmptyPath e a Origem da falha tiver o valor target, isso indica que o URL do servidor de back-end tem um objeto vazio 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, ou seja, target.url dinamicamente usando qualquer uma das políticas (dentro proxy/fluxo compartilhado) no fluxo de solicitação de destino, de modo que ele tenha um caminho vazio.

4. Determine se a variável de fluxo target.url realmente tem um caminho vazio e o origem para seu valor seguindo uma das etapas 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 Trace e:

   1. Verifique se target.url tem um caminho vazio.

   2. Em caso afirmativo, descubra qual política modificou ou atualizou o valor de target.url para conter um caminho vazio.

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

      
   3. Na amostra de trace acima, observe que a política do JavaScript foi modificada ou atualizou o valor de target.url para conter um caminho vazio.
   4. O target.url tem estes componentes:
      • esquema: https://mocktarget.apigee.net
      • path:vazio

   Registros

   Como usar registros no servidor de registros

   1. Se não houver rastreamento desse erro (um problema intermitente), verifique 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 ServiceCall ao seu servidor de registros.
   2. Se você tiver os registros, revise-os e faça o seguinte:
      1. Verifique se target.url tem um caminho vazio.
      2. Verifique se é possível determinar qual política modificou target.url conter um caminho vazio

   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 a política específica (por exemplo, AssignMessage ou JavaScript) que modifica ou atualiza a variável de fluxo target.url cuidadosamente e determina a causa da atualização target.url para ter um caminho vazio.

   Confira alguns exemplos de políticas que atualizam a variável de fluxo target.url para conter um caminho vazio 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"
   context.setVariable("target.url", url);
   

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

   O target.url tem estes componentes:

   • esquema: https://mocktarget.apigee.net
   • path:vazio

   Como o caminho está vazio, o Apigee Edge retorna 500 Internal Server Error com código de erro protocol.http.EmptyPath.

   Amostra 2

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

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

   No exemplo acima, a variável de fluxo target.url é atualizada pela concatenando o valor https://mocktarget.apigee.net contido em uma variável url e o valor de outra variável path, cuja 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>
   

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

   Então:

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + null
   • target.url = https://mocktarget.apigee.netnull

   Observe que target.url tem os seguintes componentes:

   • esquema: https://mocktarget.apigee.netnull
   • path:vazio

   Amostra 3

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

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

   Observe que target.url tem os seguintes componentes:

   • esquema: https://mocktarget.apigee.net
   • path:vazio

   Em todos os exemplos acima, o caminho no URL do servidor de back-end, que é target.url está vazio, portanto, o Apigee Edge retorna 500 Internal Server Error com o código de erro protocol.http.EmptyPath.

Resolução

De acordo com a especificação RFC 3986, seção 2: componentes da sintaxe, o componente path é obrigatório e PRECISA ter sempre uma barra (/), mesmo que não haja outros caracteres como parte de path. Siga estas etapas 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 não vazio.
   1. Em alguns casos, pode não haver um nome de recurso no caminho. Verifique se 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 verifique se as outras variáveis não têm um caminho vazio.
   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 tem um caminho vazio.
2. Nas amostras discutidas em Diagnóstico, é possível corrigir esse problema da seguinte forma: explicados abaixo:

   Amostra 1

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

   Adicione uma barra (/) à variável url para corrigir isso como mostrado abaixo:

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

   Amostra 2

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

   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, /iloveapis como parte 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: /iloveapis"
   

   Amostra 3

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

   Adicione um caminho válido no elemento <Value> da políticaAssignMessage. Para exemplo, é possível ter /json como o caminho API MockTarget. Ou seja, modifique o elemento <Value> para https://mocktarget.apigee.net/json, como 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/json</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>
   

Especificação

O Apigee Edge espera que o URL do servidor de back-end não tenha um caminho vazio, de acordo com as seguintes 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 É 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 o 500 Internal Server Error com o código de erro protocol.http.EmptyPath
• 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