Re: dont-revalidate Cache-Control header

["Roy T. Fielding" <[e-mail]>]

> On Jul 14, 2015, at 3:33 PM, Ilya Grigorik <[e-mail]> wrote:
> 
>> On Tue, Jul 14, 2015 at 3:03 AM, Ben Maurer <[e-mail]> wrote:
>> That said, this doesn't feel like a great thing for us to promote as a web performance best practice. "If you use long cache lifetimes for your static content, the dont-revalidate cache control header will reduce the cost of client reloads" seems like a piece of advice folks might take, as would "Use the <meta> tag 'dont-reload-non-expired-resources' to avoid browsers revalidating your content when the user presses reload". On the other hand "you should find every image, script, stylesheet, etc and set the fetch option on each to say force-cached" feels more tedious and unlikely to be used.
> 
> To this point, the HTTP mechanism is something that FEO / optimization proxies can do on your behalf - e.g. rewrite and/or bundle resources, add version fingerprint, append the HTTP header we're discussing here. By comparison, rewriting markup (HTML, CSS, JS) is significantly harder and very expensive. Which is to say.. +1 for HTTP directive over markup.

No, it would be managed in the CMS along with all of the other decisions that led to a static version. Sane folks don't manage their content in an optimization proxy.

This is an attribute of the reference, not the resource. It belongs in the content.

....Roy