Conditional Requests Checker
Fetches a URL, then re-requests it with If-None-Match and If-Modified-Since built from its own ETag and Last-Modified, to verify 304 Not Modified behavior actually works as specified.
Based on: RFC 9110 — HTTP Semantics
About this validation
Tests If-None-Match and If-Modified-Since conditional GET requests against RFC 9110's HTTP conditional-request semantics, classifying 304 Not Modified support as supported, not supported, inconsistent, or misconfigured.
- Protocol / standard:
- Rules reviewed:
- Sep 1, 2026
Standards and vendor-documented behavior can change. This reflects the source as last reviewed above, not a permanent guarantee.
What This Test Checks
At most 3 requests: a normal GET to discover ETag/Last-Modified, then one conditional GET per validator the response actually provided. Each is classified as Supported, Not Supported, Inconsistent, or Misconfigured -- distinguishing "this server doesn't bother with conditional requests" (fine) from "this server's 304 response is broken" (a real problem).
FAQ
Is it a problem if a site doesn't support conditional requests?
Not by itself. Many sites, especially dynamic ones, don't return ETag or Last-Modified at all, or don't act on them. This tool only flags an actual inconsistency -- e.g. a 304 that still returns a body -- as a problem.
What does a 304 with a body mean?
It's a spec violation: a 304 Not Modified response must never include a body. This can confuse clients that expect an empty response and may waste bandwidth.
Why test both ETag and Last-Modified separately?
A server can support one without the other, or handle them inconsistently. Testing both shows which validator (if either) the server actually honors.