Caching

Caching

Hier werden nur Caching Headers im Response von GET Request behandelt.

Einträge dem Cache hinzufügen (Cacheability)

Dieses Kapitel behandelt die Cache-Control direktiven

public
private
no-store
(max-age)
(s-maxage)

Algorithmus zur Bestimmung der Cachebarkeit [1]

if(
	Methode speicherbar und unterstützt vom cache &&
	Statuscode unterstützt vom cache &&
	Statuscode != 1xx &&
	!request.no-store &&
	!response.no-store &&
	(shared => !response.private) &&
	( (shared => !request.Authorization) || unless the response explicitly allows it (see Section 3.2) ) &&
	(
		response.Expires ||
		response.max-age ||
		(shared && response.s-maxage) ||
		(response.Cache-Control Extension (see Section 5.2.3) that allows it to be cached) ||
		(response.status.cacheable_by_default) ||
		(response.public)
	)
) {
	Vermutlich Speichern
}
else {
	Definitiv nicht speichern
}

Speicherbare Methoden sind [2]:

GET [3]
HEAD [4]
POST mit explicit freshness information (s. Calculating Freshness Lifetime) [5]. Dazu gibts eine weitere Erklärung und ein Beispiel von eBay.

Zu den Statuscodes die standardmäßig cachebar sind gehören unter anderem: 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, und 501 [6][7]

Die Statuscode != 1xx Einschränkung kommt aus dem aktuellen draft und sorgt dafür das nur finale (>= 200) Antworten gespeichert werden.

Einträge aus dem Cache löschen (Invalidation)

Einträge aus dem Cache holen

Dieses Kapitel behandelt die Cache-Control direktiven

no-cache

if(
	Anfrage.URI == Eintrag.URI &&
	passtZusammen(Anfrage.Methode, Eintrag.Methode) &&
	Alle Header des Eintrags passen zu denen der Anfrage &&
	( (Anfrage.Pragma.no-cache || Anfrage.Cache-Control.no-cache) => erfolgreiche validierung von Eintrag ) &&
	( Eintrag.Cache-Control.no-cache => erfolgreiche validierung von Eintrag ) &&
	(
		Eintrag.fresh ||
		Eintrag.can_be_served_stale (see Section 4.2.4) ||
		erfolgreiche validierung von Eintrag
	)
) {
	Eintrag verwenden
}
else {
	Eintrag nicht verwenden
}

passtZusammen(Anfrage_Methode, Eintrag_Methode)

Ein GET Eintrag kann eine GET oder eine HEAD Anfrage beantworten [8].
Ein HEAD Eintrag kann eine HEAD Anfrage beantworten [9].
Ein POST Eintrag kann
- eine GET Anfrage beantworten, wenn der Eintrag Content-Location gleich der Anfrage URI und den Status-Code 200 hat [10].
- eine POST Anfrage mit dem selben Body??

		GET	POST
		Eintrag
Anfrage	GET		, wenn der Eintrag Content-Location gleich der Anfrage URI und den Status-Code 200 hat [11]
	HEAD		??
	POST		( )?? s. eBay Beispiel

Weiteres

Dieser Abschnitt ist noch hochgradig Falsch!

public proxy (shared cache) vs private browser cache
Neu Laden vs validieren

`Cache-Control` vom Server	Für	Funktion	Typ
`no-cache`		Immer → validieren	Cachability
`public`		Private / Shared	Cachability
`private`	Shared	Private / Shared	Cachability
`max-age=<seconds>`	Private / Shared	Relative Cache Zeit	Expiration
`s-maxage=<seconds>`	Shared	Relative Cache Zeit (vorrang vor `Expires` und `s-maxage`)	Expiration
`must-revalidate`	Private / Shared	Abgelaufen → validieren	Re{validate,loading}
`proxy-revalidate`	Shared	Abgelaufen → validieren	Re{validate,loading}
`immutable`		Nicht abgelaufen → verwenden (auch bei F5, aber nicht bei Shift+F5) / Abgelaufen →Nicht verwenden [12]	Re{validate,loading}
`no-store`		Cachability: Private / Shared	Other
`no-transform`		Gecachten content nicht verändern (z.B. Optimieren)	Other