Henrik Nordstrom wrote:
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
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?
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.
Last-Modified: Thu, 18 Jun 2009 10:21:31 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-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
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
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