500 Erreur interne du serveur – EmptyPath

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

Problème constaté

L'application cliente obtient 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

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 (Composants à la syntaxe) et RFC 3986, section 3.3: Path (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 contenir une barre oblique (/), même si le chemin ne comporte aucun autre caractère.

Par conséquent, si l'URL de requête du serveur backend ne contient pas du tout le composant path, c'est-à-dire qu'elle ne contient 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 lorsque le composant path est vide ou manquant.

Cause	Description	Instructions de dépannage applicables
Le chemin d'accès de l'URL du serveur backend (target.url) est vide	L'URL du serveur backend représentée par la variable de flux target.url comporte un chemin vide.	Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

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

Cause: Le chemin d'accès à 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 Tool ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
2. Si le code d'erreur est protocol.http.EmptyPath et que Source d'erreur a la valeur target, cela signifie que l'URL du serveur backend présente un chemin d'accès vide.

3. L'URL du serveur 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 de manière dynamique à l'aide de l'une des règles (dans le proxy/flux partagé) du flux de requêtes cible, de sorte qu'elle présente un chemin d'accès vide.

4. Déterminez si la variable de flux target.url comporte effectivement un chemin d'accès vide et la source de sa valeur en procédant comme suit:

   Trace

   Utiliser l'outil Trace

   Si vous avez capturé une trace de cette erreur, suivez les étapes décrites dans la section Utiliser l'outil Trace , puis procédez comme suit:

   1. Vérifiez si le chemin d'accès de target.url est 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 d'accès 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 contenir un chemin d'accès vide.
   4. Notez que target.url comprend les composants suivants :
      • scheme:https://mocktarget.apigee.net
      • path:vide

   Journaux

   Utiliser les journaux d'un serveur de journaux

   1. Si vous n'avez aucune trace pour cette erreur (problème intermittent), vérifiez si vous avez enregistré les informations sur la valeur de la variable de flux target.url à l'aide de règles telles que MessageLogging ou ServiceCallout à votre serveur de journalisation.
   2. Si vous disposez des journaux, examinez-les et procédez comme suit :
      1. Vérifiez si le chemin d'accès de target.url est vide.
      2. Vérifiez si vous pouvez déterminer quelle règle a modifié target.url pour contenir un chemin d'accès vide

   proxy d'API

   Examiner le proxy d'API défaillant

   Si vous ne disposez d'aucune trace ni journal pour cette erreur, examinez le proxy d'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 non valide. Vérifiez les éléments suivants :

   • La règle au sein du proxy d'API
   • Tous les flux partagés appelés à partir du proxy

5. Examinez attentivement la stratégie 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 la mise à jour de target.url comporte 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: Règle JavaScript mettant à jour la variable target.url

   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:

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

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

   Exemple 2

   Exemple n° 2: Règle JavaScript mettant à jour la variable target.url

   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 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 transmise à request.header.Path.

   Exemple de requête envoyé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 le cadre de la requête. Par conséquent, la valeur du chemin d'accès de la variable dans la règle JavaScript est null.

   Comme suit :

   • 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 n° 3: la règleAssignMessage 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 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 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.

Résolution

Conformément à la spécification RFC 3986, section 2: Syntax Components (Composants à la syntaxe), le composant path est obligatoire et DOIT toujours contenir une barre oblique (/), même si path ne contient pas d'autres caractères. 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 d'accès non vide.
   1. Dans certains cas, il est possible que le chemin ne contienne pas de nom de ressource. 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 qu'elles ne comportent pas de chemin d'accès vide.
   3. Si vous effectuez des opérations de chaîne pour déterminer la valeur de la variable de flux target.url, assurez-vous que le résultat des opérations de chaîne ne comporte 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 comme expliqué ci-dessous:

   Exemple 1

   Exemple n° 1: Règle JavaScript mettant à jour la variable target.url

   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: Règle JavaScript mettant à jour la variable target.url

   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 l'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: règleAssignMessage 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 avoir /json comme chemin d'accès pour l'API MockTarget. Autrement dit, remplacez l'élément <Value> par 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 contienne pas de chemin d'accès vide, conformément aux spécifications suivantes:

Spécification
RFC 3986, section 3: Composants de syntaxe
RFC 3986, section 3.3: chemin d'accès

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

Recueillir 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 de cloud public, fournissez les informations suivantes:

• Le nom de l'organisation.
• Nom de l'environnement
• Nom du proxy d'API
• Terminez la commande curl permettant de 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 ayant échoué
• 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 des 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