- 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>
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" storage). 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... Regards Henrik
Received on Thursday, 18 June 2009 09:55:35 UTC