500 Erreur interne du serveur - BadPath

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.BadPath 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":"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 élément path qui commence par un point d'interrogation (?) au lieu d'une barre oblique (/), qui n'est pas valide.

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. Il DOIT commencer par une barre oblique (/) et doit toujours y avoir 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 l'élément path est non valide, car il commence par un point d'interrogation (?) au lieu d'une barre oblique (/).

Cause	Description	Instructions de dépannage applicables
L'URL du serveur backend (target.url) comporte un chemin non valide	Le composant de chemin dans l'URL du serveur backend représenté par la variable de flux target.url commence par un point d'interrogation (?) au lieu d'une barre oblique (/).	Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

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

Cause: L'URL du serveur backend (target.url) comporte un chemin non valide

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.BadPath et que Source d'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 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 (au sein du proxy/flux partagé) du flux de requêtes cible, de sorte qu'elle présente un chemin non valide.

4. Déterminez si la variable de flux target.url comporte bien un chemin d'accès non valide et la source pour sa valeur en utilisant 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 .

   1. Vérifiez si target.url comporte un chemin 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 règle qui a modifié ou mis à jour la valeur de target.url pour contenir 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 contenir un chemin d'accès non valide.
   4. Notez que target.url comprend les composants suivants :
      • scheme:https
      • authority: mocktarget.apigee.net
      • chemin d'accès:?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 d'un serveur de journaux

   1. Si vous n'avez aucune trace de 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 :
      1. Vérifiez si target.url comporte un chemin d'accès non valide.
      2. Vérifiez si vous pouvez déterminer la règle qui a modifié target.url pour contenir un chemin d'accès non valide

   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 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 la mise à jour de target.url présente un chemin non valide.

   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 non valide menant à cette erreur.

   Exemple 1

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

   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 se compose des éléments suivants:

   • scheme:https
   • authority: mocktarget.apigee.net
   • chemin d'accès:?json

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

   Exemple 2

   Exemple n° 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 réelle, vous pouvez vérifier la valeur réelle transmise à request.header.Path.

   Exemple de requête 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'en-tête n'est pas envoyé dans le cadre de la requête. Par conséquent, la valeur de la variable path dans la règle JavaScript est null.

   Comme suit :

   • 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
   • chemin d'accès:?user

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

   Exemple 3

   Exemple n° 3: la règle "AssignMessage" met à 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 comprend les composants suivants:

   • scheme:https
   • authority: mocktarget.apigee.net
   • chemin d'accès:?echo

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

Résolution

Conformément à la spécification d'URL RFC 3986, section 3 sur la syntaxe des composants, le composant path est obligatoire et doit toujours commencer par "/". Suivez donc les étapes ci-dessous 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, dispose toujours d'un chemin valide et commence toujours par une barre oblique (/).
   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 non valide.
   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 non valide.

2. Dans les exemples présentés ci-dessus, 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

   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 n° 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);
   

   Veillez à 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 n° 3: Mise à jour de la règle Attribution de message en cours de modification de 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 backend DOIT toujours commencer par une barre oblique (/) , 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 de l'aide de l'assistance Apigee, consultez la section Vous devez recueillir 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 de cloud public, fournissez les informations suivantes:

   • Le nom de l'organisation.
   • Nom de l'environnement
   • Nom de proxy d'API
   • Terminez la commande curl permettant de reproduire le 500 Internal Server Error avec le code d'erreur protocol.http.BadPath.
   • 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