Se usó la API de Cloud Translation para traducir esta página.

500 Error interno del servidor: transmisión habilitada

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

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 se muestra a continuación:

HTTP/1.1 500 Internal Server Error

Es posible que después aparezca un mensaje de error similar al 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 deberse a varias causas diferentes. Esta guía se centra en el error interno del servidor 500 causado por el acceso a la carga útil de solicitud/respuesta cuando la transmisión está habilitada.

Causa	Descripción	Quién puede realizar los pasos para solucionar problemas
Cómo acceder a la carga útil con la transmisión habilitada	Se produjo un error porque se accede a la carga útil de la solicitud o respuesta cuando la transmisión está habilitada.	Usuarios de la nube pública y privada perimetral

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

Diagnóstico

Procedimiento n.o 1: Usa Trace

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

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

Política de fallas: JSONThreatProtection

Flujo: Solicitud de proxy

Examina la definición de la política que falla 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 elemento <Source>.

<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., lo que significa que se produjo un error durante el análisis de la carga útil de la solicitud.

Determina el tipo de carga útil que se analiza revisando la solicitud a la API.

Puedes verificar el contenido de la carga útil de la solicitud y del encabezado Content-Type en la solicitud a la API. En el siguiente comando curl de ejemplo, 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 analiza. En la situación de ejemplo anterior, la política JSON-Threat-Protection falla. Esto indica que la carga útil debe estar en formato JSON.

Valida que la carga útil esté en el formato adecuado. Si la carga útil no es válida, puedes obtener este error.

Nota: Si la carga útil es grande, puedes usar cualquier formateador en línea para validar el formato de la carga útil.
Si la carga útil es válida, pero aún recibes errores como se indica 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 analice la política (como se determina en el paso 6), examina el contenido de la carga útil en la herramienta de seguimiento en la fase adecuada.

En la situación de ejemplo, se está analizando la carga útil de la solicitud, por lo que debes examinar la fase "Solicitud recibida del cliente" en el seguimiento y verificar el Contenido de la solicitud.

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

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

Del mismo modo, si se está analizando la carga útil de la respuesta cuando se produce el error, verifica el contenido de la respuesta en la fase "Respuesta recibida del servidor de destino".
A continuación, examina las definiciones de extremo de proxy y 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 solicitud del proxy (como se determinó en el paso 5 anterior); por lo tanto, examina el extremo del 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, la transmisión de solicitudes se habilitó según lo indica la propiedad "request.streaming.enabled" establecida como verdadera.

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 produzca con cargas útiles más pequeñas, pero cuando usas cargas útiles más grandes, puedes ver estos errores.
Para verificar que el error 500 se deba a la política, revisa el valor de "X-Apigee-fault-source" en la fase "X-Apigee-fault-source" del seguimiento siguiendo los pasos que se indican a continuación:
1. Haz clic en la fase "AX" (datos de Analytics registrados) como se muestra en la siguiente captura de pantalla:
2. Desplázate hacia abajo en la sección Detalles de la fase hasta la sección “Encabezados de error” 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 "X-Apigee-fault-source" como se muestra en la imagen anterior, significa que el error se debe a la política que accede a la carga útil cuando la transmisión está habilitada.

Resolución

Acceder 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 solicitud/respuesta cuando la transmisión está habilitada.

Si deseas procesar la carga útil, debes inhabilitar la transmisión en el extremo proxy/de destino. Para ello, quita las propiedades "request.streaming.enabled" and "response.streaming.enabled", como se muestra en el ejemplo de ProxyEndpoint a continuación:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
O
Si deseas usar la transmisión para tus proxies de API, no utilices ninguna política en el proxy de API que acceda a la carga útil de solicitud o respuesta.

Nota:

En esta guía, 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 llevó a 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.
Recomendamos no usar 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 solicitud/respuesta cuando la transmisión está habilitada.

Diagnostica problemas con la supervisión de API

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

La supervisión de las APIs te permite aislar las áreas problemáticas con rapidez para diagnosticar problemas de errores, rendimiento y latencia y su fuente, como las apps para desarrolladores, los proxies de API, los objetivos de backend o la plataforma de la API.

Analiza una situación de ejemplo en la que se demuestra cómo solucionar problemas 5xx de tus APIs con la supervisión de APIs. Por ejemplo, es posible que desees configurar una alerta para que se te notifique cuando la cantidad de errores 500 supere un umbral en particular.

Si deseas recibir una notificación cuando se genere una respuesta de error 500 de la política, debes configurar la alerta para el código de estado 500 con la fuente de errores 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 ellos y compártelos en el equipo de asistencia de Apigee.

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

Nombre de la organización
Nombre del entorno
Nombre de proxy de API
Completa el comando curl junto con la carga útil de la solicitud (si la hubiera) para reproducir el error 500
Archivo de seguimiento que contiene las solicitudes con el error 500 Internal Server Error
Si los errores 500 no se producen actualmente, proporciona el período con la información de la zona horaria en la que se produjeron errores 500 en el pasado.

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

Mensaje de error completo observado para las solicitudes con errores
Organización, nombre del entorno y nombre de proxy de API para el que observas errores 500
Paquete de proxy de API
Carga útil usada en la solicitud (si corresponde)
Archivo de seguimiento que contiene las solicitudes con el error 500 Internal Server Error
Registros de acceso de NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Registros del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Indica el período con la información de la zona horaria en el que se produjeron los errores del tipo 500.