Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

500 – Erreur interne du serveur - Streaming activé

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Problème constaté

L'application cliente reçoit un code d'état de réponse HTTP 500 avec le message Erreur interne du serveur pour les appels d'API.

Messages d'erreur

Les applications clientes peuvent recevoir une réponse d'erreur comme indiqué ci-dessous :

HTTP/1.1 500 Internal Server Error

Cela peut être suivi d'un message d'erreur semblable à celui-ci :

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

OR

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

Causes possibles

L'erreur interne du serveur 500 peut se produire pour plusieurs raisons. Ce guide se concentre sur l'erreur interne du serveur 500 causée par l'accès à la charge utile de requête/réponse lorsque le streaming est activé.

Cause	Description	Qui peut effectuer les étapes de dépannage ?
Accéder à la charge utile avec le streaming activé	Une erreur s'est produite, car la charge utile de requête/réponse est accessible lorsque le streaming est activé.	Utilisateurs du cloud privé et public Edge

Cause : Accéder à la charge utile avec le streaming activé

Diagnostic

Procédure 1 : Utiliser Trace

Activez la session trace et effectuez l'appel d'API pour reproduire le problème : erreur interne du serveur 500.
Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
Parcourez les différentes phases de la trace et identifiez l'endroit où l'échec s'est produit.
Cette erreur peut s'être produite lorsqu'une règle analyse la charge utile de requête/réponse.
Voici un exemple de capture d'écran de trace montrant l'échec de la règle JSONThreatProtection avec l'erreur "Expecting } at line 1" :

Notez les informations suivantes issues de la sortie de trace, comme indiqué dans la capture d'écran ci-dessus :

Règle ayant échoué : JSONThreatProtection

Flux : requête de proxy

Examinez la définition de la règle ayant échoué et vérifiez la charge utile en cours d'analyse.

Dans l'exemple de scénario, examinez la règle JSONThreatProtection nommée JSON-Threat-Protection qui a échoué et vérifiez l'élément <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>

Notez que l'élément <Source> pointe vers request.. Cela signifie que l'erreur s'est produite lors de l'analyse de la charge utile de la requête.

Déterminez le type de charge utile en cours d'analyse en vérifiant la requête API.

Vous pouvez vérifier le contenu de la charge utile de la requête et Content-Type en-tête dans la requête API. Dans l'exemple de commande curl suivant, une charge utile JSON est utilisée.

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

Vous pouvez également vérifier la règle qui échoue et déterminer le type de charge utile en cours d'analyse. Dans l'exemple de scénario ci-dessus, la règle JSON-Threat-Protection échoue. Cela indique que la charge utile doit être au format JSON.

Vérifiez si la charge utile est au format approprié. Si la charge utile n'est pas valide, vous pouvez obtenir cette erreur.

Remarque : Si la charge utile est volumineuse, vous pouvez utiliser n'importe quel formateur en ligne pour valider le format de la charge utile.
Si la charge utile est valide, mais que vous continuez à recevoir des erreurs comme indiqué dans la section Messages d'erreur, cela signifie que la charge utile est accessible lorsque le streaming est activé.

