Re: dont-revalidate Cache-Control header

On Thu, Jul 16, 2015 at 1:07 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 16 July 2015 at 13:03, Guille -bisho- <bishillo@gmail.com> wrote:
> > 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.
>
> That's a bizarre limitation.  It means that you have to own or use
> servers (or two names) in order to use the feature.  That's a pretty
> arbitrary limitation.
>

Well, yes, we can allow the same domain too.


> It also doesn't work, because if you do own the two names, you can use
> one to freeze the other.
>

Again, it will only work for sub-resources, and the resources loaded still
need the cache-headers.

If a.com freeze b.com/index.html, it will be freezed only for reloads on
a.com! and you can unfreeze at any time removing the policy from a.com.
Loading b.com will work as normal, won't be following any policies imposed
by a.com.

To be clear, the policies specified on a page will be only valid during the
load of sub-reources for THAT page. The cached resources won't have any
"static" property associated, will follow the same current cache control
policies in use. We will just allow pages to request the browser not to
revalidate cached content for domains of their choice.

Like I said, you can implement your proposed solution today, without
> writing any standards.  Sure, only Chrome supports it right now, but
> that's a whole lot more of the web than none of it.
>

AFAIK CacheStorage for service workers does not reuse the internal browser
cache, it's more limited and I suspect implementing this with service
workers will be far slower in general. It's good for implementing an
offline application, but not as good for implementing a general browser
cache solution.

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