HTTP 304 Not Modified

How HTTP 304 Not Modified Works

HTTP 304 is a cache validation response, not a content delivery response. It tells the client that its stored representation is still current, so the browser or intermediary can reuse cached content without downloading the body again. That makes the response efficient because the server only needs to confirm freshness, rather than resend the resource.

The key idea is conditional retrieval. A client sends headers such as If-Modified-Since or If-None-Match so the server can compare the cached copy with the current resource state. If the validator still matches, the server returns 304 and no body, which preserves bandwidth and reduces latency while keeping cached content usable.

Where 304 Fits in HTTP Caching

304 sits inside HTTP caching semantics, where freshness is determined by validators, cache directives, and the age of stored content. It is commonly used by browsers, reverse proxies, CDNs, and other intermediaries that want to avoid unnecessary transfers when a resource has not changed. In practice, 304 is one of the most visible indicators that cache revalidation is working correctly.

This status code is distinct from a simple cache hit. A normal cache hit can be satisfied entirely from local storage, while 304 arises after a revalidation step asks the origin server whether the cached version is still acceptable. That difference matters because 304 confirms the cache is still safe to use under the server’s current view of the resource.

Why 304 Matters for Performance and Correctness

HTTP 304 improves efficiency by reducing repeated transfers of unchanged content, especially for assets that are requested often but updated rarely. It can significantly lower origin load, cut page load times, and reduce unnecessary egress traffic. It also helps keep clients and intermediaries aligned on resource freshness without forcing full retransfers.

Correct use of 304 also protects user experience. When validators are configured well, users get fast page loads while still seeing updated content soon after a change. When validators are weak or inconsistent, caches may revalidate too often, miss reuse opportunities, or keep stale content longer than intended.

Common Implementation Details and Pitfalls

304 depends on the server generating validators that are meaningful for the resource being cached. Last-Modified timestamps and entity tags serve different purposes, but both must reflect real content changes rather than incidental file metadata or unstable generation logic. If the validator does not track the actual representation, clients may reuse a copy that no longer matches the intended content.

Care is also needed with intermediaries. Proxies, CDNs, and application servers may each participate in cache validation, and inconsistent handling can produce confusing results. A resource may appear to update slowly, revalidate unexpectedly, or return different freshness behaviour depending on headers, response directives, or how shared caches interpret the validator chain.

Risk and Threat Considerations

304 itself is not a vulnerability, but cache validation mistakes can create exposure when systems serve stale content, fail to invalidate sensitive responses, or let intermediaries reuse data longer than intended. The main risk is not the status code, but incorrect caching behaviour around it, especially for personalised pages, authenticated responses, or rapidly changing data.

Failure mechanism: A cache or origin server may treat a resource as unchanged when the representation has actually changed, or it may allow reusable cached responses where freshness and privacy requirements are stricter than the headers imply.

Impact: Users can receive stale or incorrect content, and in poorly designed systems a shared cache can amplify data exposure by reusing a response beyond the intended scope.

Practitioner Guidance

Why practitioners should care: 304 is a useful optimisation only when validators and cache directives match the resource’s real change model. For dynamic content, authenticated pages, or responses that vary by user context, the caching design needs to be explicit rather than assumed.

What to watch for: Check whether revalidation behaviour matches the resource type, and verify that changed content actually produces a new validator or a cache invalidation event. If users report stale pages or inconsistent updates, the issue is often in validator design, intermediary configuration, or response metadata rather than in the status code itself.

Related resources from NHI Mgmt Group

• How should security teams decide between WinRM over HTTP and HTTPS?
• What do teams get wrong about WinRM over HTTP security?
• How should teams respond when Apache HTTP Server has a remote code execution CVE?
• What breaks when namespace-scoped policies can trigger outbound HTTP from a controller?