<ph type="x-smartling-placeholder"></ph>
Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur
Apigee X-Dokumentation. Weitere Informationen
Symptom
Die Clientanwendung ruft den HTTP-Statuscode 500 Internal Server Error
mit
Fehlercode protocol.http.EmptyPath
als Antwort für API-Aufrufe.
Fehlermeldung
Die Clientanwendung ruft den folgenden Antwortcode ab:
HTTP/1.1 500 Internal Server Error
Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:
{ "fault":{ "faultstring":"Request path cannot be empty", "detail":{ "errorcode":"protocol.http.EmptyPath" } } }
Mögliche Ursachen
Dieser Fehler tritt auf, wenn die Anfrage-URL des Back-End-Servers, dargestellt durch die Flussvariable
<ph type="x-smartling-placeholder"></ph>
target.url
enthält einen leeren Pfad.
Gemäß den Spezifikationen <ph type="x-smartling-placeholder"></ph> RFC 3986, Abschnitt 3: Syntaxkomponenten und <ph type="x-smartling-placeholder"></ph> RFC 3986, Abschnitt 3.3: Pfad:
Die URI-Syntax besteht aus folgenden Komponenten:
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment
- Die Komponente
path
ist erforderlich und MUSS immer einen Schrägstrich enthalten. (/
), auch wenn keine anderen Zeichen im Pfad vorhanden sind.
Wenn also die Anfrage-URL des Back-End-Servers den Parameter path
nicht enthält,
Komponente, d. h. sie hat keinen Schrägstrich (/
), dann ist Apigee
Edge antwortet mit 500 Internal Server Error
und Fehlercode
protocol.http.EmptyPath
.
Beispiel: target.url
hat den Wert
https://www.mocktarget.apigee.net
enthält, tritt dieser Fehler
path
Komponente ist leer oder fehlt.
Ursache | Beschreibung | Anleitungen zur Fehlerbehebung gelten für |
---|---|---|
Backend-Server-URL (target.url) enthält einen leeren Pfad | Die Backend-Server-URL, die durch die Flussvariable target.url dargestellt wird, hat einen leeren Pfad. |
Edge-Nutzer von öffentlichen und privaten Clouds |
Allgemeine Diagnoseschritte
Verwenden Sie eines der folgenden Tools oder Techniken, um diesen Fehler zu diagnostizieren:
API-Monitoring
Verfahren 1: API-Monitoring verwenden
<ph type="x-smartling-placeholder">So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:
- <ph type="x-smartling-placeholder"></ph> Melden Sie sich in der Apigee Edge-Benutzeroberfläche als Nutzer mit einem entsprechende Rolle.
Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.
- Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
- Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.
<ph type="x-smartling-placeholder">Wählen Sie eine Zelle mit dem Fehlercode
protocol.http.EmptyPath
aus, wie unten gezeigt:Informationen über den Fehlercode
protocol.http.EmptyPath
werden angezeigt als (siehe unten):Klicken Sie auf Logs ansehen , um die Zeile für die fehlgeschlagene Anfrage zu maximieren.
- Im Fenster Logs werden die folgenden Details angezeigt:
<ph type="x-smartling-placeholder">
- </ph>
- Statuscode:
500
- Fehlerquelle:
target
- Fehlercode:
protocol.http.EmptyPath
- Statuscode:
- Wenn die Fehlerquelle
target
und der Fehlercodeprotocol.http.EmptyPath
, dann bedeutet dies, dass die Backend-Server-URL ein Leerer Pfad.
Trace
Verfahren 2: Trace-Tool verwenden
<ph type="x-smartling-placeholder">So diagnostizieren Sie den Fehler mit dem Trace-Tool:
- Aktivieren Sie die Trace-Sitzung und entweder
<ph type="x-smartling-placeholder">
- </ph>
- Warten Sie, bis der Fehler
500 Internal Server Error
auftritt, oder - Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus, um es zu reproduzieren.
500 Internal Server Error
- Warten Sie, bis der Fehler
Achten Sie darauf, dass Show all FlowInfos (Alle FlowInfos anzeigen) aktiviert ist:
- Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
- Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.
Sie finden den Fehler in der Regel in einem Ablauf nach dem Start von Zielanfragefluss. wie unten dargestellt:
Notieren Sie sich den Wert des Fehlers aus dem Trace.
Fehler: Anfragepfad darf nicht leer sein
Da der Fehler von Apigee Edge nach der Phase Zielanfragefluss gestartet ausgegeben wird, gibt sie an, dass das
path
in der Back-End-Server-URL leer ist. Dies würde ist am wahrscheinlichsten, wenn die Flussvariabletarget.url
(die die URL für Backend-Server ) möglicherweise mit einem leeren Pfad über eine der Richtlinien im Anfrageablauf.- Sehen Sie sich den Abschnitt Gelesene und zugewiesene Variablen in jedem der Abläufe rückwärts vom Zielanfragefluss gestartet an.
Legen Sie die Richtlinie fest, in der die Flussvariable
target.url
aktualisiert wird.Beispiel-Trace, das die JavaScript-Richtlinie zeigt, hat die Flussvariable
target.url
aktualisiert:Notieren Sie sich im oben gezeigten Beispiel-Trace den Wert der Flussvariablenvariablen.
target.url
wird in einer JavaScript-Richtlinie namens SetTargetURL als folgt:target.url : https://mocktarget.apigee.net
target.url
hat die folgenden Komponenten: <ph type="x-smartling-placeholder">- </ph>
- scheme:
https://mocktarget.apigee.net
- path:leer
- scheme:
- Daher wird der Fehler
Request path cannot be empty
angezeigt. - Navigieren Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.
Scrollen Sie nach unten zum Abschnitt Phase Details - Error Headers (Phase-Details – Fehlerheader) und legen Sie fest, für X-Apigee-fault-code und X-Apigee-fault-code, wie unten gezeigt:
- Sie sehen die Werte X-Apigee-fault-code und X-Apigee-fault-code als
protocol.http.EmptyPath
bzw.target
, was bedeutet, dass Dieser Fehler wird verursacht, weil der Pfad für die Backend-Server-URL leer ist.Antwortheader Wert X-Apigee-fault-code protocol.http.EmptyPath
X-Apigee-fault-source target
NGINX
Verfahren 3: NGINX-Zugriffslogs verwenden
<ph type="x-smartling-placeholder">So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs ermitteln,
die wichtigsten Informationen zu HTTP
500 Internal Server Error
. Prüfen Sie die NGINX-Zugriffslogs:
<ph type="x-smartling-placeholder">/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Nach
500
-Fehlern mit Fehlercode suchenprotocol.http.EmptyPath
während eines bestimmten Zeitraums (wenn das Problem in in der Vergangenheit) oder Anfragen mit500
fehlschlagen. Wenn Sie
500
-Fehler mit dem X-Apigee-fault-code finden den Wert vonprotocol.http.EmptyPath
und dann den Wert des X-Apigee-fault-source.Beispiel für den Fehler 500 aus dem NGINX-Zugriffsprotokoll:
Der obige Beispieleintrag aus dem NGINX-Zugriffsprotokoll enthält die folgenden Werte für X- Apigee-Fehlercode und X-Apigee-Fehler-Quelle:
Header Wert X-Apigee-fault-code protocol.http.EmptyPath
X-Apigee-fault-source target
Beachten Sie, dass die Werte von X-Apigee-fault-code und X-Apigee-fault-code folgende sind:
protocol.http.EmptyPath
bzw.target
, was bedeutet, dass Dieser Fehler wird verursacht, weil die Back-End-Server-URL einen leeren Pfad hat.
Ursache: Backend-Server-URL (target.url) hat einen leeren Pfad
Diagnose
- Ermitteln Sie den Fehlercode und die Fehlerquelle für
500 Internal Server Error
mithilfe des API-Monitorings, des Trace-Tools oder der NGINX-Zugriffslogs wie unter Häufige Diagnoseschritte. - Wenn der Fehlercode
protocol.http.EmptyPath
ist und Fehlerquelletarget
gesetzt ist, zeigt dies an, dass die Back-End-Server-URL ein leeres Pfad. Die Backend-Server-URL wird durch die Flussvariable
<ph type="x-smartling-placeholder">target.url
in Apigee dargestellt. Edge Dieser Fehler tritt normalerweise auf, wenn Sie versuchen, die Backend-Server-URL zu aktualisieren, d. h.target.url
dynamisch unter Verwendung einer der Richtlinien (innerhalb Proxy/freigegebener Ablauf) im Ziel-Anfrageablauf, sodass dort ein leerer Pfad vorhanden ist.- Stellen Sie fest, ob die Flussvariable
target.url
tatsächlich einen leeren Pfad hat und der Wert Quelle für seinen Wert mithilfe eines der folgenden Schritte:Trace
Trace-Tool verwenden
Wenn Sie einen Trace für diesen Fehler erfasst haben, verwenden Sie die Schritte wie unter Mit dem Trace-Tool und:
- Prüfen Sie, ob
target.url
einen leeren Pfad hat. Falls ja, sehen Sie nach, durch welche Richtlinie der Wert
target.url
, um einen leeren Pfad zu enthalten.Beispiel-Trace, das die JavaScript-Richtlinie zeigt, die Flussvariable aktualisiert hat
target.url:
.- Beachten Sie im obigen Beispiel-Trace, dass die JavaScript-Richtlinie geändert oder
hat den Wert von
target.url
aktualisiert, sodass er einen leeren Pfad enthält. target.url
hat die folgenden Komponenten: <ph type="x-smartling-placeholder">- </ph>
- scheme:
https://mocktarget.apigee.net
- path:leer
- scheme:
Logs
Logs auf Ihrem Logserver verwenden
- Wenn Sie keine Ablaufverfolgung für diesen Fehler haben (ein vorübergehendes Problem), gehen Sie folgendermaßen vor:
prüfen, ob Sie die Informationen zum Wert einer Flussvariablen protokolliert haben
target.url
, unter Verwendung von Richtlinien wie <ph type="x-smartling-placeholder"></ph> MessageLogging oder <ph type="x-smartling-placeholder"></ph> ServiceCallout mit Ihrem Logserver verbinden. - Wenn Sie die Logs haben, prüfen Sie sie und gehen Sie so vor:
<ph type="x-smartling-placeholder">
- </ph>
- Prüfen Sie, ob
target.url
einen leeren Pfad hat. - Prüfen Sie, ob Sie feststellen können, welche Richtlinie
target.url
geändert hat einen leeren Pfad enthalten
- Prüfen Sie, ob
API-Proxy
Fehlerhaften API-Proxy prüfen
Wenn Sie weder ein Trace noch Protokolle für diesen Fehler haben, prüfen Sie die fehlerhafte API Proxy, um zu bestimmen, was die Flussvariable
target.url
geändert oder aktualisiert hat enthält einen ungültigen Pfad. Dann machen Sie Folgendes:- Richtlinie im API-Proxy
- Alle freigegebenen Abläufe, die vom Proxy aufgerufen werden
- Prüfen Sie, ob
Sehen Sie sich die Richtlinie an, z. B. „AssignMessage“ oder „JavaScript“, die oder aktualisiert die Flussvariable
target.url
sorgfältig und ermittelt den Grund für die Aktualisierungtarget.url
, um einen leeren Pfad zu haben.Hier sind einige Beispielrichtlinien, die die Flussvariable
target.url
aktualisieren fälschlicherweise einen leeren Pfad enthalten, der zu diesem Fehler führt.Beispiel 1
Beispiel 1: JavaScript-Richtlinie zur Aktualisierung der Variable „
target.url
“var url = "https://mocktarget.apigee.net" context.setVariable("target.url", url);
Beachten Sie im obigen Beispiel, dass die Flussvariable
target.url
aktualisiert wird wobei der Werthttps://mocktarget.apigee.net
in einer anderen Variablen enthalten isturl
target.url
hat die folgenden Komponenten:- scheme:
https://mocktarget.apigee.net
- path:leer
Da der Pfad leer ist, gibt Apigee Edge
500 Internal Server Error
mit Fehlercodeprotocol.http.EmptyPath
.Beispiel 2
Beispiel 2: JavaScript-Richtlinie zur Aktualisierung der Variable „
target.url
“var path = context.getVariable("request.header.Path"); var url = "https://mocktarget.apigee.net" + path context.setVariable("target.url", url);
Beachten Sie im obigen Beispiel, dass die Flussvariable
target.url
durch Werthttps://mocktarget.apigee.net
in einer Variablen verkettenurl
und den Wert einer weiteren Variablenpath
, deren Der Wert wird ausrequest.header.Path.
abgerufenWenn Sie Zugriff auf die eigentliche Anfrage oder den Trace haben, können Sie den tatsächlichen Wert an
request.header.Path
übergeben.Beispielanfrage des Nutzers:
curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token>
In diesem Beispiel wird der Header-Pfad nicht als Teil der Anfrage gesendet. Daher ist der Wert des Variablenpfads in der JavaScript-Richtlinie lautet
null
.Das bedeutet:
url = https://mocktarget.apigee.net + path
url = https://mocktarget.apigee.net + null
target.url = https://mocktarget.apigee.netnull
target.url
hat die folgenden Komponenten:- scheme:
https://mocktarget.apigee.netnull
- path:leer
Beispiel 3
Beispiel 3: AssignMessage-Richtlinie aktualisiert
target.url
-Variable über andere Variable<AssignMessage async="false" continueOnError="false" enabled="true" name=">AM-SetTargetURL"> <DisplayName>AM-SetTargetURL</DisplayName> <AssignVariable> <Name>target.url</Name> <Value>https://mocktarget.apigee.net</Value> </AssignVariable> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
target.url
hat die folgenden Komponenten:- scheme:
https://mocktarget.apigee.net
- path:leer
In allen obigen Beispielen ist der Pfad in der Back-End-Server-URL, also
target.url
ist leer, daher gibt Apigee Edge Folgendes zurück:500 Internal Server Error
mit Fehlercodeprotocol.http.EmptyPath
.- scheme:
Auflösung
Gemäß Spezifikation
<ph type="x-smartling-placeholder"></ph>
RFC 3986, Abschnitt 2: Syntaxkomponenten, ist die path
-Komponente
erforderlich und MUSS immer einen Schrägstrich (/) enthalten, auch wenn kein
andere Zeichen als Teil des path
. Führen Sie die folgenden Schritte aus, um
dieses Problem beheben:
- Achten Sie darauf, dass die Back-End-Server-URL, dargestellt durch die Flussvariable
target.url
hat immer einen nicht leeren Pfad.- In einigen Fällen enthält der Pfad möglicherweise keinen Ressourcennamen. Prüfen Sie dann, ob der Pfad korrekt ist.
mindestens einen Schrägstrich (
/
) enthält. - Wenn Sie andere Variablen verwenden, um den Wert der Flussvariablen zu bestimmen
target.url
. Achten Sie dann darauf, dass der Pfad für andere Variablen nicht leer ist. - Wenn Sie Zeichenfolgenvorgänge ausführen, um den Wert der Flussvariablen zu bestimmen
target.url
. Prüfen Sie dann, ob das Ergebnis oder Ergebnis des Strings hat keinen leeren Pfad.
- In einigen Fällen enthält der Pfad möglicherweise keinen Ressourcennamen. Prüfen Sie dann, ob der Pfad korrekt ist.
mindestens einen Schrägstrich (
- In den Beispielen, die im Abschnitt Diagnose behandelt werden, können Sie dieses Problem folgendermaßen beheben:
wie im Folgenden beschrieben:
Beispiel 1
Beispiel 1: JavaScript-Richtlinie zur Aktualisierung der Variable „
target.url
“Fügen Sie der Variablen
url
einen Schrägstrich (/
) hinzu, um dieses Problem zu beheben wie unten dargestellt:var url = "https://mocktarget.apigee.net/" context.setVariable("target.url", url);
Beispiel 2
Beispiel 2: JavaScript-Richtlinie zur Aktualisierung der Variable „
target.url
“var path = context.getVariable("request.header.Path"); var url = "https://mocktarget.apigee.net" + path context.setVariable("target.url", url);
Sie müssen einen gültigen Pfad übergeben, z. B.
/iloveapis
als Teil des AnfrageheaderPath
, um dieses Problem zu beheben (siehe unten):Beispielanfrage:
curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /iloveapis"
Beispiel 3
Beispiel 3: AssignMessage-Richtlinie aktualisiert die Variable
target.url
über andere VariableFügen Sie im
<Value>
-Element derAssignMessage-Richtlinie einen gültigen Pfad hinzu. Für können Sie z. B./json
als Pfad für MockTarget API verwenden. Ändern Sie also das Element<Value>
inhttps://mocktarget.apigee.net/json
, wie unten gezeigt:<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL"> <DisplayName>AM-SetTargetURL</DisplayName> <AssignVariable> <Name>target.url</Name> <Value>https://mocktarget.apigee.net/json</Value> </AssignVariable> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
Spezifikation
Apigee Edge erwartet, dass die Back-End-Server-URL keinen leeren Pfad hat, wie pro die folgenden Spezifikationen:
Spezifikation |
---|
<ph type="x-smartling-placeholder"></ph> RFC 3986, Abschnitt 3: Syntaxkomponenten |
<ph type="x-smartling-placeholder"></ph> RFC 3986, Abschnitt 3.3: Pfad |
Wenn Sie weitere Unterstützung vom Apigee-Support benötigen, gehen Sie zu Diagnoseinformationen müssen erfasst werden.
Diagnoseinformationen müssen erfasst werden
Wenn das Problem trotz Befolgung der obigen Anleitung weiterhin besteht, stellen Sie Folgendes zusammen: 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
- API-Proxy-Name
- Vollständiger
curl
-Befehl zum Reproduzieren von500 Internal Server Error
mit dem Fehlercodeprotocol.http.EmptyPath
- Ablaufverfolgungsdatei für API-Anfragen
Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
- Vollständige Fehlermeldung für fehlgeschlagene Anfragen
- Name der Umgebung
- API-Proxy-Bundle
- Ablaufverfolgungsdatei für API-Anfragen
NGINX-Zugriffslogs:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Wo:ORG, ENV und PORT# werden ersetzt durch tatsächliche Werte.
- Systemprotokolle des Message Processor
/opt/apigee/var/log/edge-message- processor/logs/system.log