Same URL serves different file versions to different devices — why?
A file is hosted at one URL, test.com/test.exe. Three devices (iOS, Android, desktop Chrome) download it at the same time. Two receive v2; one receives v1. The URL is identical on all three.
URL: test.com/test.exe (same on every device)
Device 1: downloads v2
Device 2: downloads v2
Device 3: downloads v1 <-- why the older version?What could cause the same URL to serve different file versions, and which tools and headers would you use to investigate? Diagnose the cause.
Likely causes are CDN edge-cache staleness (one node still holds the old version), geo or locale-based content negotiation (the Accept-Language or geo headers select a version), a stale local browser cache, or a VPN changing the exit node. Investigate by inspecting request/response headers with DevTools or a proxy and comparing ETag, Last-Modified, and Cache-Control across the devices.
- ✗Assuming one URL must always return the same bytes
- ✗Ignoring CDN cache and geo/locale content negotiation
- ✗Not comparing
ETag/Last-Modified/Cache-Controlheaders
- →Which response header would reveal a stale CDN edge node?
- →How could
Accept-Languagecause one device to get an older build?
The trap is "one URL = one file." In a real CDN-fronted, content-negotiated system the same URL can legitimately resolve to different bytes per request.
Likely causes:
- Stale CDN edge node — Device 3 hit an edge that still caches v1; the others hit edges already holding v2.
- Geo / locale content negotiation — the origin serves a version based on
Accept-Languageor a geo header, so a device in a different locale gets a different build. - Stale local browser cache — Device 3 served v1 from its own cache without revalidating.
- VPN / different exit node — changes the apparent region and thus the served version.
How to investigate — compare the response headers across the devices:
Device 1: ETag: "v2-9f3c" Age: 12 X-Cache: HIT (edge-fra)
Device 2: ETag: "v2-9f3c" Age: 4 X-Cache: HIT (edge-ams)
Device 3: ETag: "v1-2b71" Age: 86400 X-Cache: HIT (edge-sin) <-- stale objectDifferent ETags under one URL already prove different artifacts are being served. A large Age on a different edge node points at a stale CDN cache; matching ETags under differing Accept-Language would instead point at content negotiation, and Cache-Control tells you whether the browser could have served the file from its own cache without revalidating.
The reasoning skill is knowing which request attribute makes the server (or a cache) return a different artifact.
