Re: dont-revalidate Cache-Control header

On Tue, Jul 14, 2015 at 3:03 AM, Ben Maurer <ben.maurer@gmail.com> 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.

On Tue, Jul 14, 2015 at 5:36 AM, Ben Maurer <ben.maurer@gmail.com> wrote:

>
>
> On Tue, Jul 14, 2015 at 1:01 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> 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)
>>
>
> Static is a fairly reasonable name. Static does imply that the resource
> will *never* be revalidated (ever) vs the dont-reload which implies no
> revalidations prior to expiration. I don't have any preferences between the
> two but wanted to call that out.
>
> What's the next step here?
>