Error interno del servidor: 500 - EmptyPath

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X.
Información

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 500 Internal Server Error con el código de error protocol.http.EmptyPath 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 veas el siguiente mensaje de error:

{
   "fault":{
      "faultstring":"Request path cannot be empty",
      "detail":{
         "errorcode":"protocol.http.EmptyPath"
      }
   }
}

Causas posibles

Este error se produce si la URL de solicitud del servidor de backend, representada por la variable de flujo target.url, contiene una ruta de acceso vacía.

Según las especificaciones de RFC 3986, sección 3: Componentes de la sintaxis y RFC 3986, sección 3.3: Ruta de acceso:

  1. La sintaxis del URI tiene los siguientes componentes:

            foo://example.com:8042/over/there?name=ferret#nose
            \_/   \______________/\_________/ \_________/ \__/
             |            |            |            |       |
          scheme      authority       path        query   fragment
    
  2. El componente path es obligatorio y DEBE tener siempre una barra diagonal (/), incluso si no hay otros caracteres como parte de la ruta de acceso.

Por lo tanto, si la URL de la solicitud del servidor de backend no tiene el componente path, es decir, ni siquiera tiene una barra diagonal (/), Apigee Edge responde con 500 Internal Server Error y el código de error protocol.http.EmptyPath.

Por ejemplo, si target.url tiene el valor https://www.mocktarget.apigee.net, este error se produce porque el componente path está vacío o falta.

Causa Descripción Instrucciones de solución de problemas aplicables para
La URL del servidor de backend (target.url) tiene una ruta vacía La URL del servidor de backend representada por la variable de flujo target.url tiene una ruta de acceso vacía. 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 n.o 1: Usar la supervisión de APIs

Para diagnosticar el error con la supervisión de la API, sigue estos pasos:

  1. Accede a la IU de Apigee Edge como un usuario con un rol adecuado.
  2. Cambia a la organización en la que quieres investigar el problema.

  3. Navega a la página Analyze > API Monitoring > Investigate.
  4. Selecciona el período específico en el que observaste los errores.
  5. Traza el código de falla en función del valor Time.

  6. Selecciona una celda que tenga el código de falla protocol.http.EmptyPath, como se muestra a continuación:

  7. Se muestra información sobre el código de falla protocol.http.EmptyPath como se muestra a continuación:

  8. Haz clic en Ver registros para expandir la fila de la solicitud con errores.

  9. En la ventana Registros, ten en cuenta los siguientes detalles:
    • Código de estado: 500
    • Fuente de la falla: target
    • Código de falla: protocol.http.EmptyPath
  10. Si la Fuente de errores es target y el Código de falla es protocol.http.EmptyPath, eso indica que la URL del servidor de backend tiene una ruta vacía.

Trace

Procedimiento n.o 2: Usa la herramienta de seguimiento

Para diagnosticar el error con la herramienta Trace, sigue estos pasos:

  1. Habilita la sesión de seguimiento y realiza una de estas acciones:
    • Espera a que ocurra el error 500 Internal Server Error.
    • Si puedes reproducir el problema, realiza la llamada a la API para reproducirlo 500 Internal Server Error
  2. Asegúrate de que la opción Show all FlowInfos esté habilitada:

  3. Selecciona una de las solicitudes con errores y examina el seguimiento.
  4. Navega por las diferentes fases del seguimiento y localiza dónde ocurrió la falla.
  5. Por lo general, encontrarás el error en un flujo después de la fase Se inició el flujo de solicitud de destino, como se muestra a continuación:

  6. Observa el valor del error del seguimiento.

    error: La ruta de la solicitud no puede estar vacía

    Dado que Apigee Edge genera el error después de la fase Target Request Flow started, indica que el path en la URL del servidor de backend está vacío. Lo más probable es que esto suceda si la variable de flujo target.url (que representa la URL del servidor de backend) se actualizó con una ruta de acceso vacía a través de una de las políticas en el flujo de la solicitud.

  7. Examina la sección Variables leídas y asignadas en cada uno de los flujos hacia atrás desde el punto de error hacia la fase Flujo de solicitud de destino iniciado.
  8. Determina la política en la que se actualiza la variable de flujo target.url .

    Seguimiento de muestra que muestra la política de JavaScript y actualiza la variable de flujo target.url:

    En el seguimiento de muestra anterior, ten en cuenta que el valor de la variable de flujo target.url se actualiza en una política de JavaScript llamada SetTargetURL de la siguiente manera:

    target.url : https://mocktarget.apigee.net
    
  9. Ten en cuenta que target.url tiene los siguientes componentes:
    • esquema: https://mocktarget.apigee.net
    • path: vacío
  10. Por lo tanto, verás el error Request path cannot be empty.
  11. Navega a la fase AX (datos de Analytics registrados) en el seguimiento y haz clic en ella.
  12. Desplázate hacia abajo hasta la sección Detalles de la fase: Encabezados de error y determina los valores de X-Apigee-fault-code y X-Apigee-fault-source como se muestra a continuación:

  13. Verás los valores de X-Apigee-fault-code y X-Apigee-fault-source como protocol.http.EmptyPath y target respectivamente, lo que indica que este error se produce porque la URL del servidor de backend tiene una ruta vacía.
    Encabezados de respuesta Valor
    X-Apigee-fault-code protocol.http.EmptyPath
    X-Apigee-fault-source target

