Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
In diesem Thema wird beschrieben, wie Edge HTTP/1.1-Caching-Header verarbeitet, wenn Sie die Richtlinie ResponseCache verwenden. Apigee Edge unterstützt derzeit einen Teil der HTTP/1.1-Caching-Header und -Anweisungen (nicht unterstützte Features werden in diesem Thema aufgeführt), die von Back-End-Zielservern (Ursprungsserver) empfangen werden.
Darüber hinaus führt Edge bei bestimmten Headern basierend auf ihren Anweisungen Aktionen aus. In einigen Fällen überschreiben diese HTTP/1.1-Cache-Header das Verhalten, das in der ResponseCache-Richtlinie angegeben ist.
Wenn beispielsweise der Header Cache-Control von einem Back-End-Server zurückgegeben wird, kann die Anweisung s-maxage des Headers möglicherweise andere Ablaufeinstellungen in der Richtlinie überschreiben.
| Header | Support |
|---|---|
| Cachesteuerung | Wird bei Antworten unterstützt, die von Back-End-Ursprungsservern zurückgegeben werden, aber nicht bei Clientanfragen. 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 entweder komprimierte oder unkomprimierte Antworten. |
Cache-Control
Apigee Edge unterstützt den Cache-Control-Header nur bei Antworten, die von Back-End-Ursprungsservern zurückgegeben werden (die HTTP/1.1-Spezifikation erlaubt Cache-Control-Header sowohl in Clientanfragen als auch in Ursprungsserverantworten). Ursprungsserver können sowohl Zielendpunkte enthalten, die in einem Apigee Edge API-Proxy definiert wurden, als auch Zielendpunkte, die mit TargetServer API-Aufrufen erstellt wurden.
Einschränkungen bei der Unterstützung der Cachesteuerung
Apigee Edge unterstützt einen Teil der Cache-Control-Antwortheaderfunktionen, die in der HTTP/1.1-Spezifikation definiert sind. Hinweis:
- Apigee Edge unterstützt keine
Cache-Control-Header, die mit eingehenden Clientanfragen eingehen. - 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 einen Teil 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-Cache-Control-Antwortheader-Anweisungen beschrieben.
Ausführlichere Informationen zu den hier aufgeführten Anweisungen finden Sie unter Cachesteuerung in der HTTP/1.1-Spezifikation.
| Anweisung der Cachesteuerung | Wie Apigee Edge die Anweisung verarbeitet |
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 gelöscht, sobald sie ablaufen. |
no-cache |
Edge speichert die Ursprungsantwort im Cache, muss aber noch einmal mit dem Ursprungsserver validiert werden, bevor sie verwendet werden kann, um alle nachfolgenden Clientanfragen zu erfüllen. 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 gelöscht, sobald sie ablaufen. |
public |
Edge speichert die Ursprungsantwort im Cache, auch wenn in anderen Anweisungen etwas anderes angegeben ist. 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 |
Läuft ab am
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 empfängt, der einen If-Match-Header enthält:
| 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 Nicht geändert zurück |
| Es wurde ein Cache-Eintrag mit demselben Anfrage-URI gefunden, der aber nur schwache ETags enthält | Der Eintrag muss vom Ursprungsserver neu 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 weitergeleitet, auch wenn ein gültiger Cache-Eintrag vorhanden ist.
Dadurch wird sichergestellt, dass Aktualisierungen einer Ressource, die nicht Apigee Edge durchlaufen haben, 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, wenn der Header Last-Modified der im Cache gespeicherten Antwort anzeigt, dass er 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.