- From: Ben Maurer <ben.maurer@gmail.com>
- Date: Thu, 16 Jul 2015 18:45:32 +0100
- To: Guille -bisho- <bishillo@gmail.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABgOVaKYPt9TY+0ejTSS6K1OBoWRepvR3SBhdR6rvyC0LF9qfg@mail.gmail.com>
If ga.js were served with a max-age of 1 year, the product would still be pretty screwed. Users would cache the resource in their browser for a long time and it would only be refreshed if the user happens to ctrl+r on a site that has ga.js. Same is true of www.foo.com/, though the user is more likely to reload if they see an entire web page break. -b On Thu, Jul 16, 2015 at 6:38 PM, Guille -bisho- <bishillo@gmail.com> wrote: > >> 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 >
Received on Thursday, 16 July 2015 17:52:15 UTC