500 Erreur interne du serveur – EmptyPath

<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 HTTP 500 Internal Server Error avec le code d'erreur protocol.http.EmptyPath comme réponse aux appels d'API.

Message d'erreur

L'application cliente reçoit le code de réponse suivant:

HTTP/1.1 500 Internal Server Error

Le message d'erreur suivant peut également s'afficher:

{
   "fault":{
      "faultstring":"Request path cannot be empty",
      "detail":{
         "errorcode":"protocol.http.EmptyPath"
      }
   }
}

Causes possibles

Cette erreur se produit si l'URL de requête du serveur backend, représentée par la variable de flux <ph type="x-smartling-placeholder"></ph> target.url, contient un chemin d'accès vide.

Conformément aux spécifications <ph type="x-smartling-placeholder"></ph> RFC 3986, section 3: Composants de la syntaxe <ph type="x-smartling-placeholder"></ph> RFC 3986, section 3.3: Chemin d'accès:

1. La syntaxe de l'URI se compose des éléments suivants:

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. Le composant path est obligatoire et DOIT toujours comporter une barre oblique (/), même si le chemin ne contient aucun autre caractère.

Par conséquent, si l'URL de requête du serveur backend ne comporte pas le path c'est-à-dire qu'il n'a même pas de barre oblique (/), alors qu'Apigee Edge répond avec 500 Internal Server Error et un code d'erreur protocol.http.EmptyPath

Par exemple, si target.url a la valeur https://www.mocktarget.apigee.net, cette erreur se produit lorsque path Le composant est vide ou manquant.

Cause	Description	Instructions de dépannage applicables
Le chemin de l'URL du serveur backend (target.url) est vide	Le chemin de l'URL du serveur backend représentée par la variable de flux target.url est vide.	Utilisateurs Edge de cloud public et privé

Étapes de diagnostic courantes

Utilisez l'une des techniques ou l'un des outils suivants pour diagnostiquer ce problème:

Cause: le chemin de l'URL du serveur backend (target.url) est vide

Diagnostic

1. Déterminez le code d'erreur et la source d'erreur pour 500 Internal Server Error à l'aide de la surveillance des API, de l'outil Trace ou des journaux d'accès NGINX comme expliqué dans Étapes de diagnostic courantes.
2. Si le code d'erreur est protocol.http.EmptyPath et que la source d'erreur est la valeur target, cela indique que l'URL du serveur backend présente un chemin.

3. L'URL du serveur backend est représentée par la variable de flux target.url dans Apigee. Périphérie. Cette erreur se produit généralement lorsque vous essayez de mettre à jour l'URL du serveur backend, target.url de manière dynamique en utilisant l'une des règles (dans proxy/flux partagé) dans le flux de requêtes Target, de sorte que son chemin d'accès est vide.

   <ph type="x-smartling-placeholder">
4. Déterminez si la variable de flux target.url a effectivement un chemin vide et si la source de sa valeur en procédant de l'une des façons suivantes:

   Trace

   Utiliser l'outil Trace

   Si vous avez capturé une trace pour cette erreur, suivez les étapes décrites dans la section Utiliser l'outil Trace :

   1. Vérifiez si le chemin d'accès de target.url est vide.

   2. Si c'est le cas, découvrez quelle stratégie a modifié ou mis à jour la valeur de target.url pour contenir un chemin d'accès vide.

      Exemple de trace montrant que la stratégie JavaScript a mis à jour la variable de flux target.url:

      
   3. Dans l'exemple de trace ci-dessus, notez que la stratégie JavaScript a modifié ou a modifié la valeur de target.url pour qu'elle contienne un chemin d'accès vide.
   4. Notez que target.url comprend les composants suivants: <ph type="x-smartling-placeholder">
      </ph>
      • schéma:https://mocktarget.apigee.net
      • path:vide

   Journaux

   Utiliser des journaux sur votre serveur de journaux

   1. Si vous n'avez aucune trace de cette erreur (problème intermittent), consultez voir si vous avez enregistré les informations sur la valeur de la variable de flux target.url, à l'aide de règles telles que <ph type="x-smartling-placeholder"></ph> MessageLogging ou <ph type="x-smartling-placeholder"></ph> ServiceAccroche à votre serveur de journaux.
   2. Si vous disposez des journaux, examinez-les et procédez comme suit: <ph type="x-smartling-placeholder">
      </ph>
      1. Vérifiez si target.url a un chemin d'accès vide et
      2. Vérifiez si vous pouvez déterminer quelle stratégie a modifié target.url contenir un chemin d'accès vide

   proxy d'API

   Examiner le proxy d'API en échec

   Si vous ne disposez d'aucune trace ni de journaux pour cette erreur, examinez l'API défaillante pour déterminer ce qui a modifié ou mis à jour la variable de flux target.url de contenir un chemin d'accès non valide. Vérifiez les éléments suivants :

   • La stratégie dans le proxy d'API
   • Tous les flux partagés appelés à partir du proxy

