500 Interner Serverfehler – BadPath

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 500 Internal Server Error mit dem Fehlercode protocol.http.BadPath als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 500 Internal Server Error

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

Mögliche Ursachen

Dieser Fehler tritt auf, wenn die Anfrage-URL des Backend-Servers, die durch die Ablaufvariable target.url dargestellt wird, einen path enthält, der mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/) beginnt, was ungültig ist.

Gemäß den Spezifikationen RFC 3986, Abschnitt 3: Syntaxkomponenten und RFC 3986, Abschnitt 3.3: Pfad:

1. Die URI-Syntax besteht aus den folgenden Komponenten:

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. Die Komponente path ist erforderlich und MUSS mit einem Schrägstrich (/) beginnen und immer einen Schrägstrich enthalten.

Wenn die Anfrage-URL des Backend-Servers also eine path-Komponente enthält, die mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/) beginnt, antwortet Apigee Edge mit 500 Internal Server Error und dem Fehlercode protocol.http.BadPath.

Beispiel: Wenn target.url den Wert https://www.mocktarget.apigee.net?json hat, tritt dieser Fehler auf, da path als ungültig erkannt wird, weil es mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/) beginnt.

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Verfahren, um diesen Fehler zu diagnostizieren:

Ursache: Die Back-End-Server-URL (target.url) hat einen ungültigen Pfad.

Diagnose

1. Ermitteln Sie den Fehlercode und die Fehlerquelle für 500 Internal Server Error mithilfe von API Monitoring, Trace Tool oder NGINX-Zugriffsprotokollen, wie in Häufige Diagnoseschritte beschrieben.
2. Wenn der Fault Code (Fehlercode) protocol.http.BadPath und die Fault Source (Fehlerquelle) den Wert target hat, bedeutet das, dass die Backend-Server-URL einen ungültigen Pfad hat.

3. Die URL des Backend-Servers wird in Apigee Edge durch die Ablaufvariable target.url dargestellt. Dieser Fehler tritt in der Regel auf, wenn Sie versuchen, die Backend-Server-URL (target.url) dynamisch mit einer der Richtlinien (im Proxy-/freigegebenen Ablauf) im Zielanfrageablauf zu aktualisieren, sodass sie einen ungültigen Pfad hat.

4. Ermitteln Sie mit einer der folgenden Methoden, ob die Ablaufvariable target.url tatsächlich einen ungültigen Pfad und die Quelle für ihren Wert hat:

   Trace

   Trace-Tool verwenden

   Wenn Sie einen Trace für diesen Fehler erfasst haben, folgen Sie der Anleitung unter Trace-Tool verwenden .

   1. Prüfen Sie, ob target.url einen ungültigen Pfad hat, d. h., ob er mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/) beginnt.

   2. Wenn ja, suchen Sie nach der Richtlinie, mit der der Wert von target.url so geändert oder aktualisiert wurde, dass er einen ungültigen Pfad enthält.

      Beispiel-Trace, in dem die Ablaufvariable target.url durch die JavaScript-Richtlinie aktualisiert wurde

      
   3. Im obigen Beispiel-Trace sehen Sie, dass die JavaScript-Richtlinie den Wert von target.url geändert oder aktualisiert hat, sodass er einen ungültigen Pfad enthält.
   4. target.url hat die folgenden Komponenten:
      • Schema:https
      • authority: mocktarget.apigee.net
      • Pfad: ?json

      Der Pfad beginnt mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/). Daher ist er ungültig.

   Logs

   Logs auf Ihrem Log-Server verwenden

   1. Wenn Sie keinen Trace für diesen Fehler haben (ein zeitweiliges Problem), prüfen Sie, ob Sie die Informationen zum Wert der Ablaufvariablen target.url mit Richtlinien wie MessageLogging oder ServiceCallout auf Ihrem Logserver protokolliert haben.
   2. Wenn Sie die Logs haben, sehen Sie sie sich an und
      1. Prüfen Sie, ob target.url einen ungültigen Pfad hat.
      2. Ermitteln Sie, durch welche Richtlinie target.url so geändert wurde, dass der Pfad ungültig ist.

   API-Proxy

   Fehlerhaften API-Proxy prüfen

   Wenn Sie keinen Trace oder keine Logs für diesen Fehler haben, prüfen Sie den fehlerhaften API-Proxy, um festzustellen, wodurch die Ablaufvariable target.url so geändert oder aktualisiert wurde, dass sie einen ungültigen Pfad enthält. Dann machen Sie Folgendes:

   • Die Richtlinie im API-Proxy
   • Alle freigegebenen Abläufe, die vom Proxy aufgerufen werden

