500 Error interno del servidor: transmisión habilitada

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente recibe un código de estado de respuesta HTTP 500 con el mensaje Error interno del servidor para las llamadas a la API.

Mensajes de error

Las aplicaciones cliente pueden recibir una respuesta de error como la que se muestra a continuación:

HTTP/1.1 500 Internal Server Error

Esto puede ir seguido de un mensaje de error como el siguiente:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Causas posibles

El error interno del servidor 500 puede ocurrir debido a varias causas diferentes. Este manual se centra en el error interno del servidor 500 causado por el acceso a la carga útil de solicitud o respuesta cuando la transmisión está habilitada.

Causa: Acceso a la carga útil con la transmisión habilitada

Diagnóstico

Procedimiento nº 1: Usa Trace

1. Habilita la sesión de seguimiento y realiza la llamada a la API para reproducir el problema: error interno del servidor 500.
2. Selecciona una de las solicitudes con errores y examina el seguimiento.
3. Navega por las distintas fases del seguimiento y ubica dónde se produjo el error.
4. Es posible que este error se haya producido mientras una política analizaba la carga útil de solicitud o respuesta.
5. A continuación, se muestra una captura de pantalla de seguimiento de muestra en la que se muestra la política JSONThreatProtection que falla con el error "Expecting } at line 1":

   

   Toma nota de la siguiente información del resultado del seguimiento, como se muestra en la captura de pantalla anterior:
   

   Política con errores: JSONThreatProtection

   Flujo: Solicitud de proxy

6. Examina la definición de la política con errores y verifica la carga útil que se está analizando.

   En la situación de ejemplo, examina la política JSONThreatProtection llamada JSON-Threat-Protection que falló y verifica el <Source> elemento.

   <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
      <DisplayName>JSON Threat Protection</DisplayName>
      <ArrayElementCount>20</ArrayElementCount>
      <ContainerDepth>10</ContainerDepth>
      <ObjectEntryCount>15</ObjectEntryCount>
      <ObjectEntryNameLength>50</ObjectEntryNameLength>
      <Source>request</Source>
      <StringValueLength>1000</StringValueLength>
   </JSONThreatProtection>

   Ten en cuenta que el elemento <Source> apunta a request.Esto significa que el error se produjo mientras se analizaba la carga útil de la solicitud.

7. Para determinar el tipo de carga útil que se está analizando, verifica la solicitud a la API.

Puedes verificar el contenido de la carga útil de la solicitud y el encabezado Content-Type en la solicitud a la API. En el siguiente ejemplo de comando curl, se usa una carga útil de JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

También puedes verificar la política que falla y determinar el tipo de carga útil que se está analizando. En la situación de ejemplo anterior, falla la política JSON-Threat-Protection. Esto indica que la carga útil debe estar en formato JSON.

8. Valida si la carga útil tiene el formato adecuado. Si la carga útil no es válida, puedes obtener este error.

9. Si la carga útil es válida, pero sigues recibiendo los errores que se indican en la sección Mensajes de error, la causa de estos errores es que se accede a la carga útil cuando la transmisión está habilitada.

   Según la carga útil que analiza la política (como se determinó en el paso 6), examina el contenido de la carga útil en la herramienta Trace en la fase adecuada.

   En la situación de ejemplo, se analiza la carga útil de la solicitud, por lo que debes examinar la "Request Received from Client" fase en el seguimiento y verificar el contenido de la solicitud.

   

   Si el contenido de la solicitud está vacío, como se muestra en la captura de pantalla anterior, aunque hayas enviado una carga útil válida, eso indica que la causa probable de este problema es que la transmisión de solicitudes está habilitada.

   Esto se debe a que, cuando la transmisión está habilitada, la carga útil de la solicitud no aparecerá en el seguimiento.

   Del mismo modo, si se analiza la carga útil de la respuesta cuando se produce el error, verifica el contenido de la respuesta en la fase "Response received from target server".

