Beregner for HTTP-cache-udløb
Indtast værdierne for Cache-Control, Expires, Date og Age for et svar, tidspunktet for modtagelsen og tidspunktet for kontrollen. Beregneren giver friskhedsperioden, den aktuelle alder og om svaret stadig er frisk.
Hvad denne beregner gør
Den dækker én del af RFC 9111, HTTP-standarden for caching: friskhedsberegningen. Det er den del, der afgør, om et gemt svar må genbruges uden at kontrollere med oprindelsesserveren. Validering (ETag, If-Modified-Since, 304), Vary og Cache-Control på anmodningssiden er ikke dækket.
Friskhed er ikke en opdatering og ikke en sletning
At et svar er forældet betyder kun, at en cache ikke må genbruge det uden først at kontrollere. Det betyder ikke, at browserens skærm opdateres af sig selv, og det betyder ikke, at filen på oprindelsesserveren ændres eller slettes. På samme måde betyder det, at et svar er frisk, ikke, at filen på serveren ikke er ændret. Om Expires-headeren siger standarden, at den "does not imply that the original resource will change or cease to exist at, before, or after that time". Denne beregner udregner kun tidsaritmetikken for den cachede kopi.
Friskhedsperiode og aktuel alder
- Friskhedsperiode: den tidslængde, svaret kan forblive "frisk". Den fastsættes af selve svaret (Cache-Control eller Expires) og ændrer sig ikke, efterhånden som tiden går.
- Aktuel alder: den tid, der er gået, siden svaret blev genereret. Den vokser, efterhånden som tiden går.
- Er det frisk? Svaret er kun frisk, når friskhedsperioden er større end den aktuelle alder (når de er lige store, er det forældet).
- Resterende friskhed = friskhedsperiode − aktuel alder.
Hvilken værdi der fastsætter friskhedsperioden
Efter afsnit 4.2.1 i RFC 9111 bruges det første match:
| Rækkefølge | Delt cache (CDN, proxy) | Privat cache (browser) |
|---|---|---|
| 1 | s-maxage | (s-maxage bruges ikke) |
| 2 | max-age | max-age |
| 3 | Expires − Date | Expires − Date |
| 4 | Hvis ingen er til stede, er der ingen eksplicit udløbstid | Det samme |
- Hvis max-age er til stede, ignoreres Expires. I en delt cache ignoreres max-age og Expires, hvis s-maxage er til stede (afsnit 5.3).
- Hvis det samme direktiv optræder mere end én gang, bruges det første (en af de fremgangsmåder, standarden tillader).
- En max-age eller s-maxage, der ikke er et heltal eller står i anførselstegn (standarden siger, at en afsender ikke må generere den form med anførselstegn), behandles som ugyldig, og svaret anses for at være forældet (friskhedsperiode 0). En værdi over 2.147.483.648 behandles som 2.147.483.648 (afsnit 1.2.2).
- Hvis Expires er
0eller en dato, der ikke findes, behandles svaret som allerede udløbet (afsnit 5.3). - Når der ikke er nogen eksplicit udløbstid, beregnes heuristisk friskhed (for eksempel et skøn ud fra Last-Modified) ikke. Standarden overlader den heuristiske levetid til implementeringen.
Sådan beregnes den aktuelle alder
Formlerne er fra afsnit 4.2.3 i RFC 9111:
- Tilsyneladende alder = max(0, modtagelsestidspunkt − Date)
- Alder ved modtagelse = max(tilsyneladende alder, Age-header + svarforsinkelse)
- Aktuel alder = alder ved modtagelse + tid siden modtagelsen
Denne beregner spørger ikke om tidspunktet, hvor forespørgslen blev sendt, så den sætter svarforsinkelsen (tiden fra afsendelse af forespørgslen til modtagelse af svaret) til 0. Ved en forbindelse med stor forsinkelse kan den beregnede alder være mindre end den reelle. Standarden tillader også at bruge Age-headeren plus forsinkelsen alene.
Regler for indtastning
- Indtast datoer som en IMF-fixdate (for eksempel
Sun, 06 Nov 1994 08:49:37 GMT) eller som et UTC-tidspunkt som2026-10-21 07:28:00. Alt er i UTC (GMT); tidszoner håndteres ikke. Året skal være fra 1900 til 2100 og sekunderne fra 0 til 59 (et skudsekund, 60, accepteres ikke). Ugedagen kontrolleres ikke mod datoen. - Formaterne RFC 850 og asctime er formater, som HTTP-modtagere forventes at acceptere, men denne beregner understøtter dem ikke. (Det betyder ikke, at de er ugyldige i HTTP. Konvertér værdien til en IMF-fixdate.)
- Hvis Date er tom, bruges det tidspunkt, du indtaster som "Tidspunkt for modtagelse af svaret", i stedet for Date. RFC 9110 siger, at en modtager, der får et svar uden Date, registrerer modtagelsestidspunktet og tilføjer det som Date. Hvis det tidspunkt også er tomt, kan de beregninger, der kræver Date (Expires − Date og den tilsyneladende alder), ikke udføres. Browserens aktuelle tid bruges aldrig automatisk; den indsættes kun, når du trykker på knappen "aktuel tid", i feltet "Tidspunkt for kontrol".
- Tidspunktet for kontrol må ikke ligge før tidspunktet for modtagelse af svaret.
Andre Cache-Control-direktiver
De bruges ikke i beregningen, men vises som bemærkninger om genbrug.
- no-store: må ikke gemmes. private: en delt cache må ikke gemme det (en browser må).
- no-cache (uden argumenter): selv når svaret er frisk, kan det ikke genbruges uden validering.
- must-revalidate: når svaret er forældet, må det ikke bruges uden validering. proxy-revalidate: det samme, men gælder ikke for en privat cache.
- public: tillader eksplicit lagring.
- immutable (RFC 8246) samt stale-while-revalidate og stale-if-error (RFC 5861) ligger uden for RFC 9111. De genkendes, men bruges ikke i beregningen.
Eksempler
| Indtastning | Resultat |
|---|---|
| max-age=3600, ingen Age, 1.800 s efter modtagelsen | Friskhedslevetid 3.600 s, aktuel alder 1.800 s, 1.800 s tilbage (frisk) |
| Det samme, ved præcis 3.600 s | Aktuel alder 3.600 s. Den er lig med friskhedslevetiden, så svaret er forældet |
| max-age=3600, Age=600, netop modtaget | Aktuel alder 600 s, 3.000 s tilbage |
| Delt cache med s-maxage=60, max-age=3600 | Friskhedslevetid 60 s (max-age ignoreres) |
Godt at vide
- Dette er en beregning baseret på standarden. Rigtige browsere og CDN'er opfører sig ikke altid præcis, som standarden beskriver. Handlinger som en tvungen genindlæsning og CDN-specifikke indstillinger kan give andre resultater. Et bestemt produkts adfærd er ikke garanteret.
- Heuristisk friskhed, validering, Vary, forespørgselsdirektiver og sammenlægning af flere cacher er ikke omfattet.
Kilder og kontrol
Følgende blev kontrolleret mod standardernes fulde tekst den 1. november 2026:
- RFC 9111, "HTTP Caching": https://www.rfc-editor.org/rfc/rfc9111 (afsnit 1.2.2, 4.2.1, 4.2.3, 5.1, 5.2.2 og 5.3, herunder friskhedstesten
freshness_lifetime > current_age) - RFC 9110, "HTTP Semantics": https://www.rfc-editor.org/rfc/rfc9110 (afsnit 5.6.7 og 6.6.1)
Denne beregner følger disse afsnit kun for friskhedens vedkommende. At en beregning består, er ikke en påstand om, at et produkt eller en server overholder standarden.
Ofte stillede spørgsmål
Hvad sker der, når både max-age og Expires er til stede?
max-age har forrang, og Expires ignoreres (RFC 9111, afsnit 5.3).
Gælder s-maxage for en browser?
s-maxage er et direktiv for delte cacher. En privat cache (en browser) bruger det ikke.
Hvad er Age-headeren?
Det er antallet af sekunder, skrevet af en cache undervejs, siden svaret blev genereret eller sidst kontrolleret hos oprindelsesserveren. Denne beregner bruger det til at finde den aktuelle alder.
Forsvinder eller opdateres et forældet svar af sig selv?
Nej. Forældet betyder blot, at en cache skal kontrollere svaret, før det genbruges. Det opdaterer ikke skærmen og ændrer intet på oprindelsesserveren.
Hvordan kan jeg kontrollere et tidspunkt?
Unix-tidsstempel-omregneren og Cron-udtryksberegneren kan hjælpe.