Re: dont-revalidate Cache-Control header

>
>
> You're right that I hadn't been thinking about this with the perspective
> of browser with an intermediate cache. I guess the behavior I'm suggesting
> here is that a browser should treat a refresh on the main resource the same
> as it does today (send a max-age=0 request), however it should *not* do
> this for sub-resources that have the static extension. Open to other
> suggestions about behavior here -- mainly I want to provide a safety net if
> a hack/mistake were to make www.foo.com/ return a corrupt document with a
> static caching flag.
>

The risk is still the typical ga.js url embedded in all websites. If a
bug/hack makes that static, you will need to ask all site owners to go and
change the url to something else, which will take ages.

Perhaps we need to change this header to the page owner? For example
facebook.com embedding a policy no never revalidate sub-resources feched
from static.facebook.com? A website wont be allowed to self-reference, so
we have this security issue solved. The page people navigate to is still
working as normal, subresources can be marked as no revalidate needed, in
case of bug, the policy can be removed and sub-resource urls changed.

-- 
Guille -ℬḭṩḩø- <bishillo@gmail.com>
:wq