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

500 – Erreur interne du serveur - Streaming activé

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

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 illustré 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 pour différentes raisons. Ce playbook se concentre sur l'erreur interne du serveur 500 causée par l'accès à la requête/réponse lors de la diffusion en streaming est activé.

Cause	Description	Qui peut effectuer la procédure de dépannage ?
Accéder à la charge utile avec Streaming activé	Une erreur s'est produite en raison de l'accès à la charge utile de requête/réponse lorsque la diffusion est activée.	Utilisateurs de cloud privé et public Edge

Cause: accès à la charge utile avec le traitement par flux activé

Diagnostic

Procédure n° 1: Utiliser Trace

Activez la trace session, 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 s'est peut-être produite lorsqu'une stratégie analyse la charge utile de la requête/réponse.
Voici un exemple de capture d'écran de trace montrant l'objet JSONThreatProtection policy avec l'erreur "Expecting } at line 1":

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

Règle en cas d'échec : JSONThreatProtection

Parcours:demande de proxy

Examinez la définition de stratégie en échec et vérifiez la charge utile en cours d'analyse.

Dans l'exemple de scénario, examinez la stratégie JSONThreatProtection nommée JSON-Threat-Protection ayant é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 analysée en vérifiant la requête API.

Vous pouvez vérifier le contenu de la charge utile de la requête et 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ées. 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 la charge utile est au bon format. 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 outil de mise en forme en ligne pour valider format de la charge utile.
Si la charge utile est valide, mais que vous obtenez toujours des erreurs, comme indiqué dans le Messages d'erreur, la cause de ces erreurs est que la charge utile est consultée lorsque le streaming est activé.

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

Si le champ "Request Content" (Contenu de la requête) est vide, comme illustré 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 la diffusion des requêtes est activée.

En effet, lorsque l'insertion en flux continu est activée, la charge utile de la requête n'apparaît pas sur 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 le contenu de la réponse lors de 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'emplacement est utilisée dans le flux de proxy d'API. Vérifiez si la diffusion a été activée.

Dans l'exemple de scénario, la stratégie en échec a été exécutée dans le flux de requête 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 le montre l'exemple ci-dessus, le streaming des requêtes a été activé, comme l'indique le lien "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 il déclenche la mise en mémoire tampon dans le proxy d'API et annule l'utilisation des flux de données dans Apigee Edge.

Il est possible que cette erreur ne se produise pas avec des charges utiles plus petites, mais lorsque vous utilisez des charges utiles plus grandes, peuvent voir ces erreurs.
Vous pouvez vous assurer que l'erreur 500 est due à la règle en vérifiant la valeur de "X-Apigee-fault-source" dans le répertoire "AX" (Données Analytics enregistrées) Phase de la trace: <ph type="x-smartling-placeholder">
1. Cliquez sur la phase AX (Données analytiques enregistrées). comme illustré dans la capture d'écran ci-dessous:
2. Faites défiler la section "Phase Details" (Détails de la phase) jusqu'à la section "Error Headers" (En-têtes d'erreur). et déterminent 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 indique que l'erreur est due à une règle d'accès 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 proxy/la cible point de terminaison 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èdent à la charge utile de la requête/réponse.

Remarque :

Dans ce playbook, la stratégie JSONThreatProtection a été utilisée pour traiter la charge utile de la requête avec le traitement par flux activé dans l'exemple de scénario. Cela a généré 500 erreur interne du serveur avec différentes erreurs.
Ces erreurs sont également visibles par les règles telles que JSONToXML et XMLToJSON, qui traitent des charges utiles de requête ou de réponse lorsque la diffusion est activée.
Nous vous recommandons vivement de ne pas utiliser de stratégies de ce type dans les proxys nécessitant un accès lorsque le streaming est activé.
Il s'agit d'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 utilisez un cloud privé, ignorez cette procédure.

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

Passez en revue un exemple de scénario qui montre comment résoudre les problèmes 5xx avec vos API à l'aide de l'API Monitoring. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre de 500 erreurs 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.

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez 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 avec la charge utile de la requête (le cas échéant) pour reproduire l'erreur 500.
Fichier de suivi contenant les requêtes associées à l'erreur 500 du serveur interne
Si les erreurs 500 ne se produisent pas actuellement, indiquez la période avec les informations de fuseau horaire lorsque des erreurs 500 se sont produites dans le passé.

Si vous êtes un utilisateur de Private Cloud, fournissez les informations suivantes:

Message d'erreur complet observé pour les requêtes en échec
Organisation, nom de l'environnement et nom du proxy d'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 associées à l'erreur 500 du serveur interne
Journaux d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Journaux de processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Période incluant les informations de fuseau horaire au cours de laquelle les erreurs 500 se sont produites.