304 Not Modified: proč jde o úspěch, ne o chybu

Jak 304 vzniká

304 je druhá polovina dvoukrokové konverzace. Při prvním požadavku server vrátí zdroj spolu s validátorem: ETag, což je neprůhledný identifikátor přesně dané verze, a často i datem Last-Modified. Klient si odpověď uloží spolu s těmito validátory.

Později, když je potřeba uloženou kopii přehodnotit, klient požadavek zopakuje a přiloží to, co má:

• If-None-Match: "abc123" nese uložený ETag. Jde o preferovaný validátor, protože je přesný.
• If-Modified-Since: Wed, 03 Sep 2026 10:00:00 GMT nese uložené datum, použije se, když ETag chybí.

Pokud se zdroj nezměnil, server odpoví 304 Not Modified jen s hlavičkami a bez těla, a klient vykreslí svou uloženou kopii. Pokud se zdroj změnil, server odpoví 200 s novým obsahem a novými validátory. Oba výsledky jsou správným chováním.

Proč je 304 dobrá zpráva, ne chyba

Lidé vidí 304 v síťovém panelu prohlížeče nebo v analyzátoru logů, všimnou si, že to není 200, a předpokládají, že něco selhalo. Neselhalo nic. 304 je nejlevnější užitečná odpověď na webu: sítí neprojde žádné tělo odpovědi, takže přenos je pár set bajtů místo celého souboru, a server se obvykle vyhne opětovnému vygenerování zdroje, takže stojí míň výpočetního výkonu než 200. Stránka se vykreslí rychleji, protože prohlížeč znovu použije bajty, které už má. Prospěch mají i crawlery, protože stabilní ETag produkující 304 nechává vyhledávač utratit svůj rozpočet procházení na stránky, které se skutečně změnily.

Vysoký podíl 304 u statických souborů je znamení, že je cachování dobře nastavené. Jediné, na co si dát pozor, je, zda vůbec potřebujete cestu tam a zpět kvůli přehodnocení: u verzovaných nebo otiskem opatřených souborů se dlouhé Cache-Control: max-age s immutable vyhne i 304, protože se prohlížeč vůbec neptá.

Kdy je 304 problém

• Zastaralá stránka, která se neobnoví. Pokud se váš HTML doručuje s validátorem, který se nemění, i když se obsah mění, prohlížeče dál dostávají 304 a uživatelé dál vidí starou stránku. Jde o klasickou chybu "nasadil jsem to, ale nikdo to nevidí".
• 304 bez odpovídající uložené kopie. Pokud klient odešle podmíněný požadavek, na který neměl důvod, nebo proxy odstraní tělo ze 200, klientovi nezbyde nic k vykreslení a stránka se zobrazí prázdná.
• Slabé nebo nestabilní ETagy za load balancerem. Když několik backendů generuje pro identický obsah různé ETagy, každé přehodnocení mine cíl a místo 304 dostáváte plná 200. Provoz zbytečně roste.
• Komprese měnící validátor. Pokud se ETag liší mezi komprimovanou a nekomprimovanou variantou bez správné hlavičky Vary: Accept-Encoding, mezipaměti mohou podat nesprávnou verzi.

Jak testovat podmíněné požadavky

1. Stáhněte zdroj a přečtěte jeho validátory:

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

2. Zopakujte požadavek se ETagem, který jste dostali, a ověřte, že server odpoví 304:

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

   Dosaďte přesnou hodnotu ETagu, včetně uvozovek. 200 zde znamená, že přehodnocení nefunguje.
3. Pokud dostanete 200 tam, kde jste čekali 304, zkontrolujte, zda proxy nebo CDN neodstraňuje If-None-Match, a zda se vaše backendy shodují na ETagu pro stejný soubor.
4. Pokud dostáváte zastaralou stránku, zařiďte, aby se validátor měnil spolu s obsahem. Nejspolehlivější oprava jsou názvy souborů s otiskem; jinak odvoďte ETag ze samotného obsahu.
5. Nechte HTML na krátké době čerstvosti a dlouhou nechte souborům. HTML cachované na den je přesně to, co dělá nasazení neviditelným.

Proč kontroly dostupnosti nikdy neuvidí 304

Kontrola dostupnosti požaduje stránku jako první návštěvník, bez If-None-Match a bez If-Modified-Since, takže server nemá s čím porovnávat a vždy odpoví 200. To je správné výchozí chování pro dostupnost. Zároveň to znamená, že se regrese v cachování v datech o dostupnosti vůbec neprojeví: web může všem servírovat zastaralou stránku, zatímco každá kontrola zůstává zelená. Ověřujte i obsah stránky, ne jen stav, a stránka, která se přestala aktualizovat, se projeví jako neshoda obsahu. HostTracker nabízí 13 typů monitorů a monitoruje weby od roku 2004. Otestujte hlavičky i stav pomocí nástroje pro HTTP kontrolu a přečtěte si co skutečně dokazuje 200 OK a celý návod k rodině 3xx.