{"id":15683,"date":"2026-11-09T08:05:00","date_gmt":"2026-11-09T07:05:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=15683"},"modified":"2026-10-26T13:14:31","modified_gmt":"2026-10-26T12:14:31","slug":"the-question-that-saves-nothing-etag-last-modified-and-the-missing-304","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/tutorials-en-web-development\/the-question-that-saves-nothing-etag-last-modified-and-the-missing-304\/","title":{"rendered":"The Question That Saves Nothing: ETag, Last-Modified and the Missing 304"},"content":{"rendered":"

A cached response is fresh while the cache rules permit reuse without asking the server. Such a response can avoid a network request. Once checking becomes necessary, a validator can avoid transferring the body again: a matching conditional GET can receive 304 Not Modified<\/code>. That still costs a request and processing time. A cache without validators can therefore remain useful while a stored response is reusable.<\/p>\n

A historical run from 5 September 2026 covered twenty starting URLs. Eleven recorded responses contained neither an ETag nor Last-Modified. This describes those responses, not an inability of eleven entire websites to support conditional requests.<\/p>\n

\"Historical
Historical response headers and interpretation: 304 avoids the body, while 200 alone does not prove a change or a defect.<\/figcaption><\/figure>\n

Two validators, different guarantees<\/h2>\n

Last-Modified<\/code> describes the last modification time with one-second precision. The corresponding request field is If-Modified-Since<\/code>. Multiple changes within a second can exceed that precision.<\/p>\n

ETag<\/code> is a version label whose contents the client need not interpret. The label is returned in If-None-Match<\/code>. Its reliability depends on generation: a content hash or another suitable version scheme can distinguish changes that timestamps miss. An ETag is not automatically a content hash.<\/p>\n

A strong ETag identifies identical representation data. A weak ETag, such as W\/\"abc\"<\/code>, permits equivalent data without byte identity. Dynamic generation does not automatically require weak tags: the actual comparison guarantee matters.<\/p>\n

What the saved sample contains<\/h2>\n

The archived results contain five ETags, including three weak ones, and five Last-Modified fields. One response has both; eleven have neither. Six responses specify no-store<\/code>, but only four of those lack both validators. Seven responses therefore lack validators without also specifying no-store. This alone does not establish cacheability: status, other directives and the cache context also matter.<\/p>\n

Two results carry an HTTP-error flag, including one of the two responses without Cache-Control. The saved summary does not preserve their exact status codes. The sample must therefore not be presented as twenty successful front-page responses or as a market statistic.<\/p>\n

The analyzer assigned six storage-prohibited, four immediate-refetch, three always-revalidate, four fresh-then-revalidate, one fresh-then-refetch and two heuristic labels. These are classifications of header observations, not measured browser histories. For example, the 54-second value was a max-age directive, not proof that every browser kept the response for exactly 54 seconds.<\/p>\n

Freshness is separate from validation<\/h2>\n

no-store<\/code> prohibits HTTP-cache storage; no-cache<\/code> requires successful validation before reuse. max-age=0<\/code> makes a response immediately stale. Private and shared caches can have different rules, particularly with private or s-maxage.<\/p>\n

Without an explicit reuse period, a cache may estimate one under suitable conditions. This is called heuristic caching. Ten percent of the interval since Last-Modified is an example heuristic, not a mandatory lifetime. Neither of the two sampled responses without Cache-Control contained Last-Modified, so the archive does not demonstrate that calculation for those responses. Browser back\/forward mechanisms also cannot be inferred from this HTTP test.<\/p>\n

Compression and the ETag trap<\/h2>\n

Apache documents that its default AddSuffix<\/code> behavior in the compression modules can prevent 304 responses for compressed content. This makes a same-variant conditional test useful. A repeated 200 alone is insufficient evidence: the selected representation may genuinely have changed.<\/p>\n

DeflateAlterETag NoChange<\/code> and BrotliAlterETag NoChange<\/code> preserve the original tag, but Apache explicitly documents the resulting variant-identity limitation. A shared strong tag for compressed and uncompressed bytes is not made correct by Vary: Accept-Encoding<\/code>. Vary controls cache selection; strong validators concern representation identity.<\/p>\n

A suitable solution depends on the server and cache pipeline: correct distinct strong tags, properly handled weak tags for equivalent representations, or removal of an unsuitable ETag with the resulting validation trade-off. Range requests and conditional responses need verification. No universal production directive follows from a single 200 result. The earlier article’s claim that NoChange was unconditionally safe has therefore been removed.<\/p>\n\n\n\n

\"Two
Two duvets tied with the same ribbon, one fluffed up, one vacuum-packed flat. A shared ETag (a label for a file version) on compressed and uncompressed data is just as misleading.<\/figcaption><\/figure>\n\n\n

A reproducible conditional GET<\/h2>\n

The Bash example needs curl 7.68.0 or later. It keeps the URL and encoding preference unchanged, preserves the received ETag, and stops if the initial response is not 200 or supplies no tag. The URL is a placeholder; redirects require selecting and testing the intended final URL separately.<\/p>\n

Shell<\/span>