Henrik Nordstrom wrote:
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.
OK.  that's the approach I've taken, but it leads to much lower cache utilisation, and it's pretty clear when you see every second site sending back

Expires: -1
Last-Modified: Thu, 18 Jun 2009 10:21:31 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

that actually it should be storable.  There are 4 directives and a cache validator and freshness information indicating the response can be stored, and 1 directive indicating it mustn't.  If it were a democracy.....

Sure this indicates general level of ignorance of site operators etc.  But the users of the sites that do this pay more to keep downloading invariant content that really should be cached.  It gets tempting to put an option into the UI like "ignore no-store directive if other directives indicate cachability".

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"

I think as Mark suggested, if you considered that the renderer simply uses the resource many times within the 1 page, you can consider it to be a single retrieval.  no-store doesn't mean you can't re-use the resource in a client.  You just can't store it.

Scanning such content for viruses could be a real problem though, if you aren't allowed to spool it to disk, you'd need to set a size limit on content that could be transferred with no-store to protect from resource overuse.



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...



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