500 Erreur interne du serveur – EmptyPath

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

Problème constaté

L'application cliente reçoit un code d'état HTTP 500 Internal Server Error avec le code d'erreur protocol.http.EmptyPath en 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

De plus, le message d'erreur suivant peut 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 target.url, contient un chemin vide.

Conformément aux spécifications RFC 3986, section 3: Syntax Components et RFC 3986, section 3.3: Path :

1. La syntaxe URI comprend les composants 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 la requête du serveur backend ne comporte pas du tout le composant path, c'est-à-dire qu'elle ne comporte même pas de barre oblique (/), Apigee Edge répond avec 500 Internal Server Error et le code d'erreur protocol.http.EmptyPath.

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

Étapes de diagnostic courantes

Utilisez l'un des outils/techniques suivants pour diagnostiquer cette erreur :

Cause : l'URL du serveur backend (target.url) comporte un chemin vide

Diagnostic

1. Déterminez le code d'erreur et la source de l'erreur pour 500 Internal Server Error à l'aide de la surveillance de l'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 de l'erreur a la valeur target, cela indique que l'URL du serveur backend a un chemin vide.

3. L'URL du serveur de backend est représentée par la variable de flux target.url dans Apigee Edge. Cette erreur se produit généralement si vous essayez de mettre à jour l'URL du serveur backend, c'est-à-dire target.url dynamiquement à l'aide de l'une des règles (dans le flux de proxy/partagé) dans le flux de requête cible, de sorte qu'il comporte un chemin vide.

4. Déterminez si la variable de flux target.url a effectivement un chemin vide et la source de sa valeur en suivant l'une des étapes suivantes :

   Trace

   Utiliser l'outil Trace

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

   1. Vérifiez si target.url a un chemin vide.

   2. Si c'est le cas, identifiez la règle qui a modifié ou mis à jour la valeur de target.url pour qu'elle contienne un chemin vide.

      Exemple de trace montrant que la règle JavaScript a mis à jour la variable de flux target.url:

      
   3. Dans l'exemple de trace ci-dessus, notez que la règle JavaScript a modifié ou mis à jour la valeur de target.url pour qu'elle contienne un chemin vide.
   4. Notez que target.url comporte les composants suivants :
      • scheme : https://mocktarget.apigee.net
      • path vide

   Journaux

   Utiliser les journaux sur votre serveur de journaux

   1. Si vous n'avez pas de trace pour cette erreur (problème intermittent), vérifiez si vous avez consigné les informations sur la valeur de la variable de flux target.url à l'aide de règles telles que MessageLogging ou ServiceCallout sur votre serveur de journaux.
   2. Si vous disposez des journaux, examinez-les et :
      1. Vérifiez si target.url a un chemin vide.
      2. Déterminez si vous pouvez identifier la règle qui a modifié target.url pour qu'il contienne un chemin d'accès vide.

   proxy d'API

   Examiner le proxy d'API en échec

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

   • Règle dans le proxy d'API
   • Tous les flux partagés appelés à partir du proxy

5. Examinez attentivement la règle spécifique (AssignMessage ou JavaScript, par exemple) qui modifie ou met à jour la variable de flux target.url et déterminez la raison pour laquelle target.url est mis à jour pour avoir un chemin vide.

   Voici quelques exemples de règles qui mettent à jour la variable de flux target.url de manière incorrecte pour qu'elle contienne un chemin vide, ce qui entraîne cette erreur.

   Exemple 1

   Exemple 1 : Mise à jour de la variable target.url de la 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 comporte les composants suivants :

   • scheme : https://mocktarget.apigee.net
   • path vide

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

   Exemple 2

   Exemple 2 : Mise à jour de la variable target.url de la 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 en concaténant la valeur https://mocktarget.apigee.net contenue dans une variable url et la valeur d'une autre variable path, dont la valeur est récupérée à partir de request.header.Path..

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

   Exemple de demande effectuée par l'utilisateur :

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

   Dans cet exemple, le chemin d'accès de l'en-tête n'est pas envoyé dans la requête. Par conséquent, la valeur du chemin de 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 comporte les composants suivants :

   • scheme : https://mocktarget.apigee.netnull
   • path vide

   Exemple 3

   Exemple 3 : Règle AssignMessage mettant à 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 comporte les composants suivants :

   • scheme : https://mocktarget.apigee.net
   • path vide

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

Solution

Conformément à la spécification RFC 3986, section 2 : Composants de syntaxe, le composant path est obligatoire et doit toujours comporter une barre oblique (/), même s'il ne contient aucun autre caractère.path Pour résoudre ce problème, procédez comme suit :

1. Assurez-vous que l'URL du serveur backend, représentée par la variable de flux target.url, comporte toujours un chemin non vide.
   1. Dans certains cas, il est possible que vous n'ayez pas de nom de ressource dans le chemin. Dans ce cas, assurez-vous qu'il 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, assurez-vous que ces autres variables n'ont pas de chemin vide.
   3. Si vous effectuez des opérations sur des chaînes pour déterminer la valeur de la variable de flux target.url, assurez-vous que le résultat ou le résultat des opérations sur les chaînes ne comporte pas de chemin vide.
2. Dans les exemples abordés dans Diagnostic, vous pouvez résoudre ce problème comme expliqué ci-dessous :

   Exemple 1

   Exemple 1 : Mise à jour de la variable target.url de la 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 2 : Mise à jour de la variable target.url de la règle JavaScript

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

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

   Exemple de demande :

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

   Exemple 3

   Exemple 3 : Règle AssignMessage mettant à jour la variable target.url via une autre variable

   Ajoutez un chemin valide dans l'élément <Value> de la règle AssignMessage. Par exemple, vous pouvez définir /json comme chemin d'accès pour l'API MockTarget. Autrement dit, modifiez l'élément <Value> en 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 vide, conformément aux spécifications suivantes :

Si vous avez encore besoin d'aide de l'assistance Apigee, consultez la page Vous devez collecter des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge.

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

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'environnement
• Bundle de proxy d'API
• Fichier de trace pour les 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 des valeurs réelles.

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

Références