304 Not Modified

A 304 response is sent when a conditional GET or HEAD request indicates the client already has a fresh copy of the resource. Instead of resending the full body, the server confirms the cached representation is still valid, and the client reuses what it already stored. This is a pure caching optimization: it saves bandwidth and server processing while keeping the client’s view of the resource up to date, and RFC 9110 requires the response carry no body.

Conditional requests are driven by two independent mechanisms that can be used together. The strong mechanism uses ETag: the server sends an ETag header on the full response, the client echoes it back as If-None-Match on the next request, and the server returns 304 if the current ETag still matches. The weaker, time-based mechanism uses Last-Modified paired with If-Modified-Since: the client sends the timestamp it last saw, and the server compares it to the resource’s current modification time. ETag is preferred where available because it detects any content change, including ones that happen within the same second, which Last-Modified’s one-second resolution can miss.

A 304 response must still include headers that would have changed between requests, such as Cache-Control, ETag, Vary, and Expires, so the client can update its cache metadata even though the body is not resent. Getting this wrong is a common bug: a server that regenerates ETags inconsistently (for example, based on a timestamp that differs per process in a multi-server deployment) will rarely or never emit 304, defeating the point of conditional caching and wasting bandwidth on redundant transfers.

304 is central to how CDNs, reverse proxies, and browsers minimize origin load for static assets, API responses, and images. Misconfigured conditional headers are a frequent source of subtle bugs: stale content served indefinitely because validators never change, or the opposite, needless full re-downloads because validators change on every request even when content is identical.