Re: dont-revalidate Cache-Control header

[Mark Nottingham <[e-mail]>]

Hey Ben,

> On 12 Jul 2015, at 3:58 am, Ben Maurer <[e-mail]> wrote:
> 
> 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.

Yes. That problem (and similar ones) is coming up in a number of contexts, so there are quite a few headers being minted at the moment :-/

Maybe a HTML control for first-party and near-party control, and a header for third-party? (just thinking out loud; not a big fan of duplication of effort in general, but it might be worthwhile here).


> 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).

Sorry - you lost me at "secure" and "swf" :)


> 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?

I agree with your dislike of magic…

From time to time, we've had people ask for "Cache-Control: Infinity-I-really-will-never-change-this." I suspect that often they don't understand how caches work, and that assigning a one-year lifetime is more than adequate for this purpose, but nevertheless, we could define that so that it worked and gave you the semantics you want too.

To keep it backwards compatible, you'd need something like:

Cache-Control: max-age=31536000, static

(or whatever we call it)

Cheers,

> 
> 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/
> 
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/