Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info
In diesem Thema wird beschrieben, wie Edge HTTP/1.1-Caching-Header verarbeitet, wenn Sie die ResponseCache-Richtlinie verwenden. Apigee Edge 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 Edge 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.
| Header | Support |
|---|---|
| Cachesteuerung | Wird bei Antworten von Back-End-Ursprungsservern, aber nicht bei Clientanfragen unterstützt. Edge 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 | Edge sendet abhängig von den eingehenden Headern komprimierte oder unkomprimierte Antworten. |
Cache-Control
Apigee Edge 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 Edge API-Proxy definiert sind, als auch solche, die mit TargetServer-API-Aufrufen erstellt wurden.
Einschränkungen bei der Unterstützung der Cachesteuerung
Apigee Edge unterstützt eine Teilmenge der Cache-Control-Antwortheaderfunktionen, die in der HTTP/1.1-Spezifikation definiert sind. Hinweis:
- Apigee Edge unterstützt keine
Cache-Control-Header, die bei eingehenden Clientanfragen empfangen werden. - Apigee Edge unterstützt nur das Konzept öffentlicher Caches. Gemäß der HTTP-Spezifikation kann
Cache-Controlentweder öffentlich (gemeinsam genutzt) oder privat (einzelner Nutzer) sein. - Apigee Edge 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 Edge 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 Edge die Anweisung |
cache-extension |
Nicht unterstützt. |
max-age |
Wenn das Element Diese Anweisung wird mit der Anweisung |
must-revalidate |
Nicht unterstützt. Alle Cache-Einträge werden von Apigee Edge unmittelbar nach Ablauf gelöscht. |
no-cache |
Edge 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. |
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 Edge unmittelbar nach Ablauf gelöscht. |
public |
Edge 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 Diese Anweisung überschreibt die Anweisung |
Gültig bis
Wenn das Flag UseResponseCacheHeaders in der ResponseCache-Richtlinie auf true gesetzt ist, kann Edge 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.
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.
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 Edge zurücksendet, speichert Edge 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 Edge eine eingehende GET-Anfrage von einem Client mit einem If-Match-Header empfängt:
| Wenn | Then |
|---|---|
Der Header If-Match gibt ein oder mehrere ETags an |
|
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 Edge eine eingehende GET-Anfrage mit diesem Header empfängt:
| Wenn | Then |
|---|---|
Der Header If-None-Match gibt ein oder mehrere ETags an |
|
|
Der Header |
Edge 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 Edge ihn an den Client zurückgibt. |
| Edge empfängt ein ETag von einem Ursprungsserver | Das ETag wird unverändert an den Client zurückgesendet |
If-Modified-Since
Wenn Apigee Edge 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 Edge übertragen wurden, berücksichtigt werden. Wenn der Ursprungsserver eine neue Entität zurückgibt, ersetzt Edge den vorhandenen Cache-Eintrag durch den neuen Wert. Wenn der Server den Status „304 Nicht geändert“ zurückgibt, gibt Edge 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.