<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 400 Bad Request
mit Fehlercode ab
protocol.http.DuplicateHeader
als Antwort auf API-Aufrufe an.
Fehlermeldung
Die Clientanwendung ruft den folgenden Antwortcode ab:
HTTP/1.1 400 Bad Request
Außerdem kann eine Fehlermeldung wie die folgende angezeigt werden:
{ "fault":{ "faultstring":"Duplicate Header \"Expires\"", "detail":{ "errorcode":"protocol.http.DuplicateHeader" } } }
Mögliche Ursachen
Dieser Fehler tritt auf, wenn ein bestimmter HTTP-Header, der in Apigee keine Duplikate enthalten darf, Edge, erscheint mehr als einmal mit denselben oder unterschiedlichen Werten als Teil der HTTP-Anfrage, die von den Client an Apigee Edge.
Gemäß
RFC 7230, Abschnitt 3.2.2: Feldreihenfolge. Ein Absender DARF KEINE Mehrfach-Header generieren.
Felder mit demselben Feldnamen in einer Nachricht, es sei denn, der gesamte Feldwert
Header-Feld ist als eine durch Kommas getrennte Liste definiert [d.h. #(values)] oder das Header-Feld ein
bekannte Ausnahme sein. Wenn Apigee Edge einen bestimmten Header findet, ist dieser
Duplikate vorhanden sind, mehr als einmal in der HTTP-Anfrage , die vom Client gesendet wird,
antwortet mit 400 Bad Request
und 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. | Edge-Nutzer von öffentlichen und privaten Clouds |
Allgemeine Diagnoseschritte
Verwenden Sie eines der folgenden Tools oder Techniken, um diesen Fehler zu diagnostizieren:
API-Monitoring
<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 Benutzer 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.
- Achten Sie darauf, dass der Proxy-Filter auf Alle gesetzt ist. <ph type="x-smartling-placeholder">
- Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.
Wähle eine Zelle mit dem Fehlercode
protocol.http.DuplicateHeader
aus wie unten dargestellt:Informationen über den Fehlercode
protocol.http.DuplicateHeader
sind wie unten dargestellt:<ph type="x-smartling-placeholder">
- Klicken Sie auf Logs ansehen und maximieren Sie die Zeile für die fehlgeschlagene Anfrage.
- Im Fenster Logs werden die folgenden Details angezeigt:
<ph type="x-smartling-placeholder">
- </ph>
- Statuscode:
400
- Fehlerquelle:
apigee
- Fehlercode:
protocol.http.DuplicateHeader
.
- Statuscode:
- Wenn die Fehlerquelle den Wert
apigee
oderMP
hat und der Fehlercode den Wertprotocol.http.DuplicateHeader
, dann bedeutet dies, dass die HTTP-Anfrage von Der Client enthielt doppelte Header.
Trace-Tool
<ph type="x-smartling-placeholder">NGINX
<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,
enthält die wichtigsten Informationen zu HTTP-
400
-Fehlern. Prüfen Sie die 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.
- Suchen Sie nach
400
-Fehlern während einer bestimmten Dauer (wenn die in der Vergangenheit aufgetreten ist) oder wenn immer noch Anfragen mit400
Wenn Sie
400
-Fehler mit dem X-Apigee-fault-code finden entspricht dem Wert vonprotocol.http.DuplicateHeader
, dann Bestimmen Sie den Wert von X-Apigee-fault-source..Beispiel 400-Fehler aus NGINX-Zugriffsprotokoll:
Der obige Beispieleintrag aus dem NGINX-Zugriffslog 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
- Ermitteln Sie den Fehlercode und die Fehlerquelle für den mit der API beobachteten Fehler. Monitoring- oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte erläutert.
- Wenn die Fehlerquelle den Wert
apigee
oderMP
hat, ist dies gibt an, dass die von der Clientanwendung an Apigee gesendete Anfrage doppelte Einträge enthält Header. Sie können den tatsächlichen Header ermitteln, der mehrmals im Rahmen der Anfrage gesendet wird, indem Sie eine der folgenden Methoden:
Fehlermeldung
Fehlermeldung
Wenn Sie Zugriff auf die vollständige Fehlermeldung von Apigee Edge haben, dann Weitere Informationen finden Sie im
faultstring
.faultstring
enthält den Headername, der mehrmals gesendet wurde.Beispiel für eine Fehlermeldung:
"faultstring":"Duplicate Header \"Expires\""
- In der obigen Fehlermeldung sehen Sie, dass der Header
Expires
ein mehr als einmal gesendet, wie infaultstring
angezeigt.
Tatsächliche Anfrage
Über die eigentliche Anfrage
Wenn Sie Zugriff auf die eigentliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:
- Überprüfen Sie die Liste der in der Anfrage übergebenen Header.
- Wenn Sie feststellen, dass ein bestimmter Titel mehr als einmal im mit demselben oder unterschiedlichen Werten anfordern , ist das der Grund für diesen 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
<ph type="x-smartling-placeholder">Expires
mehr als einmal. Daher schlägt diese Anfrage mit dem Fehler400 Bad Request
fehl und Fehlercode:protocol.http.DuplicateHeader
.- Wenn Sie Zugriff auf die Clientprotokolle haben, Informationen über die tatsächliche Anfrage an Apigee Edge und ermitteln Sie den Header, wird mehrmals gesendet.
Auflösung
Duplikate beheben
Option 1 [Empfohlene Option] Korrigieren Sie die Clientanwendung so, dass sie keine doppelten Header enthält
<ph type="x-smartling-placeholder">- Analysieren Sie den Grund für das Senden eines doppelten Headers durch den Kunden. Beispiel:
Expires
im obigen Fall. Prüfen Sie, ob die API-Proxys in Ordnung sind der doppelten Kopfzeile. Normalerweise ist dies gemäß der HTTP-Spezifikation nicht sinnvoll. RFC7230. - Ändern Sie die Client-Anwendung gegebenenfalls so, dass keine doppelten Header gesendet werden.
Im oben beschriebenen Beispiel wird die Kopfzeile
Expires
gesendet, zweimal mit demselben Wert, was nicht wünschenswert ist. Sie können das Problem beheben, indem Sie dieExpires
-Header nur einmal, wie unten gezeigt:curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
- Wenn dies gewünscht ist und Sie die doppelten Kopfzeilen zulassen möchten, gehen Sie zu Option 2: CwC-Attribut verwenden.
CwC
Option 2: CwC-Attribut verwenden
<ph type="x-smartling-placeholder">Apigee bietet eine
CwC-Eigenschaft HTTPHeader.<HeaderName>
,die Client
Anwendungen und Zielservern, um doppelte Header an API-Proxys in Apigee Edge zu senden.
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 die Überschrift Expires
.
HTTPHeader.Expires=allowDuplicates, multiValued
- Als Private Cloud-Nutzer können Sie das Attribut so konfigurieren, dass
Apigee Edge nicht den Fehler
400 Bad Request
ausgibt, auch wenn die Anfrage enthält doppelte Header mithilfe des Anleitung zur Konfiguration von Message Processors für die Verwendung doppelter Header. - Wenn Sie ein Öffentlicher Cloud-Nutzer sind, wenden Sie sich an den Apigee Edge-Support, um diese Eigenschaft zu konfigurieren. für Ihr Unternehmen.
Spezifikation
Apigee erwartet, dass die Clientanwendung keine doppelten Header als Teil der Anfrage sendet gemäß den folgenden RFC-Spezifikationen:
Spezifikation |
---|
<ph type="x-smartling-placeholder"></ph> RFC 7230, Abschnitt 3.2.2: Feldreihenfolge |
<ph type="x-smartling-placeholder"></ph> RFC 7230, Abschnitt 3.2 Headerfelder |
Wenn Sie weitere Unterstützung vom Apigee-Support benötigen, gehen Sie zu 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
- Vollständiger
curl
-Befehl zum Reproduzieren des400
-Fehlers - 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
- Führen Sie den
curl
-Befehl aus, mit dem Sie den400
-Fehler reproduziert haben - 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 für Message Processor
/opt/apigee/var/log/edge-message-processor/logs/system.log