500 Erreur interne du serveur - BadPath

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.BadPath 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":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

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 path commençant par un point d'interrogation (?) au lieu d'une barre oblique (/), ce qui est non valide.

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 commencer et toujours comporter une barre oblique (/).

Par conséquent, si l'URL de requête du serveur backend comporte un composant path commençant par un point d'interrogation (?) au lieu d'une barre oblique (/), Apigee Edge répond avec 500 Internal Server Error et le code d'erreur protocol.http.BadPath.

Par exemple, si target.url a la valeur https://www.mocktarget.apigee.net?json, cette erreur se produit, car path est considéré comme non valide, car il commence par un point d'interrogation (?) au lieu d'une barre oblique (/).

Étapes de diagnostic courantes

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

Cause : L'URL du serveur backend (target.url) contient un chemin d'accès non valide.

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.BadPath et que la source de l'erreur a la valeur target, cela signifie que l'URL du serveur backend comporte un chemin d'accès non valide.

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 (target.url) de manière dynamique à l'aide de l'une des règles (dans le flux de proxy/partagé) dans le flux de requête cible, de sorte qu'elle comporte un chemin non valide.

4. Déterminez si la variable de flux target.url possède effectivement un chemin non valide et la source de sa valeur à l'aide de l'une des méthodes 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 comporte un chemin d'accès non valide, c'est-à-dire s'il commence par un point d'interrogation (?) au lieu d'une barre oblique (/).

   2. Si c'est le cas, identifiez la stratégie qui a modifié ou mis à jour la valeur de target.url pour qu'elle contienne un chemin d'accès non valide.

      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 non valide.
   4. Notez que target.url comporte les composants suivants :
      • scheme : https
      • authority: mocktarget.apigee.net
      • path: ?json

      Le chemin commence par un point d'interrogation (?) au lieu d'une barre oblique (/), il n'est donc pas valide.

   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 comporte un chemin d'accès non valide.
      2. Déterminez quelle règle a modifié target.url pour qu'il contienne un chemin d'accès non valide.

   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 (par exemple, AssignMessage ou JavaScript) qui modifie ou met à jour la variable de flux target.url, et déterminez la raison pour laquelle target.url a été mis à jour avec un chemin d'accès non valide.

   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 d'accès non valide, 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?json"
   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?json contenue dans une autre variable url..

   Notez que la valeur de url comporte les composants suivants :

   • scheme : https
   • authority: mocktarget.apigee.net
   • path: ?json

   Le chemin commence par un point d'interrogation (?) au lieu d'une barre oblique (/), ce qui est non valide. Par conséquent, Apigee Edge renvoie 500 Internal Server Error avec le code d'erreur protocol.http.BadPath.

   Exemple 2

   Exemple 2 : Règle JavaScript mettant à jour la variable target.url en fonction de la valeur de l'en-tête de requête

   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, 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> -H "Path: ?user"
   

   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 de la variable path dans la règle JavaScript est null.

   Exemple :

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   Notez que la valeur de target.url comporte les composants suivants :

   • scheme : https
   • authority: mocktarget.apigee.net
   • path: ?user

   Le chemin commence par un point d'interrogation (?) au lieu d'une barre oblique (/), ce qui est non valide. Par conséquent, Apigee Edge renvoie 500 Internal Server Error avec le code d'erreur protocol.http.BadPath.

   Exemple 3

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

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

   Notez que la valeur de url comporte les composants suivants :

   • scheme : https
   • authority: mocktarget.apigee.net
   • path: ?echo

   Dans cet exemple, le chemin d'accès commence par un point d'interrogation (?) au lieu d'une barre oblique (/), ce qui est non valide. Par conséquent, Apigee Edge renvoie 500 Internal Server Error avec le code d'erreur protocol.http.BadPath.

Solution

Conformément à la spécification des URL RFC 3986, section 3 : Composants de syntaxe, le composant path est obligatoire et doit toujours commencer par "/". 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 valide et commence toujours par une barre oblique (/).
   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 qu'elles ne comportent pas de chemin d'accès non valide.
   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 de ces opérations ne comporte pas de chemin d'accès non valide.

2. Dans les exemples ci-dessus, vous pouvez résoudre ce problème comme suit :

   Exemple 1

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

   Utilisez une barre oblique (/) au lieu d'un point d'interrogation (?) dans la variable url pour résoudre ce problème, comme indiqué ci-dessous :

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

   Exemple 2

   Exemple 2 : Règle JavaScript mettant à jour la variable target.url en fonction de la valeur de l'en-tête de requête

   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 /user, 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: /user"
   

   Exemple 3

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

   Ajoutez un chemin valide dans l'élément <Value> de la règle AssignMessage. Autrement dit, remplacez le point d'interrogation (?) par une barre oblique (/) dans l'élément <Value> et définissez-le sur https://mocktarget.apigee.net/echo pour résoudre ce problème, 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/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   Spécification

   Apigee Edge s'attend à ce que le composant path de l'URL du serveur de backend commence toujours par une barre oblique (/) , conformément aux spécifications suivantes :

   Spécification
   RFC 3986, section 3: Syntax Components (en anglais)
   RFC 3986, section 3.3 : Chemin d'accès

   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 de proxy d'API
   • Commande curl complète utilisée pour reproduire 500 Internal Server Error avec le code d'erreur protocol.http.BadPath
   • 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

   Variables de flux : cible