304 - Not Modified
HTTP 304 Not Modified means conditional request found that the cached representation is still valid.
Last reviewed: March 10, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Not Modified Mean?
Cache revalidation succeeded, so the client should reuse its cached representation instead of downloading the body again.
Common Causes
- -If-None-Match header matches current strong ETag, so origin returns metadata-only not modified response.
- -If-Modified-Since timestamp is newer than last content update and conditional GET short-circuits body transfer.
- -CDN revalidation workflow with immutable assets repeatedly satisfies cache condition and returns 304 status.
How to Fix Not Modified
- 1Validate ETag and Last-Modified generation so validators stay consistent across origin instances.
- 2Inspect If-None-Match and If-Modified-Since behavior alongside Cache-Control and Vary directives.
- 3Purge or revalidate stale cache entries when validator drift appears after deployment changes.
Step-by-Step Diagnosis for Not Modified
- 1Capture conditional request headers and validator values associated with 304 responses.
- 2Verify ETag/Last-Modified generation consistency across replicas, regions, and representation variants.
- 3Inspect Cache-Control/Vary policies across browser, CDN, proxy, and origin paths.
- 4Retest with controlled validator scenarios (cold cache, changed resource, unchanged resource).
Validator Generation and Consistency Checks
- -Compare validator outputs across nodes (example: same resource returns different ETags per replica).
- -Audit weak vs strong validator usage (example: weak ETag used where byte-level equality is required).
Cache Revalidation Policy Alignment
- -Validate Vary dimensions are included in cache keying (example: gzip and br variants sharing one validator incorrectly).
- -Inspect CDN revalidation behavior (example: edge sends stale
If-None-Matchafter origin deploy).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource -H 'If-None-Match: "etag-v1"'
# Response:
# HTTP/1.1 304 Not Modified
# ETag: "etag-v1"const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json', 'If-None-Match': '"etag-v1"' }
});
if (response.status === 304) {
console.error('Handle 304 Not Modified');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json', 'If-None-Match': '"etag-v1"'}
)
if response.status_code == 304:
print('Handle 304 Not Modified')Seen in Production
Strong cache validation for static assets
Frequency: common
Example: Browser sends If-None-Match; unchanged asset returns 304, reducing bandwidth during repeat visits.
Fix: Keep deterministic ETag generation and correct cache directives for stable revalidation behavior.
Replica mismatch causes stale validator behavior
Frequency: rare
Example: One region computes different ETag for same content, resulting in inconsistent 304/200 responses across regions.
Fix: Normalize validator generation logic and rollout deterministic hashing across all replicas.
Debugging Tools
- -Conditional request replay with ETag/Last-Modified headers
- -CDN cache revalidation logs
- -Origin validator generation diagnostics
- -Browser cache inspection tools
How to Verify the Fix
- -Confirm changed resources return 200 with updated payload and unchanged resources return 304 only when valid.
- -Validate cache freshness, validator headers, and revalidation behavior across browser and CDN paths.
- -Monitor 304 to 200 ratio and stale-content incidents to verify stable conditional caching behavior.
How to Prevent Recurrence
- -Generate deterministic validators and keep cache keys aligned with representation variants and Vary policy.
- -Add regression tests for conditional GET and HEAD behavior across deployment and replica changes.
- -Track cache and validator anomalies with alerts tied to stale-content and revalidation failure signals.
Pro Tip
- -seed validator generation inputs with build/version hash for dynamic resources to avoid cross-release stale cache collisions.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.