Practical testing of HTTP 304 and conditional requests

What HTTP 304 actually confirms

A conditional request asks the server whether an already known representation is still current. If an ETag fits if-None-Match, the response 304 Not Modified can avoid retransmitting the content. Last-Modified and If-Modified-Since follow a similar goal based on the change date. A mere header does not yet prove that these requests are processed correctly.

This is how the comparison goes.

First, the public URL is retrieved without condition. HTTP 200 and usable validators are followed by suitable requests. An additional, random ETag serves as a counter-test. If both validators are present, another request checks the priority of If-None-Match over If-Modified-Since. The final URL remains fixed for these follow-up requests.

HTTP 200 is not automatically an error

If the content changes between two retrievals, a new 200 response may be correct. For complete answers, the tool therefore additionally compares the content. If a reading limit has been reached, no unchanged representation is claimed. Personalization, changing timestamps and different server nodes can also influence the classification.

Assess storage and revalidation separately

Cache-Control: no-store concerns storage. An ETag alone does not allow for all storage, and a missing ETag is not a stand-alone SEO error. For the entire cache concept, additionally use the cache/compression checker. The semantics of the conditions are in RFC 9110 described above.

Frequent questions