Re: dont-revalidate Cache-Control header

[Guille -bisho- <[e-mail]>]

>
> > - If a page adds the header by mistake, can easily remove it.
>
> Who do you mean by "you" in this statement?


The domain owner. Imagine www.foo.com adds a header by mistake to not
revalidate from domain not-static.foo.com. If it's a mistake, they can
remove the header easily, and not-static.foo.com will have revalidations
again. The static behavior can be revoked with ease.

>
> > - A page can't self-reference their domain, so no risk of bricking
> yourself.
>
> But as proposed you would be able to pin index.html.  So I don't get
> this either.
>

No if we don't allow self-reference. www.foo.com can only disable
revalidations on other *different* domains and those are effective for
sub-resources only, no direct page navigations.

Imagine page a.com tries to use maliciously b.com/index.html as a
subresouce and request not revalidation. If b.com/index.html has a cache
control header, it will be obeyed, and client reloads on a.com won't cause
revalidation of b.com/index.html. But people browsing to b.com/index.html
will have the normal behavior, revalidations and so on.

So this will be simply let page-owner define what other domains are used
for static resources and should not be revalidated. The subresources still
need the usual ttls and cache headers. And direct browsing to the
subresources won't follow the non-revalidation policies.

It's exactly what facebook (and others need). Define the reload behavior,
but rather than doing it in the sub-resources, specify the behavior on the
hosting page directly.

-- 
Guille -ℬḭṩḩø- <[e-mail]>
:wq