Re: dont-revalidate Cache-Control header

> > - 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 adds a header by mistake to not
revalidate from domain If it's a mistake, they can
remove the header easily, and 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. can only disable
revalidations on other *different* domains and those are effective for
sub-resources only, no direct page navigations.

Imagine page tries to use maliciously as a
subresouce and request not revalidation. If has a cache
control header, it will be obeyed, and client reloads on won't cause
revalidation of But people browsing to
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 -ℬḭṩḩø- <>

Received on Thursday, 16 July 2015 20:03:52 UTC