This is expected behavior.  For forward/back navigations, and when restoring sessions, we load pages with LOAD_SKIP_CACHE_VALIDATION, which will use expired cache entries.

@mmenke: As per comment#2 can we close this issue as wont-fix. Please feel free to change the status of the bug.

Thanks!

Since cache-control includes must-revalidate, I don't think you are following the spec.

I suspect we aren't, but the current behavior is definitely deliberate (To save bandwidth, reduce load times, speed startup, and make session restore/forward/back produce pages more consistently).  I defer on the owners of the relevant session restore code if we want to consider changing behaviors here.

Please consider changing the behaviour. Since we can't rely on the expected behaviour of must-revalidate what ends up happening is almost the exact opposite of your intentions. After it uses the stale file and our app starts it detects a version mismatch and has to force a reload. 

The spec is very specific in what must and must not happen when must-revalidate is used.
See https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html - 14.9.4 Cache Revalidation and Reload Controls

must-revalidate:
...The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances an HTTP/1.1 cache MUST obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.
Servers SHOULD send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect operation, such as a silently unexecuted financial transaction. Recipients MUST NOT take any automated action that violates this directive, and MUST NOT automatically provide an unvalidated copy of the entity if revalidation fails.
Although this is not recommended, user agents operating under severe connectivity constraints MAY violate this directive but, if so, MUST explicitly warn the user that an unvalidated response has been provided. The warning MUST be provided on each unvalidated access, and SHOULD require explicit user confirmation.

Note that RFC 2616 is obsolete.  https://tools.ietf.org/html/rfc7234 has the updated cache specs, though wording the doesn't differ significantly for this (Which seems weird to me - it's supposed to better repesent modern browser behavior, among other things, and no browser generates bogus 504 responses, though caching proxies do).

mmenke@ A Gentle ping...

Request you to please provide an update on this issue.

Thanks..

Per #5, I own neither the cache nor the session restore code, so I'll defer to the owners (It's really a session restore design decision, though it's a feature our cache does support).

As per comment #9, ccing the owners of Internals>Network>Cache for further inputs on this issue and requesting to please have a look into the issue. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

The cache is doing what it's told by session restore and behaving correctly given that. This is an issue for session restore folks.

Note: as a way to get around this, you could set vary-cookie and set a new random cookie on each load. The vary mismatch should still cause a revalidation.