HTTP-cacheverloopcalculator
Voer de waarden van Cache-Control, Expires, Date en Age van een respons in, het tijdstip van ontvangst en het tijdstip om te controleren. De calculator geeft de versheidsduur, de huidige leeftijd en of de respons nog vers is.
Wat deze calculator doet
Ze behandelt één onderdeel van RFC 9111, de HTTP-cachenorm: de versheidsberekening. Dat is het onderdeel dat beslist of een opgeslagen respons zonder controle bij de oorspronkelijke server mag worden hergebruikt. Validatie (ETag, If-Modified-Since, 304), Vary en Cache-Control aan de aanvraagzijde worden niet behandeld.
Versheid is geen verversing en geen verwijdering
Een respons die verlopen is, betekent alleen dat een cache haar niet mag hergebruiken zonder eerst te controleren. Het betekent niet dat het browserscherm zichzelf ververst, en niet dat het bestand op de oorspronkelijke server wordt gewijzigd of verwijderd. Evenzo betekent een verse respons niet dat het bestand op de server niet is veranderd. De Expires-header, zegt de norm, „impliceert niet dat de oorspronkelijke bron op, voor of na dat tijdstip zal veranderen of ophouden te bestaan”. Deze calculator werkt alleen de tijdrekenkunde van de gecachete kopie uit.
Versheidsduur en huidige leeftijd
- Versheidsduur: de tijdsduur dat de respons „vers” kan blijven. Ze wordt door de respons zelf bepaald (Cache-Control of Expires) en verandert niet naarmate de tijd verstrijkt.
- Huidige leeftijd: de tijd die is verstreken sinds de respons werd gegenereerd. Ze groeit naarmate de tijd verstrijkt.
- Is ze vers? De respons is alleen vers wanneer de versheidsduur groter is dan de huidige leeftijd (wanneer ze gelijk zijn, is ze verlopen).
- Resterende versheid = versheidsduur − huidige leeftijd.
Welke waarde de versheidsduur bepaalt
Volgens sectie 4.2.1 van RFC 9111 wordt de eerste overeenkomst gebruikt:
| Volgorde | Gedeelde cache (CDN, proxy) | Privécache (browser) |
|---|---|---|
| 1 | s-maxage | (s-maxage wordt niet gebruikt) |
| 2 | max-age | max-age |
| 3 | Expires − Date | Expires − Date |
| 4 | Als er geen is, is er geen expliciete vervaltijd | Hetzelfde |
- Als max-age aanwezig is, wordt Expires genegeerd. In een gedeelde cache worden, als s-maxage aanwezig is, max-age en Expires genegeerd (sectie 5.3).
- Als dezelfde richtlijn meer dan eens voorkomt, wordt de eerste gebruikt (een van de benaderingen die de norm toestaat).
- Een max-age of s-maxage die geen geheel getal is, of tussen aanhalingstekens staat (de norm zegt dat een verzender de vorm met aanhalingstekens niet mag genereren), wordt als ongeldig behandeld en de respons wordt als verlopen beschouwd (versheidsduur 0). Een waarde boven 2.147.483.648 wordt als 2.147.483.648 behandeld (sectie 1.2.2).
- Als Expires
0is of een datum die niet bestaat, wordt de respons als al verlopen behandeld (sectie 5.3). - Wanneer er geen expliciete vervaltijd is, wordt heuristische versheid (bijvoorbeeld een schatting uit Last-Modified) niet berekend. De norm laat de heuristische levensduur aan de implementatie over.
Hoe de huidige leeftijd wordt berekend
De formules komen uit sectie 4.2.3 van RFC 9111:
- Schijnbare leeftijd = max(0, ontvangsttijd − Date)
- Leeftijd bij ontvangst = max(schijnbare leeftijd, Age-header + responsvertraging)
- Huidige leeftijd = leeftijd bij ontvangst + tijd sinds ontvangst
Deze calculator vraagt niet naar het tijdstip waarop de aanvraag is verzonden, dus ze neemt de responsvertraging (de tijd van het verzenden van de aanvraag tot het ontvangen van de respons) als 0. Bij een verbinding met veel vertraging kan de berekende leeftijd kleiner zijn dan de werkelijke. De norm staat ook toe alleen de Age-header plus de vertraging te gebruiken.
Regels voor de invoer
- Voer datums in als IMF-fixdate (bijvoorbeeld
Sun, 06 Nov 1994 08:49:37 GMT) of als UTC-tijd zoals2026-10-21 07:28:00. Alles is in UTC (GMT); tijdzones worden niet verwerkt. Het jaar moet van 1900 tot 2100 zijn en de seconden van 0 tot 59 (een schrikkelseconde, 60, wordt niet geaccepteerd). De dagnaam wordt niet met de datum vergeleken. - De formaten RFC 850 en asctime zijn formaten die HTTP-ontvangers worden verwacht te accepteren, maar deze calculator ondersteunt ze niet. (Dat betekent niet dat ze in HTTP ongeldig zijn. Zet de waarde om naar een IMF-fixdate.)
- Als Date leeg is, wordt de tijd die u invoert bij „Tijdstip van ontvangst van de respons” in plaats van Date gebruikt. RFC 9110 zegt dat een ontvanger die een respons zonder Date ontvangt, het tijdstip van ontvangst vastlegt en dat als Date toevoegt. Als dat tijdstip ook leeg is, kunnen de berekeningen die Date nodig hebben (Expires − Date en de schijnbare leeftijd) niet worden gedaan. De huidige tijd van de browser wordt nooit automatisch gebruikt; ze wordt alleen ingevuld wanneer u op de knop „huidige tijd” drukt, in het veld „Tijdstip om te controleren”.
- Het te controleren tijdstip mag niet eerder zijn dan het tijdstip van ontvangst van het antwoord.
Andere Cache-Control-richtlijnen
Ze worden niet in de berekening gebruikt, maar worden als opmerkingen over hergebruik getoond.
- no-store: mag niet worden opgeslagen. private: een gedeelde cache mag haar niet opslaan (een browser wel).
- no-cache (zonder argumenten): zelfs terwijl ze vers is, kan ze niet zonder validatie worden hergebruikt.
- must-revalidate: zodra ze verlopen is, mag ze niet zonder validatie worden gebruikt. proxy-revalidate: hetzelfde, maar het geldt niet voor een privécache.
- public: staat opslaan uitdrukkelijk toe.
- immutable (RFC 8246) en stale-while-revalidate en stale-if-error (RFC 5861) vallen buiten RFC 9111. Ze worden herkend maar niet in de berekening gebruikt.
Voorbeelden
| Invoer | Resultaat |
|---|---|
| max-age=3600, geen Age, 1.800 s na ontvangst | Versheidsduur 3.600 s, huidige leeftijd 1.800 s, 1.800 s resterend (vers) |
| Hetzelfde, op precies 3.600 s | Huidige leeftijd 3.600 s. Ze is gelijk aan de versheidsduur, dus ze is verlopen |
| max-age=3600, Age=600, net ontvangen | Huidige leeftijd 600 s, 3.000 s resterend |
| Gedeelde cache met s-maxage=60, max-age=3600 | Versheidsduur 60 s (max-age wordt genegeerd) |
Goed om te weten
- Dit is een berekening op basis van de norm. Echte browsers en CDN's gedragen zich niet altijd precies zoals de norm beschrijft. Handelingen zoals een geforceerd herladen en CDN-specifieke instellingen kunnen andere resultaten geven. Het gedrag van een bepaald product wordt niet gegarandeerd.
- Heuristische versheid, validatie, Vary, aanvraagrichtlijnen en het optellen van meerdere caches worden niet behandeld.
Bronnen en controles
Het volgende is op 1 november 2026 gecontroleerd aan de hand van de volledige tekst van de normen:
- RFC 9111, „HTTP Caching”: https://www.rfc-editor.org/rfc/rfc9111 (secties 1.2.2, 4.2.1, 4.2.3, 5.1, 5.2.2 en 5.3, inclusief de versheidstest
freshness_lifetime > current_age) - RFC 9110, „HTTP Semantics”: https://www.rfc-editor.org/rfc/rfc9110 (secties 5.6.7 en 6.6.1)
Deze calculator volgt die secties alleen voor versheid. Deze berekening doorstaan is geen bewering dat een product of een server aan de norm voldoet.
Veelgestelde vragen
Wat gebeurt er als zowel max-age als Expires aanwezig zijn?
max-age heeft voorrang en Expires wordt genegeerd (RFC 9111, sectie 5.3).
Is s-maxage van toepassing op een browser?
s-maxage is een richtlijn voor gedeelde caches. Een privécache (een browser) gebruikt haar niet.
Wat is de Age-header?
Het is het aantal seconden, geschreven door een cache onderweg, sinds de respons werd gegenereerd of voor het laatst bij de oorspronkelijke server werd gecontroleerd. Deze calculator gebruikt het om de huidige leeftijd te vinden.
Verdwijnt of ververst een verlopen respons vanzelf?
Nee. Verlopen betekent alleen dat een cache moet controleren voordat ze haar hergebruikt. Het ververst het scherm niet en verandert niets op de oorspronkelijke server.
Hoe kan ik een tijdstip controleren?
De Unix-timestampomzetter en de cron-expressiecalculator kunnen helpen.