Unterstützung für HTTP-Antwortheader

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

In diesem Thema wird beschrieben, wie Apigee HTTP/1.1-Caching-Header verarbeitet, wenn Sie die ResponseCache-Richtlinie verwenden. Apigee unterstützt derzeit einen Teil der HTTP/1.1-Caching-Header und -Anweisungen (nicht unterstützte Funktionen sind in diesem Thema aufgelistet), die von Back-End-Zielservern (Ursprungsserver) empfangen werden.

Außerdem werden bei bestimmten Headern gemäß den Anweisungen von Apigee Maßnahmen ergriffen. In einigen Fällen überschreiben diese HTTP/1.1-Cache-Header das Verhalten, das in der ResponseCache-Richtlinie angegeben ist. Wenn der Header Cache-Control beispielsweise von einem Back-End-Server zurückgegeben wird, können Sie mit der Anweisung s-maxage des Headers möglicherweise andere Ablaufeinstellungen in der Richtlinie überschreiben.

Hinweis: In der HTTP/1.1-Spezifikation werden standardmäßige Caching-Header und Steuerungsmechanismen beschrieben, die das Caching in der HTTP-Anfrage-/Antwort-Kette unterstützen. Diese Header und Mechanismen liefern Informationen zu im Cache gespeicherten Ressourcen. Mit ihrer Hilfe können Server auch bestimmen, wie Daten im Cache verwaltet werden. Die Spezifikation selbst enthält detaillierte Informationen zum Caching in HTTP. Es gibt auch viele Blogs, Artikel und andere Ressourcen, die im Internet zur Verfügung stehen und das HTTP-Caching erklären.

Hinweis: Header verwenden, um Cache-Schlüssel und die TTL von Cache-Einträgen zu beeinflussen: Sie können Apigee Antwortheader verwenden lassen, wenn Sie Antwort-Cache-Schlüssel erstellen und die TTL von Cache-Einträgen festlegen. Dazu verwenden Sie die folgenden Flag-Elemente der ResponseCache-Richtlinie:

• <UseResponseCacheHeaders>: Wenn dieser Wert auf true gesetzt ist, berücksichtigt Apigee HTTP-Antwortheader, die beim Festlegen der Gültigkeitsdauer (TTL) der Antwort im Cache verwendet werden. Weitere Informationen finden Sie unter "Ablauf von Cache-Einträgen festlegen" und unter <UseResponseCacheHeaders> in ResponseCache-Richtlinie.
• <UseAcceptHeader>: Wenn dieser Wert auf true gesetzt ist, verwendet Apigee die Antwort-Accept-Header, um den Cache-Schlüssel zu ergänzen. Weitere Informationen finden Sie unter <UseAcceptHeader> in der ResponseCache-Richtlinie.

Header	Support
Cachesteuerung	Wird bei Antworten von Back-End-Ursprungsservern, aber nicht bei Clientanfragen unterstützt. Apigee unterstützt eine Teilmenge von Anweisungen.
Gültig bis	Unterstützt. Kann überschrieben werden.
Entitäts-Tags (ETags)	Spezifisches Verhalten für If-Match und If-None-Match.
If-Modified-Since	Bei GET-Anfragen wird der Header an den Ursprungsserver übergeben, auch wenn es einen gültigen Cache-Eintrag gibt.
Accept-Encoding	Apigee sendet abhängig von den eingehenden Headern komprimierte oder unkomprimierte Antworten.

Cachesteuerung

Apigee unterstützt den Header Cache-Control nur für Antworten, die von Back-End-Ursprungsservern zurückgegeben werden. Die HTTP/1.1-Spezifikation lässt Cache-Control-Header sowohl in Clientanfragen als auch in Ursprungsserverantworten zu. Ursprungsserver können sowohl Ziel-Endpunkte enthalten, die in einem Apigee-API-Proxy definiert sind, als auch solche, die mit TargetServer-API-Aufrufen erstellt wurden.

Einschränkungen bei der Unterstützung der Cachesteuerung

Apigee unterstützt eine Teilmenge der Cache-Control-Antwortheaderfunktionen, die in der HTTP/1.1-Spezifikation definiert sind. Beachten Sie Folgendes:

