304 Not Modified: waarom het een succes is, geen fout

Hoe een 304 ontstaat

Een 304 is de tweede helft van een gesprek in twee stappen. Bij het eerste verzoek geeft de server de resource terug met een validator: een ETag, een ondoorzichtige identifier voor precies die versie, en vaak een datum Last-Modified. De client slaat het antwoord samen met die validators op.

Later, wanneer de gecachete kopie opnieuw gevalideerd moet worden, herhaalt de client het verzoek en voegt toe wat hij heeft:

• If-None-Match: "abc123" draagt de opgeslagen ETag. Dit is de voorkeursvalidator omdat hij exact is.
• If-Modified-Since: Wed, 03 Sep 2026 10:00:00 GMT draagt de opgeslagen datum, gebruikt wanneer er geen ETag is.

Is de resource niet veranderd, dan antwoordt de server 304 Not Modified met alleen headers en geen body, en rendert de client zijn gecachete kopie. Is ze wel veranderd, dan antwoordt de server met 200 en de nieuwe inhoud en nieuwe validators. Beide uitkomsten zijn correct gedrag.

Waarom een 304 goed nieuws is, geen fout

Mensen zien 304 in het netwerkpaneel van een browser of een loganalysator, merken dat het geen 200 is, en gaan ervan uit dat er iets mislukte. Er mislukte niets. Een 304 is het goedkoopste nuttige antwoord op het web: er gaat geen responsbody over het netwerk, dus is de overdracht een paar honderd bytes in plaats van het volledige bestand, en de server vermijdt meestal het opnieuw genereren van de resource, dus kost het minder CPU dan een 200 zou kosten. De pagina rendert sneller omdat de browser bytes hergebruikt die hij al heeft. Crawlers profiteren ook, want een stabiele ETag die 304's oplevert laat een zoekmachine zijn crawlbudget besteden aan pagina's die wel veranderden.

Een hoog aandeel 304's op statische assets is een teken dat caching goed is ingesteld. Het enige om in de gaten te houden is of u de revalidatie-omweg überhaupt nodig heeft: voor geversioneerde of fingerprinted assets vermijdt een lange Cache-Control: max-age met immutable zelfs de 304, want de browser vraagt het dan niet eens.

Wanneer een 304 een probleem is

• Een verouderde pagina die niet ververst. Wordt uw HTML geserveerd met een validator die nooit verandert terwijl de inhoud dat wel doet, dan blijven browsers 304 krijgen en blijven gebruikers de oude pagina zien. Dit is de klassieke bug "ik heb gedeployd maar niemand ziet het".
• Een 304 zonder overeenkomende gecachete kopie. Stuurt een client een voorwaardelijk verzoek waarvoor hij geen grond had, of strip een proxy de body van een 200, dan blijft de client met niets achter om te renderen en lijkt de pagina leeg.
• Zwakke of instabiele ETags achter een load balancer. Wanneer meerdere backends verschillende ETags genereren voor identieke inhoud, mist elke revalidatie en krijgt u volledige 200's waar 304's werden verwacht. Het verkeer stijgt zonder reden.
• Compressie die de validator verandert. Verschilt de ETag tussen gecomprimeerde en ongecomprimeerde varianten zonder correcte Vary: Accept-Encoding, dan kunnen caches het verkeerde serveren.

Hoe u voorwaardelijke verzoeken test

1. Haal de resource op en lees de validators:

   curl -sI https://example.com/style.css | grep -Ei "^(HTTP|etag|last-modified|cache-control)"

2. Herhaal het verzoek met de ETag die u kreeg en bevestig dat de server 304 antwoordt:

   curl -sI -H 'If-None-Match: "abc123"' https://example.com/style.css | head -n 1

   Vervang de exacte ETag-waarde, aanhalingstekens inbegrepen. Een 200 hier betekent dat revalidatie niet werkt.
3. Krijgt u 200 waar u 304 verwachtte, controleer dan of een proxy of CDN If-None-Match verwijdert, en of uw backends het eens zijn over de ETag voor hetzelfde bestand.
4. Krijgt u een verouderde pagina, zorg dan dat de validator verandert wanneer de inhoud verandert. Fingerprinted bestandsnamen zijn de betrouwbaarste oplossing; leid anders de ETag af van de inhoud zelf.
5. Houd HTML op een korte versheidsduur en laat assets de lange dragen. HTML die een dag wordt gecachet, is wat een deploy onzichtbaar maakt.

Waarom uptimecontroles nooit een 304 zien

Een uptimecontrole vraagt een pagina op als eerstemaalse bezoeker, zonder If-None-Match en zonder If-Modified-Since, dus heeft de server niets om tegen te vergelijken en antwoordt altijd met 200. Dat is de juiste standaard voor beschikbaarheid. Het betekent ook dat cachingregressies helemaal niet in uptimedata verschijnen: een site kan iedereen een verouderde pagina serveren terwijl elke controle groen blijft. Controleer ook de pagina-inhoud naast de status, en een pagina die stopte met bijwerken wordt zichtbaar als een inhoudsmismatch. HostTracker biedt 13 monitortypen en bewaakt websites sinds 2004. Test headers en status met de HTTP-controletool, en lees wat een 200 OK echt bewijst en de volledige handleiding 3xx-familie.