10. A continuación, examina las definiciones de proxy y extremo de destino según dónde se use la política con errores en el flujo del proxy de API. Verifica si se habilitó la transmisión.

    En la situación de ejemplo, la política con errores se ejecutó en el flujo de solicitudes de proxy (como se determinó en el paso 5 anterior); por lo tanto, examina el extremo de proxy:

    <ProxyEndpoint name="default">
    ...
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <VirtualHost>secure</VirtualHost>
        <Properties>
          <Property name="response.streaming.enabled">true</Property>
          <Property name="request.streaming.enabled">true</Property>
        </Properties>
      </HTTPProxyConnection>
    </ProxyEndpoint>

    Como se ve en el ejemplo anterior, se habilitó la transmisión de solicitudes, como lo indica la propiedad "request.streaming.enabled" establecida en true.

    Por lo tanto, la causa del error es usar la política JSONThreatProtection en el proxy de API que accede a la carga útil de la solicitud cuando la transmisión está habilitada. Esto causa errores porque activa el almacenamiento en búfer en el proxy de API y anula el propósito de usar la transmisión en Apigee Edge.

    Es posible que este error no se vea con cargas útiles más pequeñas, pero, cuando usas cargas útiles más grandes, puedes ver estos errores.

11. Para verificar que el error 500 se debe a la política, verifica el valor de "X-Apigee-fault-source" en la fase "AX" (Analytics Data Recorded) en el seguimiento con los pasos que se indican a continuación:
    1. Haz clic en la fase "AX" (Analytics Data Recorded) como se muestra en la siguiente captura de pantalla:

       

    2. Desplázate hacia abajo por los detalles de la fase hasta la sección "Error Headers" y determina los valores de "X-Apigee-fault-code", "X-Apigee-fault-source" y "X-Apigee-fault-policy" como se muestra a continuación:

       

    3. Si el valor de "X-Apigee-fault-source" es "policy" como se muestra en la imagen anterior, indica que el error se debe a que la política accede a la carga útil cuando la transmisión está habilitada.

Solución

El acceso a la carga útil con la transmisión habilitada es un antipatrón, como se explica en Antipatrón: Accede a la carga útil de la solicitud o respuesta cuando la transmisión está habilitada.

1. Si deseas procesar la carga útil, debes inhabilitar la transmisión en el proxy o el extremo de destino quitando las propiedades "request.streaming.enabled" and "response.streaming.enabled" como se muestra en el siguiente ejemplo de ProxyEndpoint:

   <ProxyEndpoint name="default">
   ...
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <VirtualHost>secure</VirtualHost>
     </HTTPProxyConnection>
   </ProxyEndpoint>

   O

2. Si deseas usar la transmisión para tus proxies de API, no uses ninguna política en el proxy de API que acceda a la carga útil de solicitud o respuesta.

Nota:

• En este manual, se usó la política JSONThreatProtection para procesar la carga útil de la solicitud con la transmisión habilitada en la situación de ejemplo. Esto generó un error interno del servidor 500 con diferentes errores.
• Estos errores también se pueden ver con políticas como JSONToXML y XMLToJSON, que procesan cargas útiles de solicitud o respuesta cuando la transmisión está habilitada.
• Te recomendamos que no uses ninguna de estas políticas en proxies que requieran acceso a cargas útiles cuando la transmisión esté habilitada.
• Hacerlo es un antipatrón, como se documenta en Antipatrón: Accede a la carga útil de la solicitud o respuesta cuando la transmisión está habilitada.

Diagnostica problemas con la supervisión de API

Si eres usuario de la nube privada, omite este procedimiento.

La supervisión de API te permite aislar las áreas con problemas rápidamente para diagnosticar problemas de errores, rendimiento y latencia, y su fuente, como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Sigue una situación de ejemplo que muestra cómo solucionar problemas de 5xx con tus APIs mediante la supervisión de API. Por ejemplo, es posible que desees configurar una alerta para recibir una notificación cuando la cantidad de errores 500 supere un umbral determinado.

Si deseas recibir una notificación cuando se arroja una respuesta de error 500 desde la política, debes configurar la alerta para el código de estado 500 con la fuente de fallas como Proxy.

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. Comunícate con Asistencia de Apigee y compártela.

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 curl completo junto con la carga útil de la solicitud (si corresponde) para reproducir el error 500
• Archivo de seguimiento que contiene las solicitudes con el error interno del servidor 500
• Si los errores 500 no ocurren actualmente, proporciona el período con la información de la zona horaria cuando ocurrieron errores 500 en el pasado.

Si eres usuario de la nube privada, proporciona la siguiente información:

• Mensaje de error completo observado para las solicitudes con errores
• Organización, nombre del entorno y nombre del proxy de API para los que observas errores 500
• Paquete de proxy de API
• Carga útil que se usa en la solicitud (si corresponde)
• Archivo de seguimiento que contiene las solicitudes con el error interno del servidor 500
• Registros de acceso a NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
• Registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)
• El período con la información de la zona horaria cuando ocurrieron los errores 500.