Estás viendo la documentación de Apigee Edge.
Ir a la documentación de
Apigee X. info
Síntoma
La aplicación cliente obtiene un código de estado HTTP 500 Internal Server Error con el código de error protocol.http.BadPath como respuesta a las llamadas a la API.
Mensaje de error
La aplicación cliente obtiene el siguiente código de respuesta:
HTTP/1.1 500 Internal Server Error
Además, es posible que observes el siguiente mensaje de error:
{
"fault":{
"faultstring":"Invalid request path",
"detail":{
"errorcode":"protocol.http.BadPath"
}
}
}Causas posibles
Este error se produce si la URL de la solicitud del servidor de backend, representada por la variable de flujo
target.url,
contiene un path que comienza con un signo de interrogación (?) en lugar
de una barra diagonal (/), que no es válida.
Según las especificaciones RFC 3986, sección 3: Componentes de sintaxis y RFC 3986, sección 3.3: Ruta de acceso:
La sintaxis del URI tiene los siguientes componentes:
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment- El componente
pathes obligatorio y DEBE comenzar con una barra diagonal (/) y tenerla siempre.
Por lo tanto, si la URL de la solicitud del servidor de backend tiene un componente path que comienza con un signo de interrogación (?) en lugar de una barra diagonal (/), Apigee Edge responde con 500 Internal Server Error y el código de error protocol.http.BadPath.
Por ejemplo, si target.url tiene el valor https://www.mocktarget.apigee.net?json, se produce este error, ya que se detecta que path es inválido, ya que comienza con un signo de interrogación (?) en lugar de una barra diagonal (/).
| Causa | Descripción | Instrucciones de solución de problemas aplicables para |
|---|---|---|
| La URL del servidor de backend (target.url) tiene una ruta de acceso no válida | El componente de ruta de acceso en la URL del servidor de backend representado por la variable de flujo target.url comienza con un signo de interrogación (?) en lugar de una barra diagonal (/). |
Usuarios de la nube pública y privada de Edge |
Pasos comunes de diagnóstico
Usa una de las siguientes herramientas o técnicas para diagnosticar este error:
Supervisión de API
Procedimiento 1: Usa la supervisión de API
Para diagnosticar el error con API Monitoring, haz lo siguiente:
- Accede a la IU de Apigee Edge como usuario con un rol adecuado.
Cambia a la organización en la que deseas investigar el problema.
- Navega a la página Analizar > Supervisión de API > Investigar.
- Selecciona el período específico en el que observaste los errores.
Representa gráficamente el código de falla en función del tiempo.
Selecciona una celda que tenga el código de falla
protocol.http.BadPath, como se muestra a continuación:
La información sobre el código de falla
protocol.http.BadPathse muestra como se indica a continuación:
Haz clic en Ver registros y expande la fila de la solicitud con errores.
- En la ventana Registros, ten en cuenta los siguientes detalles:
- Código de estado:
500 - Fuente del error:
target - Código de falla:
protocol.http.BadPath
- Código de estado:
- Si la Fuente de la falla es
targety el Código de falla esprotocol.http.BadPath, esto indica que la URL del servidor de backend tiene una ruta de acceso no válida.
Seguimiento
Procedimiento 2: Cómo usar la herramienta de Trace
Para diagnosticar el error con la herramienta Trace, haz lo siguiente:
- Habilita la sesión de registro y una de las siguientes opciones:
- Espera a que se produzca el error
500 Internal Server Error. - Si puedes reproducir el problema, realiza la llamada a la API para reproducirlo.
500 Internal Server Error
- Espera a que se produzca el error
Asegúrate de que la opción Mostrar todos los FlowInfos esté habilitada:

- Selecciona una de las solicitudes con errores y examina el registro.
- Navega por las diferentes fases del registro y ubica dónde se produjo la falla.
Por lo general, encontrarás el error en un flujo después de la fase Target Request Flow Started , como se muestra a continuación:

