Caching

Cache-Topologien

Unterschiedliche Cache-Topologien sind möglich

Ausschließlich clientseitiger Cache
Clientseitig shared Cache (Proxy)
Server-Cache
Beliebige Mischformen dieser drei Formen

Ausschließlich clientseitiger Cache

Clientseitiger shared Cache (Proxy)

Server-Cache

Mischform

Konsistenz des Caches

Wie kann man den Cache konsistent halten?

Server notifiziert die Caches über Änderungen
(Notifikationsmodell)
Server sagt dem Cache, wie lange Daten gültig sind
(Expirationsmodell)
Cache fragt beim Server nach, ob Daten noch gültig sind
(Validierungsmodell)

Welche dieser Methoden ist für HTTP ungeeignet und warum?

Expirationsmodell

Server sendet die Gültigkeitsdauer der Daten im Response mit

HTTP/1.1 200 OK
Date: Mon, 03 Oct 2022 14:14:27 GMT
Server: Apache
Cache-Control: max-age=60
Content-Language: de-DE
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked

Alternativ kann er auch ein absolutes Datum angeben

Expires: Tue, 04 Oct 2022 14:14:27 GMT

Client (oder Proxy) fragt die Ressource erst nach Ablauf der Gültigkeitsdauer erneut an
Alle Anfragen vor Ablauf werden aus dem Cache beantwortet

Validierungsmodell

Client (oder Proxy) fragt beim Server an, ob seine Kopie der Ressource noch aktuell ist
Client kann bedingten Request stellen
GET /orders/ HTTP/1.1
Host: hs-mannheim.de
If-Modified-Since: Mon, 03 Oct 2022 14:14:27 GMT
Client kann eine Prüfsumme (Entity-Tag, Etag) über die Ressource berechnen und entsprechende Anfrage stellen
GET /orders/ HTTP/1.1
Host: hs-mannheim.de
If-None-Match: „b1b88d1e56778fe933fd4de66342f59b“
Wenn sich die Ressource nicht verändert hat, liefert der Server ein 304 Not Modified, andernfalls die Ressource

Prüfsummen mit ETag

Zwei Arten von ETags

Starke ETags (strong etags): Response muss Byte für Byte identisch sein, damit der Server dasselbe ETag verwenden darf

Erlauben range requests

Schwache ETags (weak etags): Repräsentieren Ressource auf logischer Ebene, Darstellung darf sich bei identischem ETag leicht unterscheiden

Verbieten range requests
Zu erkennen an einem vorangestellten W/
Etag: W/"845250bc4bb5783e0d618fcc97204e81"

Cache-Control-Header: Request

Request-Header-Feld Cache-Control steuert Caching

Attribut	Bedeutung
no-cache	Antwort muss vom original Server kommen, nicht aus dem Cache
no-store	Darf nicht persistent (z. B. auf Platte) abgelegt werden
max-age=…	Zeit in Sekunden, die die Antwort alt sein darf. 0 entspricht no-cache
max-stale=…	Client nimmt auch nicht aktuellen Antworten, solange sie nicht älter als die angegebenen Sekunden sind
min-fresh=…	Wie lange muss die Antwort mindestens noch gültig sein
no-transform	Cache darf die Daten nicht verändern (z. B. Bilder nicht konvertieren)
only-if-cached	Client will die Daten nur, wenn sie aus einem Cache stammen

Cache-Control-Header: Response

Response-Header-Feld Cache-Control steuert Caching

Attribut	Bedeutung
public	Darf auch von einem shared Cache gecached werden
private	Darf von einem shared Cache nicht gecached werden
no-cache	Darf nicht gecached werden
no-store	Darf nicht persistent (z. B. auf Platte) abgelegt werden
no-transform	Cache darf Daten nicht verändern (z. B. Bilder nicht konvertieren)
must-revalidate	Ressource noch einmal validiert werden bevor sie ausgeliefert wird
proxy-revalidate	Wie must-revalidate aber nur für shared Caches
max-age=…	Zeit in Sekunden, für die die Antwort gültig ist
s-maxage=…	Wie max-age aber für shared Caches