Kalkulator for utløpstid i HTTP-cache
Skriv inn verdiene for Cache-Control, Expires, Date og Age i et svar, tidspunktet det ble mottatt og tidspunktet som skal kontrolleres. Kalkulatoren gir friskhetsperioden, den nåværende alderen og om svaret fortsatt er ferskt.
Hva denne kalkulatoren gjør
Den dekker én del av RFC 9111, HTTP-standarden for hurtiglagring: friskhetsberegningen. Det er delen som avgjør om et lagret svar kan gjenbrukes uten å kontrollere med opprinnelsesserveren. Validering (ETag, If-Modified-Since, 304), Vary og Cache-Control på forespørselssiden dekkes ikke.
Friskhet er ikke en oppdatering og ikke en sletting
At et svar er foreldet betyr bare at en cache ikke kan gjenbruke det uten å kontrollere først. Det betyr ikke at nettleserskjermen oppdateres av seg selv, og det betyr ikke at filen på opprinnelsesserveren endres eller slettes. På samme måte betyr det at et svar er ferskt ikke at filen på serveren ikke har endret seg. Expires-hodet, sier standarden, «does not imply that the original resource will change or cease to exist at, before, or after that time». Denne kalkulatoren regner bare ut tidsregningen for den hurtiglagrede kopien.
Friskhetsperiode og nåværende alder
- Friskhetsperiode: den tidslengden svaret kan forbli «ferskt». Den bestemmes av selve svaret (Cache-Control eller Expires) og endrer seg ikke etter hvert som tiden går.
- Nåværende alder: tiden som har gått siden svaret ble generert. Den øker etter hvert som tiden går.
- Er det ferskt? Svaret er ferskt bare når friskhetsperioden er større enn nåværende alder (når de er like, er det foreldet).
- Gjenstående friskhet = friskhetsperiode − nåværende alder.
Hvilken verdi som bestemmer friskhetsperioden
Etter avsnitt 4.2.1 i RFC 9111 brukes den første som passer:
| Rekkefølge | Delt cache (CDN, proxy) | Privat cache (nettleser) |
|---|---|---|
| 1 | s-maxage | (s-maxage brukes ikke) |
| 2 | max-age | max-age |
| 3 | Expires − Date | Expires − Date |
| 4 | Hvis ingen finnes, er det ingen eksplisitt utløpstid | Det samme |
- Hvis max-age finnes, ignoreres Expires. I en delt cache ignoreres max-age og Expires hvis s-maxage finnes (avsnitt 5.3).
- Hvis det samme direktivet forekommer mer enn én gang, brukes det første (en av tilnærmingene standarden tillater).
- En max-age eller s-maxage som ikke er et heltall, eller står i anførselstegn (standarden sier at en avsender ikke må generere den siterte formen), behandles som ugyldig, og svaret regnes som foreldet (friskhetsperiode 0). En verdi over 2 147 483 648 behandles som 2 147 483 648 (avsnitt 1.2.2).
- Hvis Expires er
0eller en dato som ikke finnes, behandles svaret som allerede utløpt (avsnitt 5.3). - Når det ikke finnes noen eksplisitt utløpstid, beregnes ikke heuristisk ferskhet (for eksempel et overslag ut fra Last-Modified). Standarden overlater den heuristiske levetiden til implementeringen.
Slik beregnes gjeldende alder
Formlene er fra avsnitt 4.2.3 i RFC 9111:
- Tilsynelatende alder = max(0, mottakstidspunkt − Date)
- Alder ved mottak = max(tilsynelatende alder, Age-header + svarforsinkelse)
- Gjeldende alder = alder ved mottak + tid siden svaret ble mottatt
Denne kalkulatoren spør ikke etter tidspunktet forespørselen ble sendt, så den setter svarforsinkelsen (tiden fra forespørselen ble sendt til svaret ble mottatt) til 0. På en forbindelse med stor forsinkelse kan den beregnede alderen bli mindre enn den virkelige. Standarden tillater også å bruke bare Age-headeren pluss forsinkelsen.
Regler for inndata
- Skriv inn 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); tidssoner håndteres ikke. Året må være fra 1900 til 2100, og sekundene fra 0 til 59 (et skuddsekund, 60, godtas ikke). Ukedagsnavnet kontrolleres ikke mot datoen. - Formatene RFC 850 og asctime er formater som HTTP-mottakere forventes å godta, men denne kalkulatoren støtter dem ikke. (Det betyr ikke at de er ugyldige i HTTP. Konverter verdien til en IMF-fixdate.)
- Hvis Date er tom, brukes tidspunktet du skriver inn som «Tidspunkt svaret ble mottatt» i stedet for Date. RFC 9110 sier at en mottaker som får et svar uten Date, registrerer mottakstidspunktet og legger det til som Date. Hvis dette tidspunktet også er tomt, kan beregningene som trenger Date (Expires − Date og tilsynelatende alder) ikke utføres. Nettleserens gjeldende tid brukes aldri automatisk; den fylles inn bare når du trykker på knappen «gjeldende tid», i feltet «Tidspunkt for kontroll».
- Tidspunktet som skal kontrolleres må ikke være tidligere enn tidspunktet svaret ble mottatt.
Andre Cache-Control-direktiver
De brukes ikke i beregningen, men vises som merknader om gjenbruk.
- no-store: må ikke lagres. private: en delt cache må ikke lagre det (en nettleser kan).
- no-cache (uten argumenter): selv mens svaret er ferskt, kan det ikke gjenbrukes uten validering.
- must-revalidate: når svaret er utgått, må det ikke brukes uten validering. proxy-revalidate: det samme, men gjelder ikke for en privat cache.
- public: tillater uttrykkelig lagring.
- immutable (RFC 8246) og stale-while-revalidate og stale-if-error (RFC 5861) ligger utenfor RFC 9111. De gjenkjennes, men brukes ikke i beregningen.
Eksempler
| Inndata | Resultat |
|---|---|
| max-age=3600, ingen Age, 1800 s etter mottak | Ferskhetslevetid 3600 s, gjeldende alder 1800 s, 1800 s igjen (fersk) |
| Det samme, ved nøyaktig 3600 s | Gjeldende alder 3600 s. Den er lik ferskhetslevetiden, så svaret er utgått |
| max-age=3600, Age=600, nettopp mottatt | Gjeldende alder 600 s, 3000 s igjen |
| Delt cache med s-maxage=60, max-age=3600 | Ferskhetslevetid 60 s (max-age ignoreres) |
Godt å vite
- Dette er en beregning basert på standarden. Virkelige nettlesere og CDN-er oppfører seg ikke alltid nøyaktig slik standarden beskriver. Handlinger som tvungen omlasting og CDN-spesifikke innstillinger kan gi andre resultater. Oppførselen til et bestemt produkt er ikke garantert.
- Heuristisk ferskhet, validering, Vary, forespørselsdirektiver og sammenlegging av flere cacher dekkes ikke.
Kilder og kontroller
Følgende ble kontrollert mot den fullstendige teksten i standardene 1. november 2026:
- RFC 9111, «HTTP Caching»: https://www.rfc-editor.org/rfc/rfc9111 (avsnitt 1.2.2, 4.2.1, 4.2.3, 5.1, 5.2.2 og 5.3, inkludert ferskhetstesten
freshness_lifetime > current_age) - RFC 9110, «HTTP Semantics»: https://www.rfc-editor.org/rfc/rfc9110 (avsnitt 5.6.7 og 6.6.1)
Denne kalkulatoren følger disse avsnittene bare for ferskhet. At en beregning går igjennom, er ikke en påstand om at et produkt eller en server er i samsvar med standarden.
Vanlige spørsmål
Hva skjer når både max-age og Expires er til stede?
max-age har forrang, og Expires ignoreres (RFC 9111, avsnitt 5.3).
Gjelder s-maxage for en nettleser?
s-maxage er et direktiv for delte cacher. En privat cache (en nettleser) bruker det ikke.
Hva er Age-headeren?
Det er antall sekunder, skrevet av en cache underveis, siden svaret ble generert eller sist kontrollert hos opprinnelsesserveren. Denne kalkulatoren bruker den til å finne gjeldende alder.
Forsvinner eller oppdateres et utgått svar av seg selv?
Nei. Utgått betyr bare at en cache må kontrollere før den gjenbruker det. Det oppdaterer ikke skjermen og endrer ingenting på opprinnelsesserveren.
Hvordan kan jeg kontrollere et tidspunkt?
Unix-tidsomregneren og Cron-uttrykkskalkulatoren kan hjelpe.