Re: dont-revalidate Cache-Control header

On Tue, Jul 14, 2015 at 12:49 AM, Bryan McQuade <bmcquade@google.com> wrote:

> Some history around page refresh->subresource reload browser behavior:
>
> HTTP/1.1 RFC (now deprecated):
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
> "14.9.4 Cache Revalidation and Reload Controls: Sometimes a user agent
> might want or need to insist that a cache revalidate its cache entry with
> the origin server ... End-to-end revalidation might be necessary if either
> the cache or the origin server has overestimated the expiration time of the
> cached response. End-to-end reload may be necessary if the cache entry has
> become corrupted for some reason."
>
> I take the above to suggest that the page refresh->reload subresource
> behavior was added to give users more certainty that refreshing a page
> would reload any corrupted or out of date resources. This seems like a fine
> default, but I agree with Ben that it'd be useful to allow web developers
> to opt out of this behavior.
>

For what it's worth, at least in our configuration reloading will do
absolutely nothing to fix cache corruption. The client will send us an
If-Modified-Since request, our servers will note that the resource has not
changed and we will send a 304. We've actually seen this in practice --
we've experienced issues where users somehow get corrupted resources (
https://code.google.com/p/chromium/issues/detail?id=161127). Refreshing
does *not* fix the issue, the users have to either clear cache or use a
ctrl+shift+r.

-b