Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu
Apigee X. 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 ergreift Edge bei bestimmten Headern Maßnahmen basierend auf ihren Anweisungen. 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. |
Cachesteuerung
Apigee Edge unterstützt den Cache-Control Header 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. Hinweise:
- 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 Ursprung servern. 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 Ursprungsantwort im Cache, auch wenn andere Anweisungen etwas anderes angeben. 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 UseResponseCacheHeaders Flag in der ResponseCache-Richtlinie auf
true gesetzt ist, kann Edge den Expires Header 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 Ziel-Endpunkt 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 |
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
an den Ursprungsserver übergeben, auch 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 Not Modified" 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 der ResponseCache-Richtlinie.