<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.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
Le message d'erreur suivant peut également 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 (?
)
d'une barre oblique (/
), qui est non valide.
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:
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
- Le composant
path
est obligatoire et DOIT commencer par et toujours comporter une barre oblique (/
).
Par conséquent, si l'URL de requête du serveur backend comporte un composant path
qui démarre
par un point d'interrogation (?
) au lieu d'une barre oblique (/
), puis Apigee
Edge répond avec 500 Internal Server Error
et un code d'erreur
protocol.http.BadPath
Par exemple, si target.url
a la valeur
https://www.mocktarget.apigee.net?json
, cette erreur se produit lorsque
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 d'accès non valide | Composant de chemin d'accès dans l'URL du serveur backend représenté par une variable de flux
target.url commence par un point d'interrogation (? ) au lieu d'un avant
(/ ). |
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:
Surveillance des API
Procédure n° 1: Utiliser la surveillance des API
<ph type="x-smartling-placeholder">Pour diagnostiquer l'erreur à l'aide de l'API Monitoring, procédez comme suit:
- <ph type="x-smartling-placeholder"></ph> Connectez-vous à l'interface utilisateur d'Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.
Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.
- Accédez à Analyser > Surveillance des API > Examiner.
- Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.
Représentez le code d'erreur par rapport à l'heure.
<ph type="x-smartling-placeholder">Sélectionnez une cellule avec le code d'erreur
protocol.http.BadPath
, comme indiqué ci-dessous:Les informations sur le code d'erreur
protocol.http.BadPath
s'affichent sous la forme comme indiqué ci-dessous:Cliquez sur Afficher les journaux et développez la ligne correspondant à la requête ayant échoué.
- Dans la fenêtre Journaux, notez les détails suivants:
<ph type="x-smartling-placeholder">
- </ph>
- Code d'état:
500
- Source de l'erreur:
target
- Code d'erreur:
protocol.http.BadPath
- Code d'état:
- Si la source d'erreur est
target
et que le code d'erreur estprotocol.http.BadPath
, cela indique que l'URL du serveur backend dispose d'un chemin d'accès non valide.
Trace
Procédure n° 2: Utiliser l'outil Trace
<ph type="x-smartling-placeholder">Pour diagnostiquer l'erreur à l'aide de l'outil Trace:
- Activez la session de trace, puis
<ph type="x-smartling-placeholder">
- </ph>
- Attendez que l'erreur
500 Internal Server Error
se produise. - Si vous pouvez reproduire le problème, effectuez l'appel d'API pour le reproduire.
500 Internal Server Error
- Attendez que l'erreur
Assurez-vous que l'option Show all FlowInfos (Afficher toutes les infos FlowInfos) est activée:
- Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
- Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
L'erreur se produit généralement dans un flux après le début du flux de requête cible . comme indiqué ci-dessous:
Notez la valeur de l'erreur à partir de la trace:
error: Chemin de requête non valide
Étant donné que l'erreur est générée par Apigee Edge après le début du flux de requête cible , cela indique que l'URL du serveur backend présente un chemin d'accès non valide. Cela permettrait se produire très probablement si la variable de flux
target.url
(qui représente l'URL pour le serveur backend) dans Apigee Edge avec un chemin d'accès non valide via l'une des stratégies du flux de requêtes cible.- Examinez la section Variables lues et attribuées dans chacun des flux en sens inverse. du flux d'erreur vers la phase Target Request Flow Started (Flux de requête cible démarré).
- Déterminez la règle, où se trouvait la variable de flux
target.url
mis à jour:Exemple de trace montrant que la stratégie JavaScript a mis à jour la variable de flux
target.url:
Dans l'exemple de trace ci-dessus, notez la valeur de la variable de flux
target.url
est mis à jour dans une règle JavaScript nomméeJS- SetTargetURL
, comme suit:target.url : https://mocktarget.apigee.net?json
- Notez que la valeur de
target.url
comprend les composants suivants: <ph type="x-smartling-placeholder">- </ph>
- schéma:
https
- autorité:
mocktarget.apigee.net
- chemin d'accès:
?json
- schéma:
- Le composant path commence par un point d'interrogation (
?
). au lieu d'une barre oblique (/
), vous obtenez l'erreurInvalid request path
- Accédez à la phase AX (Données analytiques enregistrées) dans la trace, puis cliquez dessus.
Faites défiler la page jusqu'à la section Phase Details - Error Headers (Détails de la phase - En-têtes d'erreur) et déterminez de X-Apigee-fault-code et X-Apigee-fault-source, comme indiqué ci-dessous:
Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source comme
protocol.http.BadPath
ettarget
, respectivement, indiquant que cette erreur est due au fait que l'URL du serveur backend a un chemin d'accès non valide.En-têtes de réponse Valeur X-Apigee-fault-code protocol.http.BadPath
X-Apigee-fault-source target
NGINX
Procédure n° 3: Utiliser les journaux d'accès NGINX
<ph type="x-smartling-placeholder">Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX:
- Si vous êtes un utilisateur Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer
les informations clés concernant HTTP
500 Internal Server Error
. Vérifiez les journaux d'accès NGINX:
<ph type="x-smartling-placeholder">/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Effectuez une recherche pour voir s'il existe des erreurs
500
avec un code d'erreurprotocol.http.BadPath
pendant une durée spécifique (si le problème est survenu pendant ou si des requêtes échouent toujours avec500
. Si vous trouvez des erreurs
500
avec la correspondance X-Apigee-fault-code la valeur deprotocol.http.BadPath
, puis déterminez la valeur de X- Apigee-fault-source.Exemple d'erreur 500 dans le journal d'accès NGINX:
L'exemple d'entrée ci-dessus du journal d'accès NGINX contient les valeurs suivantes pour X-Apigee- fault-code et X-Apigee-fault-source:
En-têtes Valeur X-Apigee-fault-code protocol.http.BadPath
X-Apigee-fault-source target
Notez que les valeurs de X-Apigee-fault-code et X-Apigee-fault-source sont
protocol.http.BadPath
ettarget
, respectivement, ce qui indique que cette erreur est due au fait que l'URL du serveur backend présente un chemin d'accès non valide.
Cause: l'URL du serveur backend (target.url) comporte un chemin d'accès non valide
Diagnostic
- 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. - Si le code d'erreur est
protocol.http.BadPath
et que la source d'erreur est la valeurtarget
, cela indique que l'URL du serveur backend présente un chemin. L'URL du serveur backend est représentée par la variable de flux
<ph type="x-smartling-placeholder">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 qu'il présente un chemin d'accès non valide.Déterminez si la variable de flux
target.url
possède effectivement une valeur non valide. path 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 la section Utiliser l'outil Trace
- Vérifiez si
target.url
a un chemin d'accès non valide, c'est-à-dire s'il démarre par un point d'interrogation (?
) au lieu d'une barre oblique (/
). Si c'est le cas, recherchez la stratégie 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 stratégie JavaScript a mis à jour la variable de flux
target.url
- 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 d'accès non valide. - Notez que
target.url
comprend les composants suivants: <ph type="x-smartling-placeholder">- </ph>
- schéma:
https
- autorité:
mocktarget.apigee.net
- chemin d'accès:
?json
Le chemin commence par un point d'interrogation (
?
) au lieu d'un transfert barre oblique (/
), elle n'est donc pas valide. - schéma:
Journaux
Utiliser des journaux sur votre serveur de journaux
- 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 <ph type="x-smartling-placeholder"></ph> MessageLogging ou <ph type="x-smartling-placeholder"></ph> ServiceAccroche à votre serveur de journaux. - Si vous disposez des journaux, examinez-les et
<ph type="x-smartling-placeholder">
- </ph>
- Vérifiez si
target.url
possède un chemin d'accès non valide et - Vérifier si vous pouvez déterminer les informations sur la stratégie modifiée
target.url
pour contenir un chemin d'accès non valide
- Vérifiez si
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
- Vérifiez si
Examinez attentivement la règle spécifique (par exemple, AffectMessage ou JavaScript) qui modifie ou met à jour la variable de flux
target.url
et détermine la cause de Mettre à jourtarget.url
pour lui attribuer un chemin d'accès non valideVoici quelques exemples de règles qui mettent à jour la variable de flux
target.url
de manière incorrecte pour contenir un chemin non valide menant à cette erreur.Exemple 1
Exemple n° 1: Mise à jour de la variable
target.url
par une règle JavaScriptvar 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 dont la valeurhttps://mocktarget.apigee.net?json
est contenue dans une autre variableurl.
Notez que la valeur de
url
se compose des éléments suivants:- schéma:
https
- autorité:
mocktarget.apigee.net
- chemin d'accès:
?json
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 renvoie500 Internal Server Error
avec le code d'erreurprotocol.http.BadPath
.Exemple 2
Exemple n° 2: Mise à jour de la variable
target.url
par une règle JavaScript en fonction de la valeur indiquée dans l'en-tête de la requêtevar 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 valeurhttps://mocktarget.apigee.net
contenue dansurl
et la valeur d'une autre variablepath
, dont la valeur est extraite derequest.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> -H "Path: ?user"
Dans cet exemple, le chemin d'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 estnull
.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
se compose des éléments suivants:- schéma:
https
- autorité:
mocktarget.apigee.net
- chemin d'accès:
?user
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 renvoie500 Internal Server Error
avec le code d'erreurprotocol.http.BadPath
.Exemple 3
Exemple n° 3: La règle AffectMessage 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:- schéma:
https
- autorité:
mocktarget.apigee.net
- chemin d'accès:
?echo
Dans cet exemple encore, le chemin commence par un point d'interrogation (
?
). au lieu d'une barre oblique (/
), qui est non valide. Par conséquent, Apigee Edge renvoie500 Internal Server Error
avec un code d'erreurprotocol.http.BadPath
- schéma:
Solution
Conformément à la spécification de l'URL
<ph type="x-smartling-placeholder"></ph>
RFC 3986, section 3: Composants de syntaxe, le composant path
est obligatoire
et il DOIT toujours commencer par "/". Pour résoudre ce problème, procédez comme suit:
- 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 valide et commence toujours par un (/
). <ph type="x-smartling-placeholder">- </ph>
- Dans certains cas, il se peut que le chemin d'accès ne contienne pas de nom de ressource. Dans ce cas, assurez-vous que la propriété
le chemin d'accès comporte au moins une barre oblique (
/
). - Si vous utilisez d'autres variables pour déterminer la valeur de la variable de flux
target.url
, puis assurez-vous que les autres variables n'ont pas de valeur chemin d'accès non valide. - 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 les opérations ne comportent pas de chemin d'accès non valide.
- Dans certains cas, il se peut que le chemin d'accès ne contienne pas de nom de ressource. Dans ce cas, assurez-vous que la propriété
le chemin d'accès comporte au moins une barre oblique (
Dans les exemples présentés ci-dessus, vous pouvez résoudre ce problème comme expliqué ci-dessous:
Exemple 1
Exemple n° 1: Mise à jour de la variable
target.url
par une règle JavaScriptUtilisez une barre oblique (
/
) au lieu d'un point d'interrogation (?
) à l'intérieururl
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: Mise à jour de la variable
target.url
par une règle JavaScript en fonction de la valeur indiquée dans l'en-tête de la requêtevar 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 la requête. en-têtePath
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 variable
target.url
par la règle AffectMessageAjoutez un chemin d'accès valide dans l'élément
<Value>
de la règle AffectMessage. Autrement dit, remplacez le point d'interrogation (?
) par a (/
) dans l'élément<Value>
et Définissez-la surhttps://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
dans l'URL du serveur backend DOIT toujours commencer par une barre oblique (/
) comme suit : spécifications: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 toujours besoin de l'aide de l'assistance Apigee, consultez la section Doit rassembler de diagnostic.
Vous devez collecter 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 de proxy d'API
- Exécutez la commande
curl
utilisée pour reproduire le500 Internal Server Error
avec le code d'erreurprotocol.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 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