Re: httpbis-p6-cache-06 and no-store response directive

has there been much past discussion on precedence for seemingly 
conflicting directives though?

e.g. if you get a no-store plus public, or no-store + any other 
directive that implies it could be stored / revalidated.

IMO a site that really wants to prevent caching should use no-store, and 
not emit Expires, Last-Modified, or ETag.

in the current www environment, honouring no-store over and above other 
directives has a significant impact on cache usefulness.

Regards

Adrien


Mark Nottingham wrote:
> Exactly. This is a problem that can be addressed by evangelisation and 
> education.
>
> E.g., Curl until quite recently emitted Pragma: no-cache, but as of 
> this January (IIRC) this changed.
>
>
> On 17/06/2009, at 7:12 AM, Henrik Nordstrom wrote:
>
>> mån 2009-06-15 klockan 16:42 +0200 skrev Yngve Nysaeter Pettersen:
>>
>>> As I said above: If they made the choice. In many cases I don't 
>>> think they
>>> did more than select a development environment that made the choice for
>>> them, based on what is supposed to provide a "revalidate each time the
>>> user clicks on a link to this document"-functionality, that is, the 
>>> same
>>> as "Cache-Control: max-age=0" and "no-cache".
>>
>> All environments I have seen support setting these kind of things if you
>> care about them, and emit a default "do not cahe this response" header
>> if the author / site developer using such environment don't care. Most
>> people who don't care simply do not know, and quite happily try to
>> accomodate for caching when they learn what it is.
>>
>> Blaiming the dev environment for emitting a safe low-performance default
>> cache profile won't get us very far, neither is trying to work around
>> this in the cache layer. This situation will persist, and any changes we
>> make to the protocol will only get reflected in those dev environments
>> using the new names, until the content/site developers gets their acts
>> together.
>>
>> This is a case of careless developers making their sites slower than
>> they need to be, not a specifacion fault, and not causing an error of
>> any kind, just slow performance due to content author/developer
>> ignorance, just as the 100 other asoects which makes web content
>> delivery slower than it need to be and is as frequently ignored by
>> content developers/authors.
>>
>> Regarding some of the big sites using this that can only be assumed to
>> be their choice, quite likely due to browser bugs in dealing with
>> no-cache or Vary:. Many of these sites uses Cookie based logins or user
>> identification, with a farily large userbase of "known users" who do get
>> slightly modified content compared to anonymous readers.
>>
>> Regards
>> Henrik
>>
>
>
> -- 
> Mark Nottingham     http://www.mnot.net/
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Thursday, 18 June 2009 01:05:23 UTC