5. Sehen Sie sich die spezifische Richtlinie (z. B. AssignMessage oder JavaScript) an, die die Ablaufvariable target.url ändert oder aktualisiert, und ermitteln Sie die Ursache für die Aktualisierung von target.url mit einem ungültigen Pfad.

   Hier sind einige Beispielrichtlinien, die die Ablaufvariable target.url falsch aktualisieren, sodass sie einen ungültigen Pfad enthält, der zu diesem Fehler führt.

   Beispiel 1

   Beispiel 1: Aktualisieren der target.url-Variablen in der JavaScript-Richtlinie

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

   Im obigen Beispiel wird die Ablaufvariable target.url mit dem Wert https://mocktarget.apigee.net?json aktualisiert, der in einer anderen Variablen url. enthalten ist.

   Der Wert von url hat die folgenden Komponenten:

   • Schema:https
   • authority: mocktarget.apigee.net
   • Pfad: ?json

   Der Pfad beginnt mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/), was ungültig ist. Daher gibt Apigee Edge 500 Internal Server Error mit dem Fehlercode protocol.http.BadPath zurück.

   Beispiel 2

   Beispiel 2: JavaScript-Richtlinie, die die Variable target.url basierend auf dem Wert im Anfrageheader aktualisiert

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   Im obigen Beispiel wird die Ablaufvariable target.url aktualisiert, indem der Wert https://mocktarget.apigee.net, der in einer Variablen url enthalten ist, mit dem Wert einer anderen Variablen path verkettet wird, dessen Wert aus request.header.Path. abgerufen wird.

   Wenn Sie Zugriff auf die tatsächliche Anfrage oder den Trace haben, können Sie den tatsächlichen Wert prüfen, der an request.header.Path übergeben wurde.

   Beispielanfrage des Nutzers

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   In diesem Beispiel wird der Headerpfad nicht als Teil der Anfrage gesendet. Daher ist der Wert der Variablen path in der JavaScript-Richtlinie null.

   Das bedeutet:

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

   Der Wert von target.url hat die folgenden Komponenten:

   • Schema:https
   • authority: mocktarget.apigee.net
   • Pfad: ?user

   Der Pfad beginnt mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/), was ungültig ist. Daher gibt Apigee Edge 500 Internal Server Error mit dem Fehlercode protocol.http.BadPath zurück.

   Beispiel 3

   Beispiel 3: target.url-Variable mit AssignMessage-Richtlinie aktualisieren

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

   Der Wert von url hat die folgenden Komponenten:

   • Schema:https
   • authority: mocktarget.apigee.net
   • Pfad: ?echo

   Auch in diesem Beispiel beginnt der Pfad mit einem Fragezeichen (?) anstelle eines Schrägstrichs (/), was ungültig ist. Daher gibt Apigee Edge 500 Internal Server Error mit dem Fehlercode protocol.http.BadPath zurück.

Auflösung

Gemäß der URL-Spezifikation RFC 3986, Abschnitt 3: Syntaxkomponenten ist die Komponente path erforderlich und muss immer mit "/" beginnen. Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:

1. Achten Sie darauf, dass die Backend-Server-URL, die durch die Ablaufvariable target.url dargestellt wird, immer einen gültigen Pfad hat und immer mit einem Schrägstrich (/) beginnt.
   1. In einigen Fällen ist im Pfad kein Ressourcenname enthalten. Achten Sie dann darauf, dass der Pfad mindestens einen Schrägstrich (/) enthält.
   2. Wenn Sie andere Variablen verwenden, um den Wert der Ablaufvariablen target.url zu bestimmen, achten Sie darauf, dass diese Variablen keinen ungültigen Pfad haben.
   3. Wenn Sie String-Operationen ausführen, um den Wert der Ablaufvariablen target.url zu ermitteln, achten Sie darauf, dass das Ergebnis der String-Operationen keinen ungültigen Pfad hat.

2. In den oben besprochenen Beispielen können Sie dieses Problem so beheben:

   Beispiel 1

   Beispiel 1: Aktualisieren der target.url-Variablen in der JavaScript-Richtlinie

   Verwenden Sie in der Variablen url einen Schrägstrich (/) anstelle eines Fragezeichens (?), um dieses Problem zu beheben. Beispiel:

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

   Beispiel 2

   Beispiel 2: JavaScript-Richtlinie, die die Variable target.url basierend auf dem Wert im Anfrageheader aktualisiert

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   Achten Sie darauf, dass Sie einen gültigen Pfad übergeben, z. B. /user, als Teil des Anfrageheaders Path, um dieses Problem zu beheben, wie unten dargestellt:

   Beispielanfrage:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   Beispiel 3

   Beispiel 3: AssignMessage-Richtlinie, die die Variable target.url aktualisiert

   Fügen Sie im Element <Value> der AssignMessage-Richtlinie einen gültigen Pfad hinzu. Ersetzen Sie dazu das Fragezeichen (?) durch einen Schrägstrich (/) im Element <Value> und legen Sie es auf https://mocktarget.apigee.net/echo fest, um das Problem zu beheben.

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

   Spezifikation

   Apigee Edge erwartet, dass die path -Komponente in der Backend-Server-URL immer mit einem Schrägstrich (/) beginnt, wie in den folgenden Spezifikationen beschrieben:

   Spezifikation
   RFC 3986, Abschnitt 3: Syntaxkomponenten
   RFC 3986, Abschnitt 3.3: Pfad

   Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

   Erfassen von Diagnoseinformationen erforderlich

   Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

   Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

   • Name der Organisation
   • Name der Umgebung
   • Name des API-Proxys
   • Vollständiger curl-Befehl, der zum Reproduzieren des 500 Internal Server Error mit dem Fehlercode protocol.http.BadPath verwendet wurde
   • Trace-Datei für die API-Anfragen

   Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

   • Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
   • Name der Umgebung
   • API-Proxy-Bundle
   • Trace-Datei für die API-Anfragen

   • NGINX-Zugriffslogs:

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

     Dabei gilt:ORG, ENV und PORT# werden durch tatsächliche Werte ersetzt.

   • Systemprotokolle des Message Processors /opt/apigee/var/log/edge-message- processor/logs/system.log

   Verweise

   Ablaufvariablen – Ziel