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:
A sintaxe de URI tem os seguintes componentes:
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment- 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:
Monitoramento de APIs
Procedimento no 1: como usar o monitoramento de APIs
Para diagnosticar o erro usando a API Monitoring:
- Faça login na interface do Apigee Edge como usuário com uma função apropriada.
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 tenha o código de falha
protocol.http.EmptyPath, conforme mostrado abaixo:
As informações sobre o código de falha
protocol.http.EmptyPathsão exibidas como mostrados abaixo:
Clique em Ver registros para expandir a linha da solicitação com falha.
- Na janela Registros, observe os seguintes detalhes:
- Código de status:
500 - Origem da falha:
target - Código da falha:
protocol.http.EmptyPath
- Código de status:
- Se a Origem da falha for
targete o Código da falha forprotocol.http.EmptyPath, isso indica que o URL do servidor de back-end tem um caminho vazio.
Trace
Procedimento no 2: como usar a ferramenta Trace
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a sessão de rastreamento e
- Aguarde a ocorrência do erro
500 Internal Server Errorou - Se você puder reproduzir o problema, faça a chamada de API para reproduzir o problema
500 Internal Server Error
- 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.
Normalmente, o erro está em um fluxo após o início do fluxo de solicitação de destino. fase, conforme mostrado abaixo:
Anote o valor do erro do trace.
error: O caminho da solicitação não pode ficar vazio
Como o erro é gerado pelo Apigee Edge após a fase Fluxo de solicitação de destino iniciado, isso indica que o
pathno URL do servidor de back-end está vazio. Isso provavelmente acontecerá se a variável de fluxotarget.url(que representa o URL do servidor de back-end ) foi possivelmente atualizado com um caminho vazio por meio de uma das políticas no fluxo de solicitação.- Examine a seção Variáveis lidas e atribuídas em cada um dos fluxos inversos do de erro para a fase Fluxo de solicitação de destino iniciado.
Determine a política em que a variável de fluxo
target.urlé atualizada.Exemplo de trace mostrando que a política JavaScript atualizou a variável de fluxo
target.url:
No trace de amostra mostrado acima, observe o valor da variável de fluxo
target.urlé atualizado em uma política de JavaScript chamada SetTargetURL como da seguinte forma:target.url : https://mocktarget.apigee.net
- Observe que
target.urltem os seguintes componentes:- esquema:
https://mocktarget.apigee.net - path:vazio
- esquema:
- Portanto, você recebe o erro
Request path cannot be empty. - Navegue até a fase AX (dados do Analytics registrados) no trace e clique nela.
Role para baixo até a seção Detalhes da fase - Cabeçalhos de erro e determine as 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.EmptyPathetarget, respectivamente, indicando que esse erro é causado porque o URL do servidor de back-end tem um caminho vazio.Cabeçalhos de resposta Valor X-Apigee-fault-code protocol.http.EmptyPathX-Apigee-fault-source target
NGINX
Procedimento no 3: como usar registros de acesso do 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
as principais informações sobre o
500 Internal Server Errordo HTTP. Verifique os registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log- Pesquise se há algum erro
500com o código de erro.protocol.http.EmptyPathdurante um período específico (se o problema tiver acontecido em no passado) ou se ainda há solicitações com falha com500. Se você encontrar erros
500com a correspondência X-Apigee-fault-code o valor deprotocol.http.EmptyPathe, em seguida, determine o valor do X-Apigee-fault-source.Exemplo de erro 500 do registro de acesso do NGINX:
O exemplo de entrada do registro de acesso do NGINX acima tem os seguintes valores para X- Apigee-fault-code e X-Apigee-fault-source:
Cabeçalhos Valor X-Apigee-fault-code protocol.http.EmptyPathX-Apigee-fault-source targetOs valores de X-Apigee-fault-code e X-Apigee-fault-source são
protocol.http.EmptyPathetarget, respectivamente, indicando que esse erro é causado porque o URL do servidor de back-end tem um caminho vazio.
Causa: o URL do servidor de back-end (target.url) tem um caminho vazio
Diagnóstico
- Determine o código da falha e a origem da falha do
500 Internal Server Errorusando os registros de acesso do API Monitoring, da ferramenta Trace ou do NGINX, conforme explicado em Etapas comuns de diagnóstico. - Se o Código da falha for
protocol.http.EmptyPathe a Origem da falha tiver o valortarget, isso indica que o URL do servidor de back-end tem um objeto vazio caminho de conversão. O URL do servidor de back-end é representado pela variável de fluxo
target.urlna Apigee Borda Esse erro normalmente acontece quando você tenta atualizar o URL do servidor de back-end, ou seja,target.urldinamicamente 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.- Determine se a variável de fluxo
target.urlrealmente 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:
- Verifique se
target.urltem um caminho vazio. Em caso afirmativo, descubra qual política modificou ou atualizou o valor de
target.urlpara conter um caminho vazio.Exemplo de trace mostrando que a política JavaScript atualizou a variável de fluxo
target.url:
- Na amostra de trace acima, observe que a política do JavaScript foi modificada ou
atualizou o valor de
target.urlpara conter um caminho vazio. - O
target.urltem estes componentes:- esquema:
https://mocktarget.apigee.net - path:vazio
- esquema:
Registros
Como usar registros no servidor de registros
- 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. - Se você tiver os registros, revise-os e faça o seguinte:
- Verifique se
target.urltem um caminho vazio. - Verifique se é possível determinar qual política modificou
target.urlconter um caminho vazio
- Verifique se
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.urlconter um caminho inválido. Verifique os seguintes itens:- A política no proxy de API
- Quaisquer fluxos compartilhados invocados do proxy
- Verifique se
Examine a política específica (por exemplo, AssignMessage ou JavaScript) que modifica ou atualiza a variável de fluxo
target.urlcuidadosamente e determina a causa da atualizaçãotarget.urlpara ter um caminho vazio.Confira alguns exemplos de políticas que atualizam a variável de fluxo
target.urlpara conter um caminho vazio que leva a esse erro.Amostra 1
Exemplo 1: política de JavaScript atualizando a variável
target.urlvar url = "https://mocktarget.apigee.net" context.setVariable("target.url", url);
No exemplo acima, observe que a variável de fluxo
target.urlfoi atualizada com o valorhttps://mocktarget.apigee.netcontido em outra variávelurlO
target.urltem estes componentes:- esquema:
https://mocktarget.apigee.net - path:vazio
Como o caminho está vazio, o Apigee Edge retorna
500 Internal Server Errorcom código de erroprotocol.http.EmptyPath.Amostra 2
Exemplo 2: política de JavaScript atualizando a variável
target.urlvar 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 valorhttps://mocktarget.apigee.netcontido em uma variávelurle o valor de outra variávelpath, cuja valor é recuperado derequest.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 + pathurl = https://mocktarget.apigee.net + nulltarget.url = https://mocktarget.apigee.netnull
Observe que
target.urltem os seguintes componentes:- esquema:
https://mocktarget.apigee.netnull - path:vazio
Amostra 3
Exemplo 3: política AttributionMessage atualizando a variável
target.urlpor 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.urltem 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.urlestá vazio, portanto, o Apigee Edge retorna500 Internal Server Errorcom o código de erroprotocol.http.EmptyPath.- esquema:
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:
- Verifique se o URL do servidor de back-end, representado pela variável de fluxo
target.urlsempre tem um caminho não vazio.- Em alguns casos, pode não haver um nome de recurso no caminho. Verifique se o caminho
tenha pelo menos uma barra (
/). - Se você usa outras variáveis para determinar o valor da variável de fluxo
target.urle verifique se as outras variáveis não têm um caminho vazio. - 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.
- Em alguns casos, pode não haver um nome de recurso no caminho. Verifique se o caminho
tenha pelo menos uma barra (
- 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.urlAdicione uma barra (
/) à variávelurlpara 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.urlvar 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,
/iloveapiscomo parte cabeçalho da solicitaçãoPathpara 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.urlpor meio outra variávelAdicione um caminho válido no elemento
<Value>da políticaAssignMessage. Para exemplo, é possível ter/jsoncomo o caminho API MockTarget. Ou seja, modifique o elemento<Value>parahttps://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
curlcompleto usado para reproduzir o500 Internal Server Errorcom o código de erroprotocol.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_logOnde: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