Weitergeleitete und hostbezogene Header, die an HTTP-Backends gesendet werden, stimmen nicht mit den Erwartungen des Backends überein

Problemsymptome

Möglicherweise sehen Sie eines oder mehrere der folgenden Symptome:

• Der Backend-Service erwartet Forwarded: host=<client-hostname>, aber der Wert fehlt.

• Der Backend-Service empfängt nur Forwarded: for=...-Einträge.

• Der Backend-Service empfängt den Backend-Zielhostnamen im Host-Header anstelle des clientseitigen Hostnamens.

• Umleitungen, generierte URLs oder hostbasierte Zugriffssteuerungslogik funktionieren anders, nachdem die API hinter API Gateway platziert wurde.

• Der Backend-Service empfängt mehrere Forwarded- oder X-Forwarded-For-Werte, und die Anwendung verarbeitet nur einen Wert.

Mögliche Gründe

Nicht übereinstimmende Weiterleitungs- und Hostheader können aus folgenden Gründen auftreten:

• Die Anwendung erwartet Forwarded: host=... oder Forwarded: proto=..., aber API Gateway fügt standardmäßig nur einen for=...-Eintrag hinzu.

• Die Anwendung liest den Host-Header, aber API Gateway schreibt diesen Header für das Backend-Ziel neu.

• Die Anwendung erwartet einen einzelnen Weiterleitungswert, aber die Anforderung enthält eine Weiterleitungskette.

• Das Deployment enthält keine Request-Header-Transformation, die den Client-orientierten Host an das Backend übergibt.

Verhalten des weitergeleiteten Headers verstehen

Für HTTP-Backends fügt API Gateway Anforderungsheader hinzu, die Client-IP-Informationen enthalten.

Die Anforderung an das Backend kann die folgenden Header enthalten:

• X-Real-IP

• Forwarded

• X-Forwarded-For

• User-Agent: Oracle API Gateway

Der Forwarded-Standardwert ist ein for=...-Eintrag. API Gateway fügt dem Forwarded-Header nicht automatisch host=...- oder proto=...-Werte hinzu.

Wenn der Client vorhandene Weiterleitungsheader sendet, behält API Gateway diese Werte bei und hängt seine eigenen Client-IP-Informationen an. Das Backend kann daher eine Kette von Forwarded- oder X-Forwarded-For-Werten empfangen.

Verhalten des Hostheaders verstehen

Bei HTTP-Backends ist der Host-Header in der Anforderung an das Backend standardmäßig nicht der ursprüngliche clientseitige Host. API Gateway schreibt den Host-Header für das Backend-Ziel neu.

Wenn die Anwendung den Client-orientierten Host benötigt, konfigurieren Sie eine Request-Header-Transformation, die den eingehenden Host-Wert in einen Header kopiert, den die Anwendung liest. Beispiel: Verwenden Sie die Kontextvariable request.host, um den eingehenden Host in X-Forwarded-Host oder in einen anwendungsspezifischen Header zu kopieren.

Verlassen Sie sich nicht auf den Host-Header der Backend-Anforderung, um den externen Hostnamen beizubehalten.

Erhaltene Header prüfen

Wiederholen Sie die Anforderung über API Gateway, und prüfen Sie die Header, die das Backend empfängt.

Prüfen Sie die folgenden Headerwerte:

• Der sichtbare Forwarded-Header des Backends.

• Der sichtbare X-Forwarded-For-Header des Backends.

• Der sichtbare Host-Header des Backends.

• Der für das Backend sichtbare X-Forwarded-Host-Header, wenn die Route diesen Header verwendet.

• Jeder benutzerdefinierte Header, den das Deployment aus dem eingehenden Host-Wert erstellt.

Wenn möglich, verwenden Sie einen temporären Endpunkt, der Anforderungsheader wiedergibt. Die Echoantwort zeigt die Headerwerte, die am Backend angekommen sind.

Deployment-Konfiguration prüfen

Prüfen Sie die API-Deployment-Konfiguration in API Gateway, um die übereinstimmende Route und alle Anforderungsheadertransformationen auf dieser Route zu identifizieren.

Bestätigen Sie die folgenden Konfigurationswerte:

• Der Wert backend.url für die Route.

• Der Wert routes.path, der mit der Anforderung übereinstimmt.

• Die Anforderungsheadertransformationen auf der Abgleichsroute.

Wenn das Backend vom clientseitigen Hostnamen abhängt, stellen Sie sicher, dass die Route den eingehenden Host-Wert in einen Header kopiert, den das Backend lesen kann.

Wenn das Backend von Forwarded: host=... abhängt, stellen Sie sicher, dass die eigene Headerstrategie diesen Wert festlegt. Gehen Sie nicht davon aus, dass API Gateway den Wert automatisch erstellt.

Weitergeleitete und Hostheaderprobleme beheben

Wenden Sie den Fix an, der mit dem Headerwert übereinstimmt, den das Backend benötigt:

• Wenn das Backend X-Forwarded-Host verwenden kann, konfigurieren Sie die Route, um diesen Header zu senden, und aktualisieren Sie die Anwendung, um ihn zu lesen.

• Wenn das Backend den clientseitigen Host in einem benutzerdefinierten Header benötigt, erstellen Sie eine Anforderungsheadertransformation aus dem eingehenden Host-Wert.

• Wenn das Backend Forwarded: host=... erwartet, aktualisieren Sie die Anwendung so, dass sie die von API Gateway bereitgestellten Header verwendet, oder fügen Sie eine explizite Headerstrategie hinzu, die von der Anwendung verwendet werden kann.

• Wenn das Backend nur einen Forwarded- oder X-Forwarded-For-Wert parst, aktualisieren Sie die Anwendung so, dass sie eine Weiterleitungskette verarbeitet.

Weitergeleitete Header und Hostheader prüfen

Nachdem Sie die Deployment- oder Anwendungslogik aktualisiert haben, wiederholen Sie die Anforderung, und prüfen Sie das Ergebnis.

Bestätigen Sie die folgenden Ergebnisse:

• Das Backend empfängt den erwarteten clientseitigen Hostwert im konfigurierten Header.

• Das Backend verarbeitet mehrere Forwarded- oder X-Forwarded-For-Werte korrekt.

• Umleitungen, generierte URLs und hostbasierte Logik verwenden den erwarteten Hostnamen und das erwartete Schema.

• Hostbasierte Zugriffssteuerungslogik gibt die erwartete Antwort zurück.

Weitere Informationen

Weitere Informationen finden Sie unter:

• HTTP- oder HTTPS-URL als API-Gateway-Backend hinzufügen

• Eingehende Anforderungen und ausgehende Antworten transformieren

• Kontextabhängige Variablen zu Policys und HTTP-Backend-Definitionen hinzufügen

• Verschiedene Fehler beim Aufrufen von APIs