Cette page a été traduite par l'API Cloud Translation.

500 – Erreur interne du serveur - Streaming activé

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

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

Ce message 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 de différentes causes. Ce playbook 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	Personnes pouvant effectuer les étapes de dépannage
Accéder à la charge utile avec le streaming activé	Une erreur s'est produite, car la charge utile requête/réponse est accessible lorsque le streaming est activé.	Utilisateurs périphériques de cloud privé et public

Cause: accès à la charge utile lorsque le streaming est activé

Diagnostic

Procédure n° 1: utiliser Trace

Activez la session de trace, puis 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 localisez l'origine de l'échec.
Cette erreur peut se produire lorsqu'une stratégie analyse la charge utile requête/réponse.
Voici un exemple de capture d'écran de trace montrant la règle JSONThreatProtection JSONThreatProtection qui échoue avec l'erreur JSONThreatProtection :

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

Règle en échec : JSONThreatProtection

Flux:requête de proxy

Examinez la définition de stratégie qui a é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 de l'en-tête Content-Type 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 stratégie qui échoue et déterminer le type de charge utile analysée. 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 que le format de la charge utile est correct. Si la charge utile n'est pas valide, cette erreur peut se produire.

Remarque : Si la charge utile est importante, vous pouvez utiliser n'importe quel outil de mise en forme en ligne pour valider son format.
Si la charge utile est valide, mais que vous continuez à recevoir des erreurs comme indiqué dans la section Messages d'erreur, ces erreurs sont dues au fait que la charge utile est accessible lorsque le streaming est activé.

En fonction de la charge utile analysée par la stratégie (comme déterminé à l'étape 6), examinez le contenu de la charge utile dans l'outil Trace dans 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 phase "Request Received from Client" (Demande reçue du client) dans la trace et vérifiez le champ Request Content.

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

En effet, lorsque le streaming est activé, la charge utile de la requête n'apparaît 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 "Réponse reçue du serveur cible".
Examinez ensuite les définitions du proxy et du point de terminaison cible en fonction de l'endroit où la règle défaillante est utilisée dans le flux de proxy de l'API. Vérifiez si le streaming est activé.

Dans l'exemple de scénario, la stratégie ayant échoué a été exécutée dans le flux de requête de proxy (comme déterminé à l'étape 5 ci-dessus). Par conséquent, examinez 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 illustré dans l'exemple ci-dessus, la diffusion des requêtes a été activée, 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 une mise en mémoire tampon dans le proxy d'API et va à l'encontre de l'objectif de l'utilisation du flux dans Apigee Edge.

Il est possible que cette erreur ne soit pas visible avec des charges utiles plus petites, mais lorsque vous utilisez des charges utiles plus importantes, vous pouvez voir ces erreurs.
Vous pouvez vérifier que l'erreur 500 est causée par la règle en vérifiant la valeur de "X-Apigee-fault-source" dans la phase AX (données Analytics enregistrées) de la trace en procédant comme suit :
1. Cliquez sur "AX" (Analytics Data Recorded) Phase, comme illustré dans la capture d'écran ci-dessous:
2. Faites défiler la page jusqu'à la section En-têtes d'erreur 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 illustré dans l'image ci-dessus, cela indique que l'erreur est causée par une règle accédant à la charge utile lorsque la diffusion en streaming est activée.

Résolution

L'accès à la charge utile lorsque le streaming est activé est un antischéma, comme expliqué dans Antimodèles: accéder à la charge utile 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 proxy/cible en supprimant les propriétés "request.streaming.enabled" and "response.streaming.enabled", comme indiqué dans l'exemple de point de terminaison ProxyEndpoint ci-dessous :
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
OU
Si vous souhaitez utiliser des flux 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 playbook, la règle JSONThreatProtection a été utilisée pour traiter la charge utile de la requête avec le streaming activé dans le scénario d'exemple. Cela entraînait une erreur 500 interne du serveur avec des erreurs différentes.
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 règles de ce type dans les proxys nécessitant un accès aux charges utiles lorsque le streaming est activé.
Il s'agit d'un antischéma, comme indiqué dans Antimodèles: accéder à la charge utile 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 problèmes afin de diagnostiquer les problèmes d'erreur, de performances et de latence, ainsi que leur source. C'est le cas, par exemple, des applications pour développeurs, des proxys d'API, des cibles backend ou de la plate-forme d'API.

Suivez 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 certain seuil.

Si vous souhaitez être averti lorsqu'une réponse d'erreur 500 est générée par la stratégie, vous devez configurer l'alerte pour le code d'état 500 avec la source d'erreur sur Proxy.

Doit recueillir 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-les et partagez-les avec l'assistance Apigee.

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

Nom de l'organisation
Nom de l'environnement
Nom du proxy d'API
Exécutez la commande curl ainsi que la charge utile de la requête (le cas échéant) pour reproduire l'erreur 500.
Fichier de suivi contenant les requêtes avec une erreur interne du serveur 500
Si les erreurs 500 ne se produisent pas actuellement, indiquez la période à laquelle les erreurs 500 se sont produites avec le fuseau horaire.

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

Message d'erreur complet observé pour les requêtes ayant échoué
Organisation, nom de l'environnement et nom du proxy de l'API pour lesquels vous observez des erreurs 500
Groupe de proxys d'API
Charge utile utilisée dans la requête (le cas échéant)
Fichier de suivi contenant les requêtes avec une 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 contenant le fuseau horaire au cours de laquelle les erreurs 500 se sont produites.