Ten en cuenta el valor del error del registro:
error: Invalid request path
Dado que Apigee Edge genera el error después de la fase Target Request Flow Started, indica que la URL del servidor de backend tiene una ruta de acceso no válida. Esto probablemente sucedería si la variable de flujo
target.url(que representa la URL del servidor de backend) en Apigee Edge se actualizó posiblemente con una ruta de acceso no válida a través de una de las políticas en el flujo de solicitudes de destino.- Examina la sección Variables Read and Assigned en cada uno de los flujos hacia atrás, desde el flujo de errores hasta la fase Target Request Flow Started.
- Determina la política en la que se actualizó la variable de flujo
target.url:Muestra de seguimiento en la que se muestra que la política de JavaScript actualizó la variable de flujo
target.url:
En el registro de muestra que se muestra arriba, observa que el valor de la variable de flujo
target.urlse actualiza en una política de JavaScript llamadaJS- SetTargetURLde la siguiente manera:target.url : https://mocktarget.apigee.net?json - Ten en cuenta que el valor en
target.urltiene los siguientes componentes:- scheme:
https - authority:
mocktarget.apigee.net - ruta:
?json
- scheme:
- Dado que el componente ruta comienza con un signo de interrogación (
?) en lugar de una barra diagonal (/), recibirás el errorInvalid request path. - Navega a la fase AX (datos de Analytics registrados) en el registro y haz clic en ella.
Desplázate hacia abajo hasta la sección Phase Details - Error Headers y determina los valores de X-Apigee-fault-code y X-Apigee-fault-source, como se muestra a continuación:

