Addendum (2026-07-22): the same production deployment dpl_7WPXNNai4E3YaHiUy6TqBQydu1Hm has a second reproducible CDN HIT contract failure.

For HTML (/fr), manifest.webmanifest, one current hashed JS chunk, and one current hashed CSS chunk, each identity 200 contains an ETag. Sending If-None-Match with that exact ETag then returns an empty 304 but omits the ETag on all four resources (0/4). Current Vercel response IDs were cdg1::cdg1::j96qc-1784763214915-da8d234eeeb2, cdg1::kctzg-1784763215062-624315778f06, cdg1::vfrjk-1784763215187-65bbf76281a4, and cdg1::ptnk4-1784763215306-559d19561bb0; all were x-vercel-cache: HIT.

The application has no handler for Vercel-generated cache-HIT 304s (including /_next/static), so this cannot be corrected in Next.js without masking the edge contract. No code, deployment, DNS change, or second purge was made.

Please inspect CDN conditional-response header propagation together with the existing stale If-Match / If-Range cache-HIT issue.

Hi Elhassanaz,

This is a strong repro. The important distinction is that MISS responses behave correctly, but cached HIT responses do not, so I’d keep the report focused on the CDN HIT path rather than Next.js, deploy cache, or the asset contents themselves.

One small thing I’d add is a compact before/after matrix for a single asset, with the same headers captured every time:

1
URL="https://wassel.ma/manifest.webmanifest"
2

3
curl -sSI "$URL" | egrep -i 'HTTP/|etag|cache-control|age|x-vercel-cache|x-vercel-id|content-length|content-range'
4

5
curl -sSI \
6
  -H 'If-Match: "definitely-not-current"' \
7
  "$URL" | egrep -i 'HTTP/|etag|cache-control|age|x-vercel-cache|x-vercel-id|content-length|content-range'
8

9
curl -sSI \
10
  -H 'Range: bytes=0-63' \
11
  -H 'If-Range: "definitely-not-current"' \
12
  "$URL" | egrep -i 'HTTP/|etag|cache-control|age|x-vercel-cache|x-vercel-id|content-length|content-range'
13

Then repeat the same test with a cache-busting URL or after forcing a MISS, if possible. If the stale validators are handled correctly on MISS but ignored on HIT, that makes the failing layer very clear.

For the escalation, I’d include:

1
Asset URL:
2
Current ETag:
3
Request headers:
4
Expected status:
5
Actual status:
6
x-vercel-cache:
7
x-vercel-id:
8
Age:
9
POP from x-vercel-id:
10
UTC timestamp:
11

I don’t think repeated vercel cache purge is a durable workaround here if the behavior returns as soon as the object is cached again. The actionable ask is specifically whether Vercel’s static asset cache path is evaluating If-Match and If-Range before serving a HIT, or whether those request headers are currently bypassed on cached objects.