


From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 18 Jun 2009 11:54:38 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: Mark Nottingham <mnot@mnot.net>, "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <1245318878.15069.334.camel@localhost.localdomain>
tor 2009-06-18 klockan 13:08 +1200 skrev Adrien de Croy:
> has there been much past discussion on precedence for seemingly 
> conflicting directives though?

Not really.

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

But no-store is a MUST and anything related to actually caching stuff is
merely a MAY so imho there isn't much room for getting this wrong.

But just as Yngve I don't quite like the new wording for no-store. The
old wording was more suited for it's purpose. There is perfectly valid
situations where a client (user-agent or similar end consumer) MAY
temporarily cache the response in memory, as long as it makes sure there
is no risk the response leaks outside the client (no "permanent"

Regarding cache validators there is applications where these are very
useful even if the response as such isn't cached as such. Authoring,
conditional fetches (not validations, even if the request at HTTP level
looks the same), etc.

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

no-store MUST prevent any non-voilatile storage of the response.

But yes, if you are really paranoid then...

Received on Thursday, 18 June 2009 09:55:35 GMT
