Re: dont-revalidate Cache-Control header

[Bryan McQuade <[e-mail]>]

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.

In order to opt out, we need to address the issues listed in the RFC:
a) if either the cache or the origin server has overestimated the
expiration time of the cached response
b) if the cache entry has become corrupted

For (a):
Will proxy caches add future max-age or Expires headers to resources that
they fetched from an origin, if the origin didn't provide any such headers?

For (b):
The user agent should be able to assert that the copy of the resource it
has is the 'right' copy, and not a corrupted copy, before deciding not to
attempt to reload the resource from the origin server.

RE: whether this mechanism should be associated with the resource vs the
page being loaded, I prefer associating the behavior with the resource (via
e.g. an HTTP response header or Cache-Control directive). If associated
with the resource rather than the page, third party resources
(ads/analytics/widgets/etc), which add latency to many page loads, could
also adopt this and prevent resource reloads on page refresh.

-bryan