500 Erreur interne du serveur - BadPath

<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:

  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 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:

  1. <ph type="x-smartling-placeholder"></ph> Connectez-vous à l'interface utilisateur d'Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.
  2. Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.

  3. Accédez à Analyser > Surveillance des API > Examiner.
  4. Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.
  5. Représentez le code d'erreur par rapport à l'heure.

    <ph type="x-smartling-placeholder">
  6. Sélectionnez une cellule avec le code d'erreur protocol.http.BadPath, comme indiqué ci-dessous:

  7. Les informations sur le code d'erreur protocol.http.BadPath s'affichent sous la forme comme indiqué ci-dessous:

  8. Cliquez sur Afficher les journaux et développez la ligne correspondant à la requête ayant échoué.

  9. 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
  10. Si la source d'erreur est target et que le code d'erreur est protocol.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:

  1. 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
  2. Assurez-vous que l'option Show all FlowInfos (Afficher toutes les infos FlowInfos) est activée:

  3. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
  4. Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
  5. 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:

  6. 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.

  7. 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é).
  8. 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ée JS- SetTargetURL, comme suit: target.url : https://mocktarget.apigee.net?json

  9. 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
  10. Le composant path commence par un point d'interrogation (?). au lieu d'une barre oblique (/), vous obtenez l'erreur Invalid request path
  11. Accédez à la phase AX (Données analytiques enregistrées) dans la trace, puis cliquez dessus.
  12. 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:

  13. Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source comme protocol.http.BadPath et target , 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:

  1. 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.
  2. Vérifiez les journaux d'accès NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    <ph type="x-smartling-placeholder">
  3. Effectuez une recherche pour voir s'il existe des erreurs 500 avec un code d'erreur protocol.http.BadPath pendant une durée spécifique (si le problème est survenu pendant ou si des requêtes échouent toujours avec 500.
  4. Si vous trouvez des erreurs 500 avec la correspondance X-Apigee-fault-code la valeur de protocol.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 et target , 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

  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 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 d'erreur est la valeur target, cela indique que l'URL du serveur backend présente un chemin.
  3. L'URL du serveur backend est représentée par la variable de flux 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.

    <ph type="x-smartling-placeholder">
  4. 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

    1. 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 (/).
    2. 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

    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 d'accès non valide.
    4. 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.

    Journaux

    Utiliser des journaux sur votre 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 <ph type="x-smartling-placeholder"></ph> MessageLogging ou <ph type="x-smartling-placeholder"></ph> ServiceAccroche à votre serveur de journaux.
    2. Si vous disposez des journaux, examinez-les et <ph type="x-smartling-placeholder">
        </ph>
      1. Vérifiez si target.url possède un chemin d'accès non valide et
      2. 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

    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
  5. 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 à jour target.url pour lui attribuer 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 contenir un chemin non valide menant à cette erreur.

    Exemple 1

    Exemple n° 1: Mise à jour de la variable target.url par une 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 dont la valeur https://mocktarget.apigee.net?json est contenue dans une autre variable url.

    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 renvoie 500 Internal Server Error avec le code d'erreur protocol.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ê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 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 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 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 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 renvoie 500 Internal Server Error avec le code d'erreur protocol.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 renvoie 500 Internal Server Error avec un code d'erreur protocol.http.BadPath

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:

  1. 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>
    1. 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 (/).
    2. 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.
    3. 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.
  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: Mise à jour de la variable target.url par une règle JavaScript

    Utilisez une barre oblique (/) au lieu d'un point d'interrogation (?) à l'intérieur 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: 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ê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 la requête. en-tê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 variable target.url par la règle AffectMessage

    Ajoutez 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 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 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 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 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

      :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

    Variables de flux – Cible