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

Algorithmus zur Bestimmung der Cachebarkeit [1]

if(
	Methode speicherbar &&
	Statuscode unterstützt &&
	!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]

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

Mit public können auch POST und Auth Resourcen gecached werden [7][8]. Ohne genaue Erklärung äusert sich auch eBay wie es POST requests cached.

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

• 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

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
• Entscheidungsbaum, welche ''Cache-Control'' direktiven verwendet werden sollen
• https://www.slideshare.net/martinmartin7777/http-caching-basics-66553113
• https://www.keycdn.com/blog/http-cache-headers
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
• https://www.fastly.com/blog/understanding-vary-header-browser
• https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies
• REDbot: Caching Header online analyse tool
• Preload ggf. auch bei Edge caches
• POST, PUT und DELETE invalidieren private und shared cached. [13]
• RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
• RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
• draft-ietf-httpbis-cache-03: HTTP Caching (obsoletes RFC 7234)
• REDbot's Algorithmus zur Cache Header Auswertung.
• Liste an ''Cache-Control'' direktiven bei der IANA.
• Zusammenfassung wie Browser Caching umsetzen (Kompatibilitäts-Testergbnisse)
• JavaScript implementierung eines Caches.