Re: dont-revalidate Cache-Control header

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
>