Cacheable
Eine cachefähige Antwort ist eine HTTP-Antwort, die zwischengespeichert werden kann, das heißt, sie wird gespeichert, um später abgerufen und genutzt zu werden, wodurch eine neue Anfrage an den Server eingespart wird. Nicht alle HTTP-Antworten können zwischengespeichert werden; dies sind die Voraussetzungen dafür, dass eine HTTP-Antwort cachefähig ist:
- Die in der Anfrage verwendete Methode ist cachefähig, das heißt entweder eine
GET- oder eineHEAD-Methode. Eine Antwort auf einePOST- oderPATCH-Anfrage kann ebenfalls zwischengespeichert werden, wenn die Frische angegeben ist und derContent-Location-Header gesetzt ist, aber dies wird selten implementiert. Zum Beispiel unterstützt Firefox dies nicht (Firefox Bug 109553). Andere Methoden wiePUToderDELETEsind nicht cachefähig und ihr Ergebnis kann nicht zwischengespeichert werden. - Der Statuscode der Antwort ist der Anwendung, die das Caching durchführt, bekannt und ist cachefähig. Die folgenden Statuscodes sind cachefähig:
200,203,204,206,300,301,404,405,410,414und501. - Es gibt keine spezifischen Header in der Antwort, wie z. B.
Cache-Control, mit Werten, die das Caching verbieten würden.
Beachten Sie, dass einige Anfragen mit nicht-cachefähigen Antworten zu einer bestimmten URI zuvor zwischengespeicherte Antworten von derselben URI ungültig machen können. Zum Beispiel macht ein PUT zu /pageX.html alle zwischengespeicherten Antworten auf GET- oder HEAD-Anfragen zu /pageX.html ungültig.
Wenn sowohl die Methode der Anfrage als auch der Status der Antwort cachefähig sind, kann die Antwort auf die Anfrage zwischengespeichert werden:
GET /pageX.html HTTP/1.1
(…)
200 OK
(…)
Die Antwort auf eine PUT-Anfrage kann nicht zwischengespeichert werden. Darüber hinaus macht sie zwischengespeicherte Daten für Anfragen an dieselbe URI mit HEAD- oder GET-Methoden ungültig:
PUT /pageX.html HTTP/1.1
(…)
200 OK
(…)
Das Vorhandensein des Cache-Control-Headers mit einem bestimmten Wert in der Antwort kann das Caching verhindern:
GET /pageX.html HTTP/1.1
(…)
200 OK
Cache-Control: no-cache
(…)