publicErlaubt gemeinsame Speicherung, wenn auch die übrigen Bedingungen erfüllt sind.
Zeile 1, Spalte 16
HTTP & Request Debugging
Cache-Control-GeneratorSpeichern und Wiederverwenden unterscheiden
Antwort-Header einfügen oder per Formular erstellen. Das aktuelle Alter wird für das Beispiel angenommen.
Cache-Control-Generator
Header und Formularwerte bleiben in diesem Browser. Es werden keine Origin-Anfragen gesendet.
Browser / privater Cache
In diesem Altersbeispiel frisch
max-age: Laufzeit 3600 Sekunden
Verbleibendes Frischebudget: 3600 Sekunden
Gemeinsamer Cache / CDN
In diesem Altersbeispiel frisch
s-maxage: Laufzeit 86400 Sekunden
Verbleibendes Frischebudget: 86400 Sekunden
Nach Ablauf verlangen diese Direktiven vor Wiederverwendung eine Validierung.
Vorausgesetzt werden eine gespeicherte Antwort und das unten angegebene Alter. Frische garantiert weder Speicherung noch Wiederverwendung; weitere Header und Plattformregeln gelten weiterhin.
current_age als Wert von 0 bis 2147483648 annehmen. Age allein umfasst nicht alle Übertragungs- und Verweilzeiten. Dies ist ein statisches Beispiel.
Analysierte Direktiven
max-age=3600Frischezeit privater Caches und gemeinsamer Caches ohne s-maxage.
Zeile 1, Spalte 24
s-maxage=86400Überschreibt max-age für gemeinsame Caches, nicht für Browser.
Zeile 1, Spalte 38
3 von 3 Direktiven angezeigt
Hinweise zur Richtlinie
In den modellierten Direktiven wurden keine Probleme erkannt. Die Bereitstellung ist damit nicht geprüft.
3 Direktiven · 0 Hinweise
Wenn der Browser erneut anfragt, kann der gemeinsame Cache dieselbe Antwort noch frisch halten. Der Cache-Control-Generator stellt beide Laufzeiten getrennt dar. So lässt sich ein vermeintlicher Widerspruch im HTTP-Caching anhand konkreter Werte untersuchen.
Sie können einen Cache-Control-Header erstellen oder eine vorhandene Antwort analysieren. Der Browser-Cache und der gemeinsame Cache werden getrennt betrachtet; unbekannte Erweiterungen bleiben beim Wechsel ins Formular im ursprünglichen Eingabefeld erhalten.
Warum dieser Cache-Control-Generator hilft
Die ursprünglichen Hinweise behalten
Der Cache-Control-Generator entfernt weder doppelte Direktiven noch unbekannte Erweiterungen. Das Komma in private="X-Foo, X-Bar" gehört zum Argument. Das getrennte Formular erzeugt eine neue Richtlinie, ohne die untersuchte Eingabe zu überschreiben.
Zwei Laufzeiten, dasselbe Alter
Im Beispiel gelten max-age=3600 und s-maxage=86400. Mit einem angenommenen Alter von 4000 Sekunden ist die Browser-Antwort bereits veraltet, die gemeinsame Kopie hat noch 82400 Sekunden Frischebudget. Das ist keine Zusage eines Cache-Treffers.
Drei Entscheidungen vor der Laufzeitwahl
01
Nur das richtige Feld einfügen
Erlaubt sind ein einzelner Feldwert oder mehrere Cache-Control:-Zeilen. Ein vollständiger Antwortblock mit Age oder ETag wird zurückgewiesen. Dadurch verschwinden fremde Felder nicht unbemerkt aus einer vermeintlich vollständigen Prüfung.
02
Leer und null unterscheiden
Ein leeres Zeitfeld lässt die Direktive weg; 0 erzeugt ausdrücklich null Sekunden. Beispiel und Leeren zeigen zuerst eine Ersetzungsvorschau. Rückgängig stellt beide Eingaben, das Alter und das vorherige Ergebnis einmal wieder her.
03
Die Altersannahme variieren
Automatisch wird 350 ms nach der Bearbeitung analysiert. Ausgeschaltet stehen die Schaltfläche und Ctrl/Cmd + Enter bereit. Änderungen sperren den Export alter Ergebnisse sofort. Das Alter ist ein statischer Beispielwert, kein gemessener Countdown.
Direktiven, Argumente und Auswirkungen
Argumente mit Positionen lesen
Namen werden ohne Beachtung der Großschreibung erkannt und klein ausgegeben. Argumente, Anführungszeichen, Reihenfolge und Wiederholungen bleiben erhalten. Leere Listenelemente werden übersprungen; jede Direktive erhält Zeile und Spalte.
Antwortdirektiven zusammenstellen
Neun Schalter und vier Zeitfelder decken die üblichen Einstellungen ab. max-age, s-maxage, stale-while-revalidate und stale-if-error nehmen ganze Sekunden bis 2147483648 an. Widersprüchliche Auswahl wird erläutert und nicht automatisch entfernt.
Frische von Wiederverwendung trennen
max-age und s-maxage bestimmen unterschiedliche Laufzeiten. Gewöhnliches no-cache fordert vor Wiederverwendung eine erfolgreiche Validierung; no-store untersagt das Speichern. Eine positive Laufzeit allein bestätigt keine vollständige Speicherberechtigung.
Unsichere Aussagen kenntlich machen
Unbekannte Erweiterungen, feldbezogene Einschränkungen und must-understand benötigen Kontext. Bei doppelten bekannten Direktiven oder ungültigen Argumenten wird kein eindeutiger Zahlenwert abgeleitet. Kopie und Textdatei enthalten alle Direktiven, auch bei einer Anzeige in Gruppen zu 50.
Die Aussagekraft eines einzelnen Headers
- Nur Antwort-Cache-Control
- Es gibt keine URL-Abfrage, Request-Simulation oder gemeinsame Auswertung mit ETag, Vary und Expires. Request-Direktiven bleiben mit einem Hinweis erhalten. Serverkonfiguration, Upload und Stapeldateien gehören nicht zu diesem Werkzeug.
- Keine tatsächliche Ablaufzeit
- Die Rechnung zieht das angenommene Alter von der Laufzeit ab. Date-Korrektur, Übertragung und Verweildauer werden nicht berechnet. Ohne explizite Laufzeit können weiterhin Expires oder heuristische Regeln wirken; das Ergebnis lautet deshalb nicht automatisch „nicht cachebar“.
- Keine Herstellerprüfung
- CDN-Regeln, Authentifizierung, Statuscode und Cache-Schlüssel beeinflussen den Betrieb. Keine Hinweise bedeutet keine Freigabe für die Produktion. Dieses Werkzeug leert keine Caches und garantiert weder Speicherung noch Treffer.
- Begrenzte Eingaben
- Maximal 16384 UTF-16-Einheiten und 128 Direktiven sind zulässig. Syntaxfehler sperren den Export und nennen ihre Position. Zu große gelesene Sekunden bleiben als Text sichtbar, ohne numerische Schlussfolgerung. Formular und Alter erlauben höchstens 2147483648.
- Veraltete Antworten bleiben veraltet
- stale-while-revalidate und stale-if-error werden nicht zur Frischezeit addiert. Sie gestatten bedingte Wiederverwendung nach deren Ende. Zusammen mit strengen Validierungsvorgaben erscheint ein Hinweis; die konkrete Umsetzung wird nicht simuliert.
Fragen zum Cache-Control-Generator
Wie unterscheiden sich no-cache und no-store beim Speichern?
Gewöhnliches no-cache erlaubt Speicherung, verlangt aber vor jeder Wiederverwendung eine erfolgreiche Validierung. no-store untersagt die Speicherung der Antwort. Beide sind keine Befehle zum Löschen sämtlicher bereits vorhandener Kopien.
Wofür ist immutable bei Cache-Control gedacht?
immutable kennzeichnet einen während seiner Frischezeit unveränderten Inhalt und kann normale Validierungen vermeiden. Es setzt keine Laufzeit und verhindert nicht jede erzwungene Aktualisierung. Nach Ablauf gelten die normalen Regeln. Argumente werden ignoriert; Wiederholungen entsprechen einem einzelnen Vorkommen.
Welche Caches betreffen max-age und s-maxage?
max-age gilt für private Caches und gemeinsame Caches ohne überschreibendes s-maxage. s-maxage legt die Laufzeit gemeinsamer Caches fest und verlangt nach Ablauf Validierung. Die Browser-Laufzeit wird dadurch nicht verlängert.
Wie entscheide ich zwischen public und private?
public kommt für zwischen Nutzern teilbare Antworten infrage; private schränkt gewöhnlich auf einen privaten Cache ein. Inhalt und Authentifizierung müssen trotzdem passen. private ist keine Verschlüsselung, und die Form mit einer Feldliste hat eine differenziertere Bedeutung.
Was passiert mit stale-while-revalidate nach Ablauf der Frischezeit?
Innerhalb des angegebenen Zeitfensters kann eine veraltete Antwort während eines Validierungsversuchs im Hintergrund verwendet werden. Das setzt passende Anfragen und Unterstützung voraus. Es entsteht weder zusätzliche Frische noch eine Garantie, dass der Cache die alte Antwort liefert.
Stimmt etwas nicht?
Die Richtlinie vor dem Einsatz prüfen
Cache-Control-Generator: Prüfen Sie den Header mit einem passenden angenommenen Alter und vergleichen Sie beide Caches vor dem Kopieren.