Cache

Ohne Vorkehrung erledigen beide dieselbe Arbeit: Jede baut die Antwort vollständig neu auf, bei hundert gleichzeitigen Aufrufen geschieht das hundertmal. RFC 9111 nennt in Abschnitt 4 das Zusammenfassen wartender Anfragen zu einem einzigen Aufruf am Ursprung – als Möglichkeit, nicht als Pflicht; ein Cache darf bündeln, muss aber nicht. Die zweite Vorkehrung steht in RFC 5861: Mit stale-while-revalidate wird der abgelaufene Stand für die angegebene Dauer weiter ausgeliefert, während die Erneuerung im Hintergrund läuft.

Cache-Control: private – nach RFC 9111 Abschnitt 5.2.2.7 darf ein gemeinsam genutzter Cache eine so gekennzeichnete Antwort nicht speichern, ein privater im Browser des Besuchers dagegen schon. Abschnitt 1.3 trennt beide: privat heißt einem einzigen Nutzer zugeordnet, gemeinsam heißt Wiederverwendung durch mehrere. Der Schutz aus Abschnitt 3.5 greift nur bei Anfragen mit Authorization-Kopfzeile; eine Anmeldung per Sitzungs-Cookie fällt nicht darunter. Ohne private oder no-store kann der nächste Besucher die Seite des vorigen bekommen.

So viele, wie die Trefferquote offenlässt – sie ist die Zahl der Treffer geteilt durch alle Anfragen. Bei 95 Prozent erreichen von 1.000 Aufrufen immer noch 50 die Datenbank, und jeder dieser Fehltreffer führt die Abfrage in voller Länge aus. Nach einem Neustart oder einer Veröffentlichung ist der Zwischenspeicher leer, dann trifft die volle Last die ungebremste Abfrage. Ein Cache verbirgt eine langsame Abfrage, er behebt sie nicht.

Nein. RFC 9111 zählt in Abschnitt 3 auf, was ein Cache nicht speichern darf – no-cache steht nicht darin. Abschnitt 5.2.2.4 verbietet allein, eine so gekennzeichnete Antwort ohne Rückfrage beim Ursprungsserver erneut auszuliefern. Das Speichern untersagt erst no-store nach Abschnitt 5.2.2.5, und zwar für jeden Teil von Anfrage und Antwort. Wer no-cache setzt, um Vertrauliches von den Datenträgern fremder Zwischenspeicher zu halten, verwechselt die beiden Angaben.