En fonction de la charge utile analysée par la règle (comme déterminé à l'étape 6), examinez le contenu de la charge utile dans l'outil Trace lors de la phase appropriée.

Dans l'exemple de scénario, la charge utile de la requête est en cours d'analyse. Examinez donc la "Request Received from Client" phase (Requête reçue du client) dans la trace et vérifiez le Request Content (Contenu de la requête).

Si le contenu de la requête est vide, comme indiqué dans la capture d'écran ci-dessus, même si vous avez envoyé une charge utile valide, cela indique que la cause probable de ce problème est que le streaming de requêtes est activé.

En effet, lorsque le streaming est activé, la charge utile de la requête ne s'affiche pas dans la trace.

De même, si la charge utile de la réponse est en cours d'analyse lorsque l'erreur se produit, vérifiez le contenu de la réponse dans la phase "Response received from target server" (Réponse reçue du serveur cible).
Ensuite, examinez les définitions de point de terminaison du proxy et de point de terminaison cible en fonction de l'endroit où la règle ayant échoué est utilisée dans le flux de proxy d'API. Vérifiez si le streaming a été activé.

Dans l'exemple de scénario, la règle ayant échoué a été exécutée dans le flux de requête de proxy (comme déterminé à l'étape 5 ci-dessus). Examinez donc le point de terminaison du 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>
```
Comme vous pouvez le voir dans l'exemple ci-dessus, le streaming de requêtes a été activé, comme indiqué par la propriété "request.streaming.enabled" définie sur "true".

Par conséquent, l'erreur est due à l'utilisation de la règle JSONThreatProtection dans le proxy d'API qui accède à la charge utile de la requête lorsque le streaming est activé. Cela provoque des erreurs, car cela déclenche la mise en mémoire tampon dans le proxy d'API et annule l'objectif d'utiliser le streaming dans Apigee Edge.

Cette erreur peut ne pas s'afficher avec des charges utiles plus petites, mais elle peut apparaître lorsque vous utilisez des charges utiles plus volumineuses.
Vous pouvez vérifier que l'erreur 500 est due à la règle en vérifiant la valeur de "X-Apigee-fault-source" dans la phase "AX" (Données d'analyse enregistrées) de la trace en suivant les étapes ci-dessous :
1. Cliquez sur la phase "AX" (Analytics Data Recorded) (Données d'analyse enregistrées) comme indiqué dans la capture d'écran ci-dessous :
2. Faites défiler les détails de la phase jusqu'à la section "Error Headers" et déterminez les valeurs de "X-Apigee-fault-code", "X-Apigee-fault-source" et "X-Apigee-fault-policy" comme indiqué ci-dessous :
3. Si la valeur de "X-Apigee-fault-source" est "policy" comme indiqué dans l'image ci-dessus, cela signifie que l'erreur est due à la règle qui accède à la charge utile lorsque le streaming est activé.

Solution

L'accès à la charge utile avec le streaming activé est un antimodèle, comme expliqué dans Antimodèle : Accéder à la charge utile de requête/réponse lorsque le streaming est activé.

Si vous souhaitez traiter la charge utile, vous devez désactiver le streaming dans le point de terminaison du proxy/cible en supprimant les propriétés "request.streaming.enabled" and "response.streaming.enabled"comme indiqué dans l'exemple ProxyEndpoint ci-dessous :
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
OU
Si vous souhaitez utiliser le streaming pour vos proxys d'API, n'utilisez aucune règle dans le proxy d'API qui accède à la charge utile de requête/réponse.

Remarque :

Dans ce guide, la règle JSONThreatProtection a été utilisée pour traiter la charge utile de la requête avec le streaming activé dans l'exemple de scénario. Cela a entraîné une erreur interne du serveur 500 avec différentes erreurs.
Ces erreurs peuvent également être observées avec des règles telles que JSONToXML et XMLToJSON, qui traitent les charges utiles de requête ou de réponse lorsque le streaming est activé.
Nous vous recommandons vivement de ne pas utiliser de telles règles dans les proxys qui nécessitent un accès aux charges utiles lorsque le streaming est activé.
Cela constitue un antimodèle, comme indiqué dans Antimodèle : Accéder à la charge utile de requête/réponse lorsque le streaming est activé.

Diagnostiquer les problèmes à l'aide de la surveillance des API

Si vous êtes un utilisateur du cloud privé, ignorez cette procédure.

La surveillance des API vous permet d'isoler rapidement les zones à problèmes pour diagnostiquer les problèmes d'erreur, de performances et de latence et leur source, tels que les applications de développeur, les proxys d'API, les cibles backend ou la plate-forme d'API.

Parcourez un exemple de scénario qui montre comment résoudre les problèmes 5xx avec vos API à l'aide de la surveillance des API. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre d'erreurs 500 dépasse un seuil particulier.

Si vous souhaitez être averti lorsqu'une réponse d'erreur 500 est générée par une règle, vous devez configurer l'alerte pour le code d'état 500 avec la source de l'erreur comme proxy.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez l'assistance Apigee et partagez-les avec elle.

Si vous êtes un utilisateur du cloud public, fournissez les informations suivantes :

Nom de l'organisation
Nom de l'environnement
Nom du proxy d'API
Commande curl complète avec la charge utile de la requête (le cas échéant) pour reproduire l'erreur 500
Fichier de trace contenant les requêtes avec l'erreur interne du serveur 500
Si les erreurs 500 ne se produisent pas actuellement, indiquez la période avec les informations de fuseau horaire au cours de laquelle les erreurs 500 se sont produites par le passé.

Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :

Message d'erreur complet observé pour les requêtes ayant échoué
Nom de l'organisation, de l'environnement et du proxy d'API pour lesquels vous observez des erreurs 500
Bundle de proxy d'API
Charge utile utilisée dans la requête (le cas échéant)
Fichier de trace contenant les requêtes avec l'erreur interne du serveur 500
Journaux d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Période avec les informations de fuseau horaire au cours de laquelle les erreurs 500 se sont produites.