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

500 Error interno del servidor: transmisión habilitada

Estás viendo la documentación de Apigee Edge.
Ve a 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 Internal Server Error 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 esté seguido de 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 producirse por diferentes causas. Esta guía se centra en el error 500 interno del servidor causado por el acceso a la solicitud/respuesta de carga útil cuando se transmite esté habilitada.

Causa	Descripción	Quién puede realizar los pasos para solucionar problemas
Acceder a la carga útil con Transmisión habilitada	Se produjo un error porque se accede a la carga útil de la solicitud/respuesta cuando la transmisión está habilitada.	Usuarios perimetrales de nubes privadas y públicas

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

Diagnóstico

Procedimiento n.o 1: Usa Trace

Habilita el seguimiento sesión y realiza la llamada a la API para reproducir el problema (Error interno del servidor 500).
Selecciona una de las solicitudes fallidas y examina el seguimiento.
Navega por las diferentes fases del seguimiento y localiza dónde ocurrió la falla.
Este error puede haberse producido mientras una política analizaba la carga útil de la solicitud o respuesta.
A continuación, verás una captura de pantalla de seguimiento de ejemplo en la que se muestra JSONThreatProtection falla la política con el error "Expecting } at line 1":

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

Política de fallas: JSONThreatProtection

Flujo: Solicitud de proxy

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

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

Determinar el tipo de carga útil que se está analizando verificando 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 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

Puedes verificar la política que falla y determinar el tipo de carga útil analizar. En la situación del ejemplo anterior, la política JSON-Threat-Protection falla. Esto indica que la carga útil debe estar en formato JSON.

Verifica si la carga útil tiene el formato adecuado. Si la carga útil no es válida, es posible que recibas este error.

Nota: Si la carga útil es grande, puedes usar cualquier formateador en línea para validar la de la carga útil.
Si la carga útil es válida, pero sigues recibiendo errores como se indica en el Mensajes de error y, luego, la causa de estos errores. es que se accede a la carga útil cuando se habilita la transmisión.

Según la carga útil que analice la política (como se determina en el paso 6), examinar el contenido de la carga útil en la herramienta Trace en la fase adecuada.

En la situación de ejemplo, la carga útil de la solicitud se está analizando, así que examine la "Solicitud recibida del cliente" en el seguimiento y verifica Solicitar Contenido.

Si el contenido de la solicitud está vacío como se muestra en la captura de pantalla anterior, aunque ya que enviaste una carga útil válida, eso indica que la causa probable de este problema es 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.

De manera similar, si la carga útil de la respuesta se está analizando cuando se produce el error, comprueba el contenido de la respuesta en la fase "Respuesta recibida del servidor de destino".
Luego, examine las definiciones del proxy y del extremo de destino según dónde se encuentre se usa 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, examine 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 el la propiedad "request.streaming.enabled" se estableció en true.

Por lo tanto, la causa del error es usar la política JSONThreatProtection en el proxy de API. que acceda a la carga útil de la solicitud cuando la transmisión esté habilitada. Esto genera errores porque Se activa el almacenamiento en búfer en el proxy de API y se anula el objetivo de usar transmisiones en Apigee Edge.

Es posible que este error no se vea en cargas útiles más pequeñas, pero cuando usas cargas útiles más grandes, puedan ver estos errores.
Para comprobar que el error 500 se debe a la política, revisa el valor de "X-Apigee-fault-source" en el curso "AX" (Datos registrados de Analytics) Fase del seguimiento según 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 por los detalles de la fase hasta "Encabezados de error". y determinan 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 como se muestra en la imagen anterior, indica que el error se debe a que la política cuando se habilita la transmisión.

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

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

Nota:

En esta guía, se utilizó la política JSONThreatProtection para procesar la carga útil de la solicitud con de transmisión habilitada en el caso de ejemplo. Esto generó un error interno del servidor 500 con errores diferentes.
Estos errores también se pueden ver con políticas como JSONToXML y XMLToJSON, que procesan solicitudes o respuestas 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 un usuario de la nube privada, omite este procedimiento.

La supervisión de API te permite aislar rápidamente las áreas problemáticas para diagnosticar problemas de error, rendimiento y latencia, y sus orígenes, como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

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

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

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
Completa el comando curl junto con la carga útil de la solicitud (si corresponde) para reproducir el error 500
Archivo de registro que contiene las solicitudes con el error 500 Internal Server Error
Si los errores 500 no están ocurriendo en este momento, proporciona el período con la información de la zona horaria en la que se produjeron los 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 fallidas
Organización, nombre del entorno y nombre del proxy de la API en los que observas errores 500
Paquete de proxy de API
Carga útil usada en la solicitud (si corresponde)
Archivo de registro 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)
El período con la información de la zona horaria en el que se produjeron los errores 500.