NGINX

Procedimiento n.o 3: Cómo usar los registros de acceso de NGINX

Para diagnosticar el error con los registros de acceso de NGINX, sigue estos pasos:

  1. Si eres un usuario de la nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave de 500 Internal Server Error de HTTP.
  2. Verifica los registros de acceso de NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Busca para ver si hay errores 500 con el código de error protocol.http.EmptyPath durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con 500.
  4. Si encuentras algún error 500 en el que X-Apigee-fault-code coincida con el valor deX-Apigee-fault-code , determina el valor de X-Apigee-fault-code

    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.EmptyPath
    X-Apigee-fault-source target

    Ten en cuenta que los valores de X-Apigee-fault-code y X-Apigee-fault-source son protocol.http.EmptyPath y target respectivamente, lo que indica que este error se produce porque la URL del servidor de backend tiene una ruta de acceso vacía.

Causa: La URL del servidor de backend (target.url) tiene una ruta de acceso vacía.

Diagnóstico

  1. Determina el código de error y la fuente de errores para 500 Internal Server Error mediante la supervisión de la API, la herramienta de seguimiento o los registros de acceso de NGINX, como se explica en Pasos comunes de diagnóstico.
  2. Si Fault Code es protocol.http.EmptyPath y Fault Source tiene el valor target, esto indica que la URL del servidor de backend tiene una ruta de acceso vacía.
  3. La URL del servidor de backend se representa con la variable de flujo target.url en Apigee Edge. Por lo general, este error ocurre si intentas actualizar la URL del servidor de backend, es decir, target.url de forma dinámica con cualquiera de las políticas (dentro del proxy/flujo compartido) en el flujo de solicitudes de destino, de modo que tenga una ruta de acceso vacía.

  4. Determina si la variable de flujo target.url tiene una ruta de acceso vacía y el origen de su valor mediante uno de los siguientes pasos:

    Trace

    Cómo usar la herramienta Trace

    Si capturaste un seguimiento para este error, sigue los pasos que se explican en Cómo usar la herramienta de seguimiento y haz lo siguiente:

    1. Verifica si target.url tiene una ruta de acceso vacía.
    2. Si es así, descubre qué política modificó o actualizó el valor de target.url para que contenga una ruta de acceso vacía.

      Seguimiento de ejemplo que muestra que la política de JavaScript actualizó la variable de flujo target.url:

    3. En el seguimiento de muestra anterior, observa que la política de JavaScript modificó o actualizó el valor de target.url para que contenga una ruta vacía.
    4. Ten en cuenta que target.url tiene los siguientes componentes:
      • esquema: https://mocktarget.apigee.net
      • path: vacío

    Registros

    Usa registros en tu servidor de registros

    1. Si no tienes un seguimiento para este error (un problema intermitente), verifica si registraste la información sobre el valor de la variable de flujo target.url mediante políticas como MessageLogging o ServiceHighlight en tu servidor de registros.
    2. Si tienes los registros, revísalos y haz lo siguiente:
      1. Verifica si target.url tiene una ruta vacía.
      2. Intenta determinar qué política modificó target.url para que contenga una ruta vacía.

    proxy de API

    Revisa el proxy de API con errores

    Si no tienes un seguimiento o registros para este error, revisa el proxy de API con errores a fin de determinar qué modificó o actualizó la variable de flujo target.url para que contenga una ruta de acceso no válida. Verifica lo siguiente:

    • La política dentro del proxy de API
    • Cualquier flujo compartido invocado desde el proxy
  5. Examina la política específica (por ejemplo, AssignMessage o JavaScript) que modifica o actualiza la variable de flujo target.url con atención y determina la causa de la actualización de target.url para que tenga una ruta vacía.

    Estas son algunas políticas de ejemplo que actualizan la variable de flujo target.url de forma incorrecta para contener una ruta vacía que genera este error.

    Ejemplo 1

    Ejemplo 1: Actualización de la variable target.url de la política de JavaScript

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

    En el ejemplo anterior, observa que la variable de flujo target.url se actualiza con el valor https://mocktarget.apigee.net contenido en otra variable url.

    Ten en cuenta que target.url tiene los siguientes componentes:

    • esquema: https://mocktarget.apigee.net
    • path: vacío

    Dado que la ruta de acceso está vacía, Apigee Edge muestra 500 Internal Server Error con el código de error protocol.http.EmptyPath.

    Muestra n.o 2

    Ejemplo 2: Actualización de la variable target.url de la política de JavaScript

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

    En el ejemplo anterior, observa que la variable de flujo target.url se actualiza mediante la concatenación del valor https://mocktarget.apigee.net contenido en una variable url y el valor de otra variable path, cuyo valor se recupera de request.header.Path..

    Si tienes acceso a la solicitud o al seguimiento real, puedes verificar el valor real que se pasa a request.header.Path.

    Ejemplo de solicitud del usuario:

    curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token>
    

    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 ruta de acceso de la variable en la política de JavaScript es null.

    Entonces:

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

    Ten en cuenta que target.url tiene los siguientes componentes:

    • esquema: https://mocktarget.apigee.netnull
    • path: vacío

    Ejemplo 3

    Ejemplo 3: Política de AttributionMessage actualizando la variable target.url a través de otra variable

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

    Ten en cuenta que target.url tiene los siguientes componentes:

    • esquema: https://mocktarget.apigee.net
    • path: vacío

    En todos los ejemplos anteriores, la ruta de acceso en la URL del servidor de backend, que es target.url, está vacía, por lo que Apigee Edge muestra 500 Internal Server Error con el código de error protocol.http.EmptyPath.

