no-cache und no-store: Zwei Cache-Regeln mit verschiedenen Zielen

Die Namen führen leicht in die Irre

Nach der MDN-Dokumentation erlaubt „Cache-Control: no-cache“ grundsätzlich eine Speicherung, verlangt aber vor der Wiederverwendung eine Prüfung beim Ursprungsserver. „no-store“ weist Caches dagegen an, die Antwort nicht zu speichern. Die Direktiven lösen somit unterschiedliche Aufgaben. Ein ähnlich klingender Name ist keine ausreichende Grundlage für eine technische Entscheidung.

Der Ratgeber behandelt HTTP-Caches. Browserhistorie, bereits vorhandene Kopien und anwendungseigene Speicher müssen gesondert betrachtet werden. MDN weist beim Zurücknavigieren ausdrücklich auf Besonderheiten hin. Aus einem einzelnen Header folgt deshalb keine umfassende Zusage, dass auf einem Gerät keinerlei frühere Darstellung mehr sichtbar sein kann.

Zwei Seiten eines Beispielprojekts

Unser Beispiel ist ein kleiner Veranstaltungskalender. Die öffentliche Terminseite wird regelmäßig korrigiert. Besucher sollen einen aktuellen Stand erhalten. Daneben gibt es eine angemeldete Verwaltung mit unveröffentlichten Entwürfen und Kontaktdaten. Diese beiden Bereiche benötigen unterschiedliche Überlegungen zur Zwischenspeicherung.

Schreibe für den Bauauftrag zunächst auf, welche Inhalte öffentlich sind und welche nur nach einer Berechtigungsprüfung erscheinen. Lege dann die vorgesehenen Cache-Regeln gemeinsam mit dem Betreiber fest. Verlange, dass private Antworten niemals versehentlich über einen gemeinsam genutzten Cache anderen Personen ausgeliefert werden. Der Header ersetzt dabei nicht die Anmeldung oder die Rechteprüfung des Servers.

Aktualität mit einer sichtbaren Änderung prüfen

Ändere in einer eigenen Testumgebung einen harmlosen öffentlichen Termintext. Rufe die Seite normal neu auf und kontrolliere im Netzwerkprotokoll, welche Antwort tatsächlich verwendet wird. Teste zusätzlich einen zweiten Browser. Ein erzwungenes Neuladen allein ist kein ausreichender Nachweis für den normalen Besucherweg, weil es das Cacheverhalten verändern kann.

Für die Verwaltung meldest du dich mit einem Testkonto an, öffnest einen Entwurf und meldest dich wieder ab. Prüfe anschließend direkte Aufrufe geschützter URLs. Der Server muss den Zugriff weiterhin anhand der aktuellen Anmeldung beurteilen. Untersuche gesondert, was die Zurückfunktion zeigt, statt diese Frage durch eine vermutete Wirkung von „no-store“ zu beantworten.

Eine wartbare Regel festhalten

Dokumentiere die beabsichtigte Strategie pro Seitentyp: öffentliche Inhalte, unveränderliche Dateien und angemeldete Bereiche. Halte auch fest, ob ein Service Worker oder anderer Anwendungsspeicher beteiligt ist. Neue Seiten können dann gegen diese Einteilung geprüft werden.

Die praktische Abnahme besteht aus nachvollziehbaren Antworten und Zugriffsprüfungen. Ein Header ist eine Anweisung innerhalb dieses Systems. Erst die Verbindung aus korrekter Zugriffskontrolle, passender Cachekonfiguration und realen Browserprüfungen zeigt, ob dein Projekt die gewünschte Trennung erreicht.