Re: dont-revalidate Cache-Control header

[Ben Maurer <[e-mail]>]

Hey Mark,

This suggestion also came up in prior discussions of the problem. One major
issue with this solution is that it doesn't address situations where
content is embedded in a third party site. Eg, if a user includes an API
like Google Maps or the Facebook like button those APIs may load
subresources that should fall under this stricter policy. This issue cuts
both ways -- if 3rd party content on your site isn't prepared for these
semantics you could break it.

I believe UAs were worried about the potential security implications of
such an extension -- eg what if you could alter the caching semantics of a
SWF that had privileged cross origin access so that you could extend the
lifetime of a vulnerable version (granted this extension would only make
the situation worse in the case where the user refreshed the page, so it
might not be that big of a deal).

A third design I had discussed would be a heuristic. For example:

If a UA would normally revalidate a fresh resource due to a user action
expressing interest in requesting a fresh page (eg if the user presses the
reload button) it SHOULD use the following heuristic to avoid excessive
revalidations. If the difference between freshness_lifetime and current_age
is less than 7 days, then the UA SHOULD NOT perform the revalidation and
serve the resource.

The idea here is that reloading is such a rare action (2% of page views
according to our stats) that no reasonable site would design their
experience around the user using the reload button. On the other hand it
might be reasonable for the site to have something with a 5 minute
freshness lifetime and for the user to want an up-to-date version of the
resource

Pros:
- No changes to existing headers
- Would provide a speedup for people who are currently following best
practices

Cons:
- Feels like magic
- Theoretically changes the behavior of a site which actively encourages
it's users to use the reload button (I've never seen such a site)
- Forces a developer who actively edits their code to use short lifetimes
or ctrl+shift+r
- UAs are hesitant to do anything which changes existing behavior.

Do you have any more thoughts on preferences between these options?

On Fri, Jul 10, 2015 at 6:33 PM, Mark Nottingham <[e-mail]> wrote:

> Hi Ben,
>
> > On 11 Jul 2015, at 3:14 am, Ben Maurer <[e-mail]> wrote:
> >
> > 2) Create a new behavior that websites can opt in to. Ensure that UAs
> implement it consistently. This has less risk of breaking existing sites,
> though I understand the hesitance to have a header that says "no *REALLY*
> trust my expiration times". Perhaps the header is poorly advertising the
> functionality that we wish to achieve. A better name/behavior might be
> Cache-control: content-addressed. content-addressed would signal that the
> contents of the current URL is a pure function of the URL itself. IE, that
> the contents will never change. It would take priority over a max-age
> header and signal to the browser that the resource should be permanently
> cached.
>
> This seems like the crux of the matter. A CC extension is one way to do
> this, but I wonder if a more appropriate place might be in HTML, since this
> is really about how the browser behaves in reaction to user input, not how
> the cache behaves.
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>