Resolución

Según la especificación RFC 3986, sección 2: Componentes de la sintaxis, el componente path es obligatorio y siempre DEBE tener una barra diagonal (/), incluso si no hay otros caracteres como parte de path. Sigue estos pasos para solucionar el problema:

  1. Asegúrate de que la URL del servidor de backend, representada por la variable de flujo target.url, siempre tenga una ruta de acceso no vacía.
    1. En algunos casos, es posible que no tengas un nombre de recurso en la ruta de acceso. Luego, asegúrate de que la ruta tenga al menos una barra diagonal (/).
    2. Si usas otras variables para determinar el valor de la variable de flujo target.url, asegúrate de que otras variables no tengan una ruta vacía.
    3. Si realizas alguna operación de string para determinar el valor de la variable de flujo target.url, asegúrate de que el resultado de las operaciones de string no tenga una ruta vacía.
  2. En las muestras que se analizan en Diagnóstico, puedes solucionar este problema como se explica a continuación:

    Ejemplo 1

    Ejemplo 1: Actualización de la variable target.url de la política de JavaScript

    Agrega una barra diagonal (/) a la variable url para solucionar este problema como se muestra a continuación:

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

    Muestra n.o 2

    Ejemplo 2: Actualización de la variable target.url de la política de JavaScript

    var 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, /iloveapis, como parte del encabezado de la solicitud Path para solucionar este problema, como se muestra a continuación:

    Ejemplo de solicitud:

    curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /iloveapis"
    

    Ejemplo 3

    Ejemplo 3: Política de AttributionMessage actualizando la variable target.url a través de otra variable

    Agrega una ruta de acceso válida en el elemento <Value> de la políticaAssignMessage. Por ejemplo, puedes tener /json como la ruta de acceso para la API de MockTarget. Es decir, modifica el elemento <Value> por https://mocktarget.apigee.net/json 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/json</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>
    

Especificación

Apigee Edge espera que la URL del servidor de backend no tenga una ruta vacía de acuerdo con las siguientes especificaciones:

Especificación
RFC 3986, sección 3: Componentes de la sintaxis
RFC 3986, sección 3.3: Ruta de acceso

Si aún necesitas asistencia de la asistencia de Apigee, consulta Debes recopilar 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 el equipo de asistencia de Apigee Edge.

Si eres un usuario de la nube pública, proporciona la siguiente información:

  • Nombre de la organización
  • Nombre del entorno
  • Nombre del proxy de API
  • Completa el comando curl que se usa para reproducir 500 Internal Server Error con el código de error protocol.http.EmptyPath.
  • Archivo de seguimiento para las solicitudes a la API

Si eres un 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 seguimiento para las solicitudes a la API
  • Registros de acceso de NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Dónde: Se reemplazan ORG, ENV y PORT# por valores reales.

  • Registros del sistema del procesador de mensajes /opt/apigee/var/log/edge-message- processor/logs/system.log

Referencias

Variables de flujo: objetivo