W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

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

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 18 Jun 2009 13:08:09 +1200
Message-ID: <4A399379.2030107@qbik.com>
To: Mark Nottingham <mnot@mnot.net>
CC: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Henrik Nordstrom <henrik@henriknordstrom.net>

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.



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:40 UTC