• Apigee unterstützt keine Cache-Control-Header, die bei eingehenden Clientanfragen empfangen werden.
• Apigee unterstützt nur das Konzept öffentlicher Caches. Gemäß der HTTP-Spezifikation kann Cache-Control entweder öffentlich (gemeinsam genutzt) oder privat (einzelner Nutzer) sein.
• Apigee unterstützt nur eine Teilmenge der Cache-Control-Antwortanweisungen in der HTTP/1.1-Spezifikation. Weitere Informationen finden Sie unter Unterstützung für Antwortheader-Anweisungen der Cachesteuerung.

Unterstützung für Antwortheader-Anweisungen der Cachesteuerung

Apigee unterstützt eine Teilmenge von Anweisungen aus der HTTP/1.1-Spezifikation bei Antworten von Ursprungsservern. In der folgenden Tabelle wird die Unterstützung von Apigee für HTTP-Antwortheader-Anweisungen der Cachesteuerung beschrieben.

Ausführlichere Informationen zu den hier aufgeführten Anweisungen finden Sie unter Cachesteuerung in der HTTP/1.1-Spezifikation.

Anweisung der Cachesteuerung	So verarbeitet Apigee die Anweisung
cache-extension	Nicht unterstützt.
max-age	Wenn das Element <UseResponseCacheHeaders> in Ihrer ResponseCache-Richtlinie auf true festlegt ist, kann die Antwort für die durch diese Anweisung angegebene Anzahl von Sekunden im Cache gespeichert werden. Diese Anweisung wird mit der Anweisung s-maxage überschrieben und überschreibt den Header Expires. Sie kann auch durch das Element <ExpirySettings> der Richtlinie überschrieben werden. Weitere Informationen finden Sie unter "Ablauf von Cache-Einträgen festlegen" und unter <UseResponseCacheHeaders> in ResponseCache-Richtlinie. Hinweis: Inhalte, die mit der ResponseCache-Richtlinie im Cache gespeichert werden, behalten den von ihrem Ursprungserverfestgelegten Wert für "max-age" bei. Das bedeutet, dass der Inhalt beim Abrufen aus dem Cache möglicherweise älter ist, als der Wert "max-age" vermuten lässt (älter als dem Client bekannt ist).
must-revalidate	Nicht unterstützt. Alle Cache-Einträge werden von Apigee unmittelbar nach Ablauf gelöscht.
no-cache	Apigee speichert die Ursprungsantwort im Cache, sie muss aber noch einmal beim Ursprungsserver validiert werden, bevor sie für nachfolgende Clientanfragen verwendet werden kann. Mit dieser Regel kann der Ursprung eine Antwort vom Typ "304 Not Modified" zurückgeben, um anzugeben, dass die Antwort aus dem Cache zurückgegeben werden soll. Die Verarbeitung, die erforderlich ist, um die gesamte Antwort zurückzugeben, wird so eingespart. Wenn der Ursprungsserver eine vollständige Antwort zurückgibt, wird der vorhandene Cache-Eintrag ersetzt. Alle in dieser Anweisung angegebenen Feldnamen werden ignoriert. Hinweis: Der HTTP/1.0-Header Pragma: no-cache wird wie Cache-Control: no-cache behandelt.
no-store	Nicht unterstützt.
no-transform	Nicht unterstützt.
private	Nicht unterstützt. Wenn diese Anweisung empfangen wird, wird die Ursprungsantwort nicht im Cache gespeichert. Alle Feldnamen werden ignoriert.
proxy-revalidate	Nicht unterstützt. Alle Cache-Einträge werden von Apigee unmittelbar nach Ablauf gelöscht.
public	Apigee speichert die ursprüngliche Antwort im Cache, auch wenn andere Anweisungen etwas anderes vorgeben. Gemäß der HTTP/1.1-Spezifikation ist die einzige Ausnahme von dieser Regel, wenn die Antwort einen Autorisierungsheader enthält.
s-maxage	Wenn das Element <UseResponseCacheHeaders> in Ihrer ResponseCache-Richtlinie auf true festlegt ist, kann die Antwort für die durch diese Anweisung angegebene Anzahl von Sekunden im Cache gespeichert werden. Diese Anweisung überschreibt die Anweisung max-age und den Header Expires. Sie kann durch das Element <ExpirySettings> der Richtlinie überschrieben werden. Weitere Informationen finden Sie unter "Ablauf von Cache-Einträgen festlegen" und unter <UseResponseCacheHeaders> in ResponseCache-Richtlinie. Hinweis: Inhalte, die mit der ResponseCache-Richtlinie im Cache gespeichert werden, behalten den vom Ursprung festgelegten Wert für "s-maxage" bei. Dies bedeutet, dass der Inhalt beim Abrufen aus dem Cache älter sein kann, als der Wert "s-maxage" vermuten lässt (älter als dem Client bekannt).