5. Examinez la stratégie spécifique (par exemple, assignMessage ou JavaScript) qui modifie ou met à jour soigneusement la variable de flux target.url et détermine la cause de la mise à jour target.url pour avoir un chemin d'accès vide.

   Voici quelques exemples de règles qui mettent à jour la variable de flux target.url de manière incorrecte pour contenir un chemin d'accès vide menant à cette erreur.

   Exemple 1

   Exemple n° 1: Mise à jour de la variable target.url par une règle JavaScript

   var url = "https://mocktarget.apigee.net"
   context.setVariable("target.url", url);
   

   Dans l'exemple ci-dessus, notez que la variable de flux target.url est mise à jour avec la valeur https://mocktarget.apigee.net contenue dans une autre variable url

   Notez que target.url comprend les composants suivants:

   • schéma:https://mocktarget.apigee.net
   • path:vide

   Puisque le chemin d'accès est vide, Apigee Edge renvoie 500 Internal Server Error avec code d'erreur protocol.http.EmptyPath.

   Exemple 2

   Exemple n° 2: Mise à jour de la variable target.url par une règle JavaScript

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   Dans l'exemple ci-dessus, notez que la variable de flux target.url est mise à jour par concaténer la valeur https://mocktarget.apigee.net contenue dans une variable url et la valeur d'une autre variable path, dont La valeur est extraite de request.header.Path.

   Si vous avez accès à la requête ou à la trace réelle, vous pouvez vérifier la valeur réelle transmis à request.header.Path.

   Exemple de requête effectuée par l'utilisateur:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token>
   

   Dans cet exemple, le chemin d'en-tête n'est pas envoyé dans la requête. Par conséquent, la valeur du chemin d'accès de la variable dans la règle JavaScript est null.

   Exemple :

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + null
   • target.url = https://mocktarget.apigee.netnull

   Notez que target.url comprend les composants suivants:

   • schéma:https://mocktarget.apigee.netnull
   • path:vide

   Exemple 3

   Exemple n° 3: La règle AffectMessage met à jour la variable target.url via une autre variable

   <AssignMessage async="false" continueOnError="false" enabled="true" name=">AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>
   

   Notez que target.url comprend les composants suivants:

   • schéma:https://mocktarget.apigee.net
   • path:vide

   Dans tous les exemples ci-dessus, le chemin d'accès dans l'URL du serveur backend, qui est target.url étant vide, Apigee Edge renvoie 500 Internal Server Error avec le code d'erreur protocol.http.EmptyPath.

Solution

Conformément aux spécifications <ph type="x-smartling-placeholder"></ph> RFC 3986, section 2: Composants de syntaxe, le composant path est obligatoire et il DOIT toujours comporter une barre oblique (/), même s'il n'y a pas d'autres caractères dans path. Procédez comme suit pour résoudre ce problème:

1. Assurez-vous que l'URL du serveur backend, représentée par la variable de flux target.url a toujours un chemin d'accès non vide.
   1. Dans certains cas, il se peut que le chemin d'accès ne contienne pas de nom de ressource, puis assurez-vous que celui-ci comporte au moins une barre oblique (/).
   2. Si vous utilisez d'autres variables pour déterminer la valeur de la variable de flux target.url, puis assurez-vous que le chemin des autres variables n'est pas vide.
   3. Si vous effectuez des opérations de chaîne pour déterminer la valeur de la variable de flux target.url, puis vérifiez que le résultat de la chaîne n'a pas de chemin d'accès vide.
2. Dans les exemples présentés dans la section Diagnostic, vous pouvez résoudre ce problème en tant que expliqué ci-dessous:

   Exemple 1

   Exemple n° 1: Mise à jour de la variable target.url par une règle JavaScript

   Ajoutez une barre oblique (/) à la variable url pour résoudre ce problème comme indiqué ci-dessous:

   var url = "https://mocktarget.apigee.net/"
   context.setVariable("target.url", url);
   

   Exemple 2

   Exemple n° 2: Mise à jour de la variable target.url par une règle JavaScript

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);
   

   Veillez à transmettre un chemin d'accès valide, par exemple /iloveapis, dans le cadre de en-tête de requête Path pour résoudre ce problème comme indiqué ci-dessous:

   Exemple de requête:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /iloveapis"
   

   Exemple 3

   Exemple n° 3: La règle AffectMessage met à jour la variable target.url via une autre variable

   Ajoutez un chemin d'accès valide dans l'élément <Value> de la règle AffectMessage. Pour par exemple, vous pouvez avoir /json comme chemin d'accès API MockTarget Autrement dit, modifiez l'élément <Value> pour qu'il https://mocktarget.apigee.net/json comme indiqué ci-dessous:

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/json</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>
   

Spécification

Apigee Edge s'attend à ce que l'URL du serveur backend ne comporte pas de chemin d'accès vide, conformément à la les spécifications suivantes:

Spécification
<ph type="x-smartling-placeholder"></ph> RFC 3986, section 3: Composants de la syntaxe
<ph type="x-smartling-placeholder"></ph> RFC 3986, section 3.3: Chemin d'accès

Si vous avez encore besoin de l'aide de l'assistance Apigee, accédez à Obligation de recueillir des informations de diagnostic.

Obligation de recueillir des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, rassemblez les informations suivantes : de diagnostic, puis contactez l'assistance Apigee Edge.

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 utilisée pour reproduire le 500 Internal Server Error avec le code d'erreur protocol.http.EmptyPath.
• Fichier de suivi des requêtes API

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

• Message d'erreur complet observé pour les requêtes en échec
• Nom de l'environnement
• Groupe de proxys d'API
• Fichier de suivi des requêtes API

• Journaux d'accès NGINX:

  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Où:ORG, ENV et PORT# sont remplacés par les valeurs réelles.

• Journaux système du processeur de messages /opt/apigee/var/log/edge-message- processor/logs/system.log

Références

Variables de flux – Cible