Turbo Drive cached HTML served without cache-control invalidation on server mutation

Answer first

Turbo Drive does not issue conditional requests itself. Conditional requests with If-None-Match or If-Modified-Since are issued by the browser HTTP cache when a prior response was stored with ETag/Last-Modified and Cache-Control allows revalidation. Turbo Drive sends its own navigation headers such as X-Turbo-Request-Id and X-Turbo-Frame-Render, but it does not add validators.

Server Cache-Control and validators control whether the browser serves a cached HTML response to a Turbo Drive navigation. Turbo’s X-Turbo-* headers do not override standard HTTP caching semantics. The browser decides a cache hit or network fetch based on Cache-Control, max-age, must-revalidate/no-cache/no-store, and the presence of ETag/Last-Modified.

Yes. Turbo provides page and element level cache control without query strings. A page-level meta tag can set the default, and data-turbo-cache-control on links and forms can force a fresh navigation and skip the Turbo snapshot cache. Names and support are version dependent.

Confirmed facts

• Turbo Drive keeps an in-memory snapshot cache of visited pages for instant back/forward rendering. It relies on the browser HTTP cache for fetch requests. It does not automatically invalidate its own snapshots when server data changes.
• Conditional requests are a browser HTTP cache behavior, not a Turbo Drive behavior. They occur only when the browser has a cached entry with ETag or Last-Modified and Cache-Control permits revalidation.
• Cache-Control directives control browser reuse: no-store, no-cache, must-revalidate, or max-age=0 force a network fetch and prevent the browser from serving a cached HTML response to Turbo Drive. ETag/Last-Modified enable 304 Not Modified when revalidation is permitted.
• Turbo provides cache bypass controls at page and element level via meta tag and data-turbo-cache-control attribute to skip its snapshot cache and force a fresh navigation.

Likely explanation for your stale HTML

The stale HTML you see is likely a combination of Turbo snapshot preview rendering from its own in-memory cache and a browser HTTP cache hit due to permissive Cache-Control with no server validators to trigger revalidation after mutation. Turbo will render the snapshot instantly, then the browser may serve the cached HTTP response for the fetch, so the page appears unchanged even after a successful server mutation.

Steps needed for this case

1. Inspect network traffic for a Turbo Drive navigation. Check if If-None-Match/If-Modified-Since are sent and whether the response is 200 from network or 200 from cache / 304.
2. Check response headers for Cache-Control, ETag, Last-Modified. Confirm whether Cache-Control includes no-store/no-cache/must-revalidate or a short max-age.
3. Verify page source for turbo cache control meta tag and for data-turbo-cache-control on the links/forms that return stale content.
4. If you need to bypass Turbo’s snapshot cache for a specific page or navigation, apply the element/page cache control and tighten HTTP caching on the server.

One missing diagnostic detail that changes the recommendation: which Turbo version is in use. Meta tag name and data-turbo-cache-control values and support are version dependent, and the exact attribute to use for forcing a fresh navigation varies between major releases.