On Wed, 17 Nov 2004, Phil Endecott wrote:
I have now progressed a little; some clues in the Apache mod_cache source code pointed me to RFC2616 section 13.9 which says that, even though you use the nice HTTP 1.1 functions to declare the cacheability of your content, anything with a "?" in the URL must not be cached because that is "traditional". Aaarrgghh!!!
The section is somewhat poorly worded. Explicit expiry time is indicated either by Expires or Cache-Control max-age related headers.
But as I said, the recommended squid.conf shipped with Squid does deny caching of any such URLs by the no_cache directive, mostly to make sure this section is not violated when people play with their refresh_pattern settings.
The "must-revalidate" may also be a bit troublesome, and with "Vary: Cookie" it should not really be needed, should it?
The page must still be revalidated even if the cookie has not changed, so I think both are needed - unless there is something in RFC2616 that adds an additional dependency.
No you are correct. From your earlier description it only looked like the cookie only had impact on the result and that the page otherwise was static within your defined expiry time.
If it really is the case that you server needs to be queried on each and every view of the page (no freshness ttl allowed) then must-revalidate is suitable.
Note: If there is personal cookie information sent in the request there is little or no benefit of a shared cache for those replies. It is in such case better if you also send "Cache-Control: s-max-age=0" in the personal replies to hint to shared caches that these replies does not make sense to cache.
It should also be noted that all replies for this URI needs to have the Vary: Cookie header. Many misunderstands how Vary works and only sends it when the request had the "special" property (in your case having the correct cookie), forgetting to send it in the "default" case.
Regards Henrik