Gültig bis

Wenn das Flag UseResponseCacheHeaders in der ResponseCache-Richtlinie auf true gesetzt ist, kann Apigee den Header Expires verwenden, um die Gültigkeitsdauer (TTL)eines im Cache gespeicherten Eintrags zu bestimmen. In diesem Header wird ein Datum/eine Uhrzeit angegeben, nach dem bzw. der der Cache-Eintrag einer Antwort als veraltet gilt. Mit diesem Header können Server signalisieren, wann es in Ordnung ist, einen im Cache gespeicherten Wert basierend auf einem Zeitstempel zurückzugeben.

Hinweis: Die Anweisungen max-age und s-maxage des Headers Cache-Controlhaben Vorrang vor dem Header Expires und überschreiben ihn. Weitere Informationen finden Sie unter "Ablauf des Cache-Eintrags festlegen" und <UseResponseCacheHeaders> in der ResponseCache-Richtlinie.

Zulässige Datumsformate für den Header Expires sind in der HTTP/1.1-Spezifikation beschrieben. Beispiel:

Gültig bis: Do., 1. Dez. 1994, 16:00:00 Uhr GMT

Ausführliche Informationen zu HTTP-Formaten für Datum/Uhrzeitfinden Sie unter Datum/Uhrzeit-Formate in der HTTP/1.1-Spezifikation.

Hinweis: In Abschnitt 14.21 der Spezifikation ist angegeben, dass ein Expires-Wert von mehr als einem Jahr in der Zukunft bedeutet, dass ein Cache-Eintrag nie abläuft. Apigee interpretiert einen solchen Wert so, dass der Eintrag bis zum angegebenen Datum und zur angegebenen Uhrzeit im Cache gespeichert werden soll.

Weitere Informationen zum Header Expires finden Sie unter Headerfelddefinitionen in der HTTP/1.1-Spezifikation.

ETag

Ein Entitäts-Tag (ETag) ist eine Kennung, die mit einer angeforderten Ressource verknüpft ist. Mithilfe eines ETags kann ein Server feststellen, ob die angeforderte Ressource und die zugehörige im Cache gespeicherte Ressource übereinstimmen. Beispielsweise könnte der Server die Antwort noch einmal im Cache speichern, wenn sie nicht mit dem im Cache gespeicherten Inhalt übereinstimmt. Wenn die ETags übereinstimmen, könnte er die im Cache gespeicherte Ressource zurückgeben.

Wenn ein Zielendpunkt eine Antwort mit einem ETag an Apigee zurücksendet, speichert Apigee das ETag zusammen mit der Antwort im Cache.

Weitere Informationen zu Entitäts-Tags finden Sie unter Protokollparameter in der HTTP/1.1-Spezifikation.

If-Match

Mit dem Anfrageheader If-Match ist eine im Cache gespeicherte Entität aktuell, wenn das ETag im Header mit dem im Cache gespeicherten ETag übereinstimmt. Außer GET-Anfragen werden alle Anfragen, die den Header If-Match angeben, an den Ursprungsserver übergeben, um sicherzustellen, dass die Caching-Einrichtungen des Ursprungsservers die Möglichkeit haben, die Anfrage zu verarbeiten.

Weitere Informationen zu If-Match finden Sie unter Headerfelddefinitionen in der HTTP/1.1-Spezifikation.

Wenn Apigee eine eingehende GET-Anfrage von einem Client mit einem If-Match-Header empfängt:

