HTTP 304 Not Modified: What It Means

What this error means & how to recognize it

• A browser developer tool, API client, monitoring tool or checker reports status 304 Not Modified.
• The response contains caching or validator headers but no resource body.
• A browser may display the page normally because it reuses its cached representation.
• An API client or checker may appear to receive an empty response if it does not implement conditional caching correctly.
• The result may apply to one URL or resource rather than the entire website.
• DNS and TLS can still be working because the client reached an HTTP endpoint and received an HTTP response.

Root causes, ordered by likelihood

1. The client sent a conditional request. Request headers such as If-None-Match or If-Modified-Since asked whether the cached representation was still current.
2. The resource has not changed. The server or an intermediary matched the supplied validator, such as an ETag or Last-Modified value, and correctly returned 304.
3. A browser, proxy or CDN performed normal cache validation. The response may have been generated by an intermediary rather than the origin application.
4. A client or monitoring tool exposed a normal cache response as an error. Some tools are configured to expect a complete response body and may not reuse their stored copy.
5. Validator or cache configuration is inconsistent. Unexpected results can occur when application deployments, proxy rules or origin headers produce stale, conflicting or overly broad cache validators.

HTTP 304 is not, by itself, a redirect, authentication failure, rate-limit response or server outage. Those conditions should be confirmed from the actual status, headers and logs rather than inferred from 304.

How to fix it

For visitors

1. Let the browser handle the response first. A normal browser should use its cached copy when it receives 304. If the page appears correct, no action is usually required.
2. Check the exact URL. Confirm the hostname, path, query string and protocol. Different URLs can have separate cached representations.
3. Retry once if the displayed content is stale or incomplete. Use the browser's normal reload controls rather than repeatedly refreshing.
4. Compare another client only when useful. If one browser shows stale content while another does not, record the affected URL, approximate time and client behavior for the site owner.
5. Contact the site owner if the resource cannot load. Report the URL and timestamp, but do not share passwords, cookies, authorization headers or other private data.

For developers and site owners

1. Capture the complete request and response context. Record the HTTP method, full URL including relevant query parameters, status, request validators, response validators, Cache-Control, Vary and any proxy or CDN headers. Remove credentials and personal data before sharing.
2. Confirm that the request is conditional. Look for If-None-Match or If-Modified-Since. A 304 is normally meaningful when the client has a cached representation to validate.
3. Check the response-producing layer. Determine whether the 304 came from the browser, a local or shared proxy, CDN, reverse proxy, web server or application. Use that component's request identifier and timestamp where available.
4. Compare validators with the resource. Verify that ETag or Last-Modified accurately represents the requested representation and that content negotiation is covered by an appropriate Vary policy where relevant.
5. Test an unconditional request when you need the current body. Use an authorized diagnostic client or temporarily omit conditional request headers in a controlled test. This is a read-only comparison, but follow the service's normal access controls and avoid sending sensitive headers to untrusted tools.
6. Review recent cache and deployment changes. Check application releases, asset generation, proxy or CDN rules, compression and content negotiation, routing, and cache invalidation behavior. Focus on changes affecting the specific route rather than changing global settings immediately.
7. Apply the narrowest safe correction. Correct the validator, cache policy or intermediary rule only after identifying the mismatch. Avoid disabling caching globally when one route or representation is affected.
8. Retest the same request path. Test both a conditional request and a fresh request, then confirm that related routes and request methods still return their intended statuses and representations.

Prevention & how to verify the fix

• Treat 304 as an expected cache-validation outcome in monitoring unless the client cannot use its cached representation.
• Test important routes with both ordinary and conditional requests after deployments.
• Keep ETag, Last-Modified, Cache-Control and Vary behavior intentional and documented.
• Ensure cache validators change when the served representation changes, including relevant content negotiation variants.
• Monitor status rates by route and by cache layer so an unexpected 304 pattern is distinguishable from normal browser traffic.
• Keep proxy, CDN, web-server and application configuration version controlled where practical.
• Retain sanitized request identifiers and timestamps long enough to match a report to the layer that generated the response.

Frequently asked questions