Error Codes Wiki

If-Modified-Since Caching — Conditional Request and 304 Not Modified Errors

Informational3xx redirection

Overview

Fix If-Modified-Since and If-None-Match conditional caching errors causing stale content, cache validation failures, and unnecessary full downloads.

Key Details

  • Conditional requests use If-Modified-Since or If-None-Match headers to validate cached content
  • Server responds with 304 Not Modified if the content has not changed, saving bandwidth
  • If-Modified-Since uses a date; If-None-Match uses an ETag (entity tag) for more precise validation
  • Incorrect date formats or clock skew between client and server cause validation failures
  • Some servers do not support conditional requests, always returning full 200 responses

Common Causes

  • Server not sending Last-Modified or ETag headers on initial responses
  • Date format in If-Modified-Since not matching the required HTTP date format (RFC 7231)
  • Clock skew between client and server causing premature or delayed cache invalidation
  • Load-balanced servers generating different ETags for the same content

Steps

  1. 1Ensure your server sends Last-Modified and ETag headers on cacheable responses
  2. 2Implement conditional request handling: compare If-Modified-Since/If-None-Match and return 304 when content is unchanged
  3. 3Use strong ETags based on content hash (not timestamp) for consistent validation across load-balanced servers
  4. 4Test conditional requests: curl -H 'If-None-Match: "etag-value"' -v https://your-server.com/resource
  5. 5Configure your CDN to support and forward conditional request headers to the origin

Tags

cachingconditional-request304etagif-modified-since

More in 3xx Redirection

Frequently Asked Questions

If-Modified-Since uses a date and is simpler but less precise. If-None-Match uses ETags (content fingerprints) and is more reliable, especially with load-balanced servers generating the same content.