If	Then
Der Header If-Match gibt ein oder mehrere ETags an	Apigee ruft alle nicht abgelaufenen Cache-Einträge für die angegebene Ressource ab und vergleicht alle starken ETags dieser im Cache gespeicherten Einträge mit denen im Header If-Match. Wenn eine Übereinstimmung gefunden wird, wird der Cache-Eintrag zurückgegeben. Andernfalls wird die Anfrage an den Ursprungsserver übergeben.
Der Header If-Match gibt das Zeichen „*“ an.	Die Anfrage wird an den Ursprungsserver übergeben, um sicherzustellen, dass alle Caching-Einrichtungen des Ursprungsservers die Möglichkeit haben, die Anfrage zu verarbeiten.
Es wurde ein Cache-Eintrag mit demselben Anfrage-URI gefunden, der aber nur schwache ETags enthält	Der Eintrag muss vom Ursprungsserver noch einmal validiert werden, bevor er an den Client zurückgegeben wird.
Die ETags stammen vom Ursprungsserver.	Das ETag wird unverändert an den Client zurückgesendet

If-None-Match

Mit dem Header If-None-Match ist eine im Cache gespeicherte Entität aktuell, wenn das ETag im Header nicht mit dem im Cache gespeicherten ETag übereinstimmt. Außer GET-Anfragen werden alle Anfragen, die diesen Header enthalten, an den Ursprungsserver übergeben.

Wenn Apigee eine eingehende GET-Anfrage mit diesem Header empfängt:

If	Then
Der Header If-None-Match gibt ein oder mehrere ETags an	Apigee ruft alle nicht abgelaufenen Cache-Einträge für den angegebenen URI ab und vergleicht alle starken ETags dieser im Cache gespeicherten Einträge mit denen im Header If-None-Match. Wenn eine Übereinstimmung gefunden wird, gibt Apigee den Status "304 Not Modified" zurück. Wenn keine Übereinstimmung gefunden wird, leitet Apigee die Anfrage an den Ursprungsserver weiter.
Der Header If-None-Match gibt "*" und einen nicht abgelaufenen Cache-Eintrag für den angeforderten URI an.	Apigee gibt den Status "304 Not Modified" zurück
Es wurde ein Cache-Eintrag mit demselben Anfrage-URI gefunden, der aber nur schwache ETags enthält	Der Eintrag muss vom Ursprungsserver noch einmal validiert werden, bevor Apigee ihn an den Client zurückgibt.
Apigee empfängt ein ETag von einem Ursprungsserver	Das ETag wird unverändert an den Client zurückgesendet

If-Modified-Since

Wenn Apigee in einer GET-Anfrage einen If-Modified-Since-Header empfängt, wird er auch dann an den Ursprungsserver übergeben, wenn ein gültiger Cache-Eintrag vorhanden ist.

So wird sichergestellt, dass Änderungen an einer Ressource, die nicht über Apigee übertragen wurden, berücksichtigt werden. Wenn der Ursprungsserver eine neue Entität zurückgibt, ersetzt Apigee den vorhandenen Cache-Eintrag durch den neuen Wert. Wenn der Server den Status "304 Not Modified" zurückgibt, gibt Apigee den Antwortwert zurück, sofern der Header Last-Modified der im Cache gespeicherten Antwort angibt, dass sie nicht geändert wurde.

Accept-Encoding

Wenn eine eingehende Anfrage den Header Accept-Encoding mit den Werten gzip, deflate oder compress enthält, antwortet der Ursprungsserver mit komprimierten Daten. Wenn nachfolgende Anfragen ohne die Header Accept-Encoding gesendet werden, erwarten sie eine unkomprimierte Antwort. Der Antwort-Caching-Mechanismus von Apigee ist in der Lage, sowohl komprimierte als auch nicht komprimierte Antworten abhängig von den eingehenden Headern zu senden, ohne zum Ursprungsserver zurückzukehren.

Header-Werte des Typs "Accept" können an Cache-Schlüssel angehängt werden, damit die Schlüssel für jedes im Cache gespeicherte Element aussagekräftiger werden. Weitere Informationen finden Sie unter "Cache-Schlüssel konfigurieren" in derResponseCache-Richtlinie.