Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
Symptom
Die Clientanwendung erhält als Antwort auf API-Aufrufe den HTTP-Statuscode 400 Bad Request
mit dem Fehlercode protocol.http.DuplicateHeader
.
Fehlermeldung
Die Clientanwendung ruft den folgenden Antwortcode ab:
HTTP/1.1 400 Bad Request
Außerdem wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:
{ "fault":{ "faultstring":"Duplicate Header \"Expires\"", "detail":{ "errorcode":"protocol.http.DuplicateHeader" } } }
Mögliche Ursachen
Dieser Fehler tritt auf, wenn ein bestimmter HTTP-Header, für den in Apigee Edge keine Duplikate zulässig sind, mehr als einmal mit denselben oder unterschiedlichen Werten als Teil der HTTP-Anfrage angezeigt werden, die vom Client an Apigee Edge gesendet wird.
Gemäß
RFC 7230, Abschnitt 3.2.2: Feldreihenfolge Dürfen Absender in einer Nachricht NICHT mehrere Headerfelder mit demselben Feldnamen generieren, es sei denn, der gesamte Feldwert für dieses Headerfeld ist als durch Kommas getrennte Liste definiert, z.B. #(values)] oder das Header-Feld eine bekannte Ausnahme. Wenn Apigee Edge einen bestimmten Header, der keine Duplikate haben darf, mehr als einmal in der vom Client gesendeten HTTP-Anfrage findet, antwortet er mit 400 Bad Request
und dem Fehlercode protocol.http.DuplicateHeader
.
Mögliche Ursachen für diesen Fehler:
Ursache | Beschreibung | Anleitungen zur Fehlerbehebung gelten für |
---|---|---|
Doppelte Überschrift in Anfrage | Die HTTP-Anfrage von der Clientanwendung an Apigee enthält doppelte Header. | Nutzer von Edge Public und Private Cloud |
Allgemeine Diagnoseschritte
Verwenden Sie eines der folgenden Tools oder Methoden, um diesen Fehler zu diagnostizieren:
API-Monitoring
So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:
- Melden Sie sich in der Apigee Edge-UI als Nutzer mit einer entsprechenden Rolle an.
Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.
- Rufen Sie die Seite Analysieren > API-Überwachung > Untersuchen auf.
- Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
- Achten Sie darauf, dass der Proxyfilter auf Alle festgelegt ist.
- Stellen Sie den Fehlercode der Zeit gegenüber.
Wählen Sie eine Zelle mit dem Fehlercode
protocol.http.DuplicateHeader
aus, wie unten dargestellt:Informationen zum Fehlercode
protocol.http.DuplicateHeader
werden wie unten dargestellt angezeigt:- Klicken Sie auf Logs ansehen und maximieren Sie die Zeile für die fehlgeschlagene Anfrage.
- Notieren Sie sich im Fenster Logs die folgenden Details:
- Statuscode:
400
- Fehlerquelle:
apigee
- Fehlercode:
protocol.http.DuplicateHeader
.
- Statuscode:
- Wenn die Fehlerquelle den Wert
apigee
oderMP
und der Fehlercode den Wertprotocol.http.DuplicateHeader
hat, bedeutet das, dass die HTTP-Anfrage vom Client doppelte Header enthielt.
Trace-Tool
NGINX
So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs die wichtigsten Informationen zu HTTP-
400
-Fehlern ermitteln. Prüfen Sie die NGINX-Zugriffslogs:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Hierbei gilt: ORG, ENV und PORT# werden durch tatsächliche Werte ersetzt.
- Prüfen Sie, ob während eines bestimmten Zeitraums
400
-Fehler aufgetreten sind (ob das Problem in der Vergangenheit aufgetreten ist) oder ob Anfragen mit400
immer noch fehlschlagen. Wenn Sie
400
-Fehler mit dem X-Apigee-fault-code finden, der mit dem Wert von X-Apigee-fault-code übereinstimmt, ermitteln Sie den Wert von X-Apigee-fault-code.Beispiel für einen 400-Fehler aus dem NGINX-Zugriffslog:
Der obige Beispieleintrag aus dem NGINX Access-Log enthält die folgenden Werte für X-Apigee-Fehlercode und X-Apigee-Fehler-Quelle:
Antwortheader Wert X-Apigee-fault-code protocol.http.DuplicateHeader
X-Apigee-fault-source MP
Ursache: Doppelter Header in Anfrage
Diagnose
- Bestimmen Sie den Fehlercode und die Fehlerquelle für den beobachteten Fehler mithilfe von API-Monitoring oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte erläutert.
- Wenn die Fehlerquelle den Wert
apigee
oderMP
hat, weist dies darauf hin, dass die von der Clientanwendung an Apigee gesendete Anfrage doppelte Header enthält. Sie können den tatsächlichen Header, der mehr als einmal als Teil der Anfrage gesendet wird, mit einer der folgenden Methoden ermitteln:
Fehlermeldung
Fehlermeldung
Wenn Sie Zugriff auf die vollständige Fehlermeldung von Apigee Edge haben, lesen Sie die
faultstring
.faultstring
enthält den Headernamen, der mehrmals gesendet wurde.Beispiel für eine Fehlermeldung:
"faultstring":"Duplicate Header \"Expires\""
- In der obigen Fehlermeldung sehen Sie, dass der Header
Expires
mehr als einmal gesendet wird, wie infaultstring
zu sehen.
Tatsächliche Anfrage
Tatsächliche Anfrage verwenden
Wenn Sie Zugriff auf die eigentliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:
- Überprüfen Sie die Liste der Header, die in der Anfrage übergeben wurden.
- Wenn Sie feststellen, dass ein bestimmter Header mehr als einmal in der Anfrage mit demselben Wert oder unterschiedlichen Werten vorkommt, ist dies die Ursache für den Fehler.
Beispielanfrage:
curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
In der obigen Beispielanfrage wird der Header
Expires
mehrmals gesendet. Daher schlägt diese Anfrage mit dem Fehler400 Bad Request
und dem Fehlercodeprotocol.http.DuplicateHeader
fehl.- Wenn Sie Zugriff auf die Clientlogs haben, können Sie alternativ sehen, ob Sie Informationen über die tatsächliche Anfrage an Apigee Edge haben, und den Header ermitteln, der mehr als einmal gesendet wird.
Auflösung
Probleme mit Duplikaten beheben
Option 1 [empfohlene Option] Clientanwendung korrigieren, sodass sie keine doppelten Header enthält
- Analysieren Sie den Grund dafür, dass der jeweilige Client einen doppelten Header sendet. Beispiel:
Expires
im obigen Fall. Überprüfen Sie, ob die API-Proxys den doppelten Header akzeptieren können. Dies ist gemäß der HTTP-Spezifikation RFC7230 in der Regel nicht empfehlenswert. - Ist dies nicht wünschenswert, ändern Sie Ihre Clientanwendung so, dass keine doppelten Header gesendet werden.
Im oben beschriebenen Beispiel wird festgestellt, dass der Header
Expires
zweimal mit demselben Wert gesendet wird, was nicht wünschenswert ist. Sie können das Problem beheben, indem Sie den HeaderExpires
wie unten gezeigt nur einmal übergeben:curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
- Wenn dies sinnvoll ist und Sie die doppelten Header zulassen möchten, fahren Sie mit Option 2 – CwC-Attribut verwenden fort.
CwC
Option 2: „CwC“-Property verwenden
Apigee bietet das Attribut
CwC HTTPHeader.<HeaderName>
,mit dem Clientanwendungen und Zielserver doppelte Header an API-Proxys in Apigee Edge senden können.
CwC-Property | Werte |
---|---|
HTTPHeader.<HeaderName> |
allowDuplicates,multivalued |
Die folgende Eigenschaft kann beispielsweise für die Message Processors festgelegt werden, um Duplikate und mehrere Werte für den Header Expires
zuzulassen.
HTTPHeader.Expires=allowDuplicates, multiValued
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie das Attribut konfigurieren, um zu verhindern, dass Apigee Edge den Fehler
400 Bad Request
ausgibt, auch wenn die Anfrage doppelte Header enthält. Verwenden Sie dazu die Anleitung Nachrichtenprozessoren für die Verwendung doppelter Header konfigurieren. - Wenn Sie ein Nutzer der öffentlichen Cloud sind, wenden Sie sich an den Apigee Edge-Support, um dieses Attribut für Ihre Organisation zu konfigurieren.
Spezifikation
Apigee erwartet, dass die Clientanwendung gemäß den folgenden RFC-Spezifikationen keine doppelten Header als Teil der Anfrage sendet:
Spezifikation |
---|
RFC 7230, Abschnitt 3.2.2: Feldreihenfolge |
RFC 7230, Abschnitt 3.2 Headerfelder |
Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie Diagnoseinformationen müssen erfasst werden.
Erfassen von Diagnoseinformationen erforderlich
Erfassen Sie die folgenden Diagnoseinformationen und wenden Sie sich 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
- Führen Sie den Befehl
curl
aus, mit dem der Fehler400
reproduziert wurde - Ablaufverfolgungsdatei für die API-Anfragen
Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
- Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
- Name der Umgebung
- API-Proxy-Bundle
- Führen Sie den Befehl
curl
aus, mit dem Sie den Fehler400
reproduziert haben. - Ablaufverfolgungsdatei für die API-Anfragen
NGINX-Zugriffslogs:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Hierbei gilt: ORG, ENV und PORT# werden durch tatsächliche Werte ersetzt.
- Systemprotokolle von Message Processor
/opt/apigee/var/log/edge-message-processor/logs/system.log