Verás los valores de X-Apigee-fault-code y X-Apigee-fault-source como
protocol.http.BadPathytarget, respectivamente, lo que indica que este error se debe a que la URL del servidor de backend tiene una ruta de acceso no válida.Encabezados de respuesta Valor X-Apigee-fault-code protocol.http.BadPathX-Apigee-fault-source target
NGINX
Procedimiento 3: Uso de registros de acceso de NGINX
Para diagnosticar el error con los registros de acceso de NGINX, haz lo siguiente:
- Si eres usuario de Private Cloud, puedes usar los registros de acceso de NGINX para determinar la información clave sobre
500 Internal Server Errorde HTTP. Verifica los registros de acceso de NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log- Busca si hay errores de
500con el código de errorprotocol.http.BadPathdurante un período específico (si el problema ocurrió en el pasado) o si aún hay solicitudes que fallan con500. Si encuentras errores de
500con el X-Apigee-fault-code que coincida con el valor deprotocol.http.BadPath, determina el valor de X-Apigee-fault-source.Ejemplo de error 500 del registro de acceso de NGINX:
La entrada de ejemplo anterior del registro de acceso de NGINX tiene los siguientes valores para X-Apigee-fault-code y X-Apigee-fault-source:
Encabezados Valor X-Apigee-fault-code protocol.http.BadPathX-Apigee-fault-source targetObserva que los valores de X-Apigee-fault-code y X-Apigee-fault-source son
protocol.http.BadPathytarget, respectivamente, lo que indica que este error se debe a que la URL del servidor de backend tiene una ruta de acceso no válida.
Causa: La URL del servidor de backend (target.url) tiene una ruta de acceso no válida
Diagnóstico
- Determina el código de error y la fuente del error para
500 Internal Server Errorcon la supervisión de API, la herramienta Trace o los registros de acceso de NGINX, como se explica en los pasos de diagnóstico comunes. - Si el Código de error es
protocol.http.BadPathy la Fuente del error tiene el valortarget, esto indica que la URL del servidor de backend tiene una ruta de acceso no válida. La URL del servidor de backend se representa con la variable de flujo
target.urlen Apigee Edge. Por lo general, este error se produce si intentas actualizar la URL del servidor de backend (target.url) de forma dinámica con cualquiera de las políticas (dentro del flujo compartido o del proxy) en el flujo de solicitud de destino, de modo que tenga una ruta de acceso no válida.Determina si la variable de flujo
target.urlrealmente tiene una ruta no válida y la fuente de su valor con uno de los siguientes métodos:Seguimiento
Cómo usar la herramienta de Trace
Si capturaste un registro para este error, sigue los pasos que se explican en Cómo usar la herramienta Trace y
- Verifica si
target.urltiene una ruta de acceso no válida, es decir, si comienza con un signo de interrogación (?) en lugar de una barra diagonal (/). Si es así, busca la política que modificó o actualizó el valor de
target.urlpara que contenga una ruta de acceso no válida.Muestra de registro que muestra que la política de JavaScript actualizó la variable de flujo
target.url
- En el registro de muestra anterior, observa que la política de JavaScript modificó o actualizó el valor de
target.urlpara que contenga una ruta de acceso no válida. - Ten en cuenta que
target.urltiene los siguientes componentes:- scheme:
https - authority:
mocktarget.apigee.net - ruta:
?json
La ruta de acceso comienza con un signo de interrogación (
?) en lugar de una barra diagonal (/), por lo que no es válida. - scheme:
Registros
Usa registros en tu servidor de registros
- Si no tienes un registro de este error (un problema intermitente), verifica si registraste la información sobre el valor de la variable de flujo
target.urlcon políticas como MessageLogging o ServiceCallout en tu servidor de registro. - Si tienes los registros, revísalos y
- Verifica si
target.urltiene una ruta de acceso no válida. - Determina si puedes obtener información sobre qué política modificó
target.urlpara que contenga una ruta de acceso no válida.
- Verifica si
proxy de API
Revisa el proxy de API que falló
Si no tienes un registro o un seguimiento de este error, revisa el proxy de API con errores para determinar qué modificó o actualizó la variable de flujo
target.urlpara que contenga una ruta no válida. Verifica lo siguiente:- La política dentro del proxy de API
- Cualquier flujo compartido invocado desde el proxy
- Verifica si
Examina detenidamente la política específica (por ejemplo, AssignMessage o JavaScript) que modifica o actualiza la variable de flujo
target.urly determina la causa de la actualización detarget.urlpara que tenga una ruta no válida.A continuación, se incluyen algunos ejemplos de políticas que actualizan la variable de flujo
target.urlde forma incorrecta para que contenga una ruta no válida que genera este error.Ejemplo 1
Muestra 1: Actualización de la variable
target.urlde la política de JavaScriptvar url = "https://mocktarget.apigee.net?json" context.setVariable("target.url", url);
En la muestra anterior, ten en cuenta que la variable de flujo
target.urlse actualiza con el valorhttps://mocktarget.apigee.net?jsonque contiene otra variableurl..Ten en cuenta que el valor de
urltiene los siguientes componentes:- scheme:
https - authority:
mocktarget.apigee.net - ruta:
?json
La ruta de acceso comienza con un signo de interrogación (
?) en lugar de una barra diagonal (/), lo que no es válido. Por lo tanto, Apigee Edge devuelve500 Internal Server Errorcon el código de errorprotocol.http.BadPath.Muestra 2
Ejemplo 2: Política de JavaScript que actualiza la variable
target.urlsegún el valor del encabezado de la solicitudvar path = context.getVariable("request.header.Path"); var url = "https://mocktarget.apigee.net" + path context.setVariable("target.url", url);
En la muestra anterior, observa que la variable de flujo
target.urlse actualiza concatenando el valorhttps://mocktarget.apigee.netcontenido en una variableurly el valor de otra variablepath, cuyo valor se recupera derequest.header.Path..Si tienes acceso a la solicitud o al registro reales, puedes verificar el valor real que se pasó a
request.header.Path.Solicitud de muestra realizada por el usuario
curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
En este ejemplo, la ruta de acceso del encabezado no se envía como parte de la solicitud. Por lo tanto, el valor de la variable
pathen la política de JavaScript esnull.Entonces:
url = https://mocktarget.apigee.net + pathurl = https://mocktarget.apigee.net + "?user"target.url = https://mocktarget.apigee.net?user
Ten en cuenta que el valor de
target.urltiene los siguientes componentes:- scheme:
https - authority:
mocktarget.apigee.net - ruta:
?user
La ruta de acceso comienza con un signo de interrogación (
?) en lugar de una barra diagonal (/), lo que no es válido. Por lo tanto, Apigee Edge devuelve500 Internal Server Errorcon el código de errorprotocol.http.BadPath.Muestra 3
Ejemplo 3: Actualización de la variable
target.urlde la política AssignMessage<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>
Ten en cuenta que el valor de
urltiene los siguientes componentes:- scheme:
https - authority:
mocktarget.apigee.net - ruta:
?echo
En este ejemplo, la ruta de acceso comienza con un signo de interrogación (
?) en lugar de una barra diagonal (/), lo que no es válido. Por lo tanto, Apigee Edge devuelve500 Internal Server Errorcon el código de errorprotocol.http.BadPath.- scheme:
Solución
Según la especificación de URL
RFC 3986, sección 3: Componentes de sintaxis, el componente path es obligatorio y SIEMPRE debe comenzar con "/". Por lo tanto, sigue los pasos que se indican a continuación para solucionar este problema:
- Asegúrate de que la URL del servidor de backend, representada por la variable de flujo
target.url, siempre tenga una ruta de acceso válida y siempre comience con una barra diagonal (/).- En algunos casos, es posible que no tengas un nombre de recurso en la ruta. En ese caso, asegúrate de que la ruta tenga, al menos, una barra diagonal (
/). - Si usas otras variables para determinar el valor de la variable de flujo
target.url, asegúrate de que esas otras variables no tengan una ruta de acceso no válida. - Si realizas alguna operación de cadena para determinar el valor de la variable de flujo
target.url, asegúrate de que el resultado o el desenlace de las operaciones de cadena no tengan una ruta no válida.
- En algunos casos, es posible que no tengas un nombre de recurso en la ruta. En ese caso, asegúrate de que la ruta tenga, al menos, una barra diagonal (
En las muestras analizadas anteriormente, puedes solucionar este problema de la siguiente manera:
Ejemplo 1
Muestra 1: Actualización de la variable
target.urlde la política de JavaScriptUsa una barra diagonal (
/) en lugar de un signo de interrogación (?) en la variableurlpara solucionar este problema, como se muestra a continuación:var url = "https://mocktarget.apigee.net/json" context.setVariable("target.url", url);
Muestra 2
Ejemplo 2: Política de JavaScript que actualiza la variable
target.urlsegún el valor del encabezado de la solicitudvar path = context.getVariable("request.header.Path"); var url = "https://mocktarget.apigee.net" + path context.setVariable("target.url", url);
Asegúrate de pasar una ruta de acceso válida, por ejemplo,
/usercomo parte del encabezado de solicitudPathpara solucionar este problema, como se muestra a continuación:Solicitud de ejemplo:
curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
Muestra 3
Ejemplo 3: Política AssignMessage que actualiza la variable
target.urlAgrega una ruta de acceso válida en el elemento
<Value>de la política AssignMessage. Es decir, reemplaza el signo de interrogación (?) por una barra diagonal (/) en el elemento<Value>y configúralo comohttps://mocktarget.apigee.net/echopara solucionar este problema, como se muestra a continuación:<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>
Especificación
Apigee Edge espera que el
pathcomponente en la URL del servidor de backend SIEMPRE debe comenzar con una barra (/) según las siguientes especificaciones:Especificación RFC 3986, sección 3: Componentes de sintaxis RFC 3986, sección 3.3: Ruta de acceso Si aún necesitas ayuda del equipo de asistencia de Apigee, consulta Recopila información de diagnóstico.
Se debe recopilar información de diagnóstico
Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee Edge:
Si eres usuario de la nube pública, proporciona la siguiente información:
- Nombre de la organización
- Nombre del entorno
- Nombre del proxy de API
- Comando
curlcompleto que se usa para reproducir el500 Internal Server Errorcon el código de errorprotocol.http.BadPath - Archivo de registro de las solicitudes a la API
Si eres usuario de la nube privada, proporciona la siguiente información:
- Mensaje de error completo observado para las solicitudes con errores
- Nombre del entorno
- Paquete de proxy de API
- Archivo de registro de las solicitudes a la API
Registros de acceso de NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_logDónde: ORG, ENV y PORT# se reemplazan por valores reales.
- Registros del sistema de Message Processor
/opt/apigee/var/log/edge-message- processor/logs/system.log
Referencias