400 Bad Request – DuplicateHeader

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 400 Bad Request mit dem Fehlercode protocol.http.DuplicateHeader als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 400 Bad Request

Außerdem wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

Mögliche Ursachen

Dieser Fehler tritt auf, wenn ein bestimmter HTTP-Header, der keine Duplikate in Apigee Edge haben darf, mehrmals mit denselben oder unterschiedlichen Werten als Teil der HTTP-Anfrage auftritt, die vom Client an Apigee Edge gesendet wird.

Gemäß RFC 7230, Abschnitt 3.2.2: Feldreihenfolge, darf ein 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 ( #(values)) oder das Headerfeld ist eine bekannte Ausnahme. Wenn Apigee Edge einen bestimmten Header, der keine Duplikate haben darf, mehr als einmal in der HTTP-Anfrage findet, die vom Client gesendet wird, antwortet es mit 400 Bad Request und dem Fehlercode protocol.http.DuplicateHeader.

Mögliche Ursachen für diesen Fehler:

Allgemeine Diagnoseschritte

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

Ursache: Doppelter Header in der Anfrage

Diagnose

1. Ermitteln Sie den Fehlercode und die Fehlerquelle für den beobachteten Fehler mithilfe von API Monitoring oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte beschrieben.
2. Wenn die Fehlerquelle den Wert apigee oder MP hat, bedeutet dies, dass die von der Clientanwendung an Apigee gesendete Anfrage doppelte Header enthält.

3. Sie können den tatsächlichen Header, der mehrmals als Teil der Anfrage gesendet wird, mit einer der folgenden Methoden ermitteln:

   Fehlermeldung

   Fehlermeldung verwenden

   1. Wenn Sie Zugriff auf die vollständige Fehlermeldung haben, die Sie von Apigee Edge erhalten haben, dann sehen Sie sich den faultstring an. Der faultstring enthält den Headernamen, der mehrmals gesendet wurde.

      Beispiel für eine Fehlermeldung:

      "faultstring":"Duplicate Header \"Expires\""

   2. In der obigen Fehlermeldung sehen Sie, dass der Header Expires mehrmals gesendet wurde, wie im faultstring zu sehen ist.

   Tatsächliche Anfrage

   Tatsächliche Anfrage verwenden

   1. Wenn Sie Zugriff auf die tatsächliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:

      1. Prüfen Sie die Liste der in der Anfrage übergebenen Header.
      2. Wenn ein bestimmter Header mehrmals mit demselben oder unterschiedlichen Werten in der Anfrage vorkommt , ist das die Ursache 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 Expires mehrmals gesendet. Daher schlägt diese Anfrage mit dem 400 Bad Request Fehler und dem Fehlercode: protocol.http.DuplicateHeader fehl.

   2. Alternativ können Sie in den Clientlogs nach Informationen zur tatsächlichen Anfrage an Apigee Edge suchen und den Header ermitteln, der mehrmals gesendet wird.

Auflösung

HTTPHeader.Expires=allowDuplicates, multiValued

Spezifikation

Apigee erwartet, dass die Clientanwendung gemäß den folgenden RFC-Spezifikationen keine doppelten Header als Teil der Anfrage sendet:

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie den Abschnitt Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Erfassen Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support.

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

• Name der Organisation
• Name der Umgebung
• Name des API-Proxys
• Vollständiger curl-Befehl zum Reproduzieren des 400-Fehlers
• Trace-Datei für die API-Anfragen

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

• Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
• Name der Umgebung
• API-Proxy-Bundle
• Vollständiger curl-Befehl zum Reproduzieren des 400-Fehlers
• Trace-Datei für die API-Anfragen

• NGINX-Zugriffslogs:

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

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

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