> > > - 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 -ℬḭṩḩø- <bishillo@gmail.com> :wqReceived on Thursday, 16 July 2015 20:03:52 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC