[EMAIL PROTECTED] wrote: > Bottom line: > > In order to do your 'Cookie' scheme and have it work with > all major browsers you might have to give up on the idea > that the responses can EVER be 'cached' locally by > a browser... but now you also lose the ability to have > it cached by ANYONE. > > There is no HTTP caching control directive that says... > > Cache-Control: no-cache-only-if-endpoint-user-agent > > Given the caching issues in most 'end-point' browsers... > There probably should be such a directive. > > The ONLY guy you don't want to cache it is the > end-point browser itself... but you DO want the > response available from other nearby caches so > your Content Origin Server doesn't get hammered > to death.
Thanks again Kevin for the insight and interesting links. It seems to me that there are basically three components here: My server, intermediate caching proxies, and the end-user browser. From my understanding of the discussion so far, each of these can be covered as follows: 1. My server: Cookies can be understood (i.e. queries are differentiated) by my server's reverse proxy cache. 2. Intermediate caching proxies: I can use the 'Vary: Cookie' header to tell any intermediate caches that cookies differentiate requests. 3. Browsers: Pass the option cookie around as part of the URL param list (relatively easy to do using HTML::Embperl or other template solution). So if the cookie is "opts=123", then I make every link on my site be of the form "/somedir/example.html?opts=123&...". This makes the page look different to the browser when the cookie is changed, so the browser will have to get the new version of the page. I don't actually use the URL param on the backend, only the cookie version of the value is used. The URL param is simply there to make the URL look different to the browser. Thus if someone posts a link to my website with opt=123 in the query string, and then someone with cookie opt=456 clicks on that link, they should successfully get the right version of the page. I think all this allows me to have pages be cached, while also allowing cookies to be used to store options. This does assume that any "real" proxy caches in the middle obey the "Vary: Cookie" header. If they get a request for a page in their cache from a browser with a different cookie to that associated with the cache entry, then presumably the cache is required to not use the cache entry and pass it through to the origin server. This obviously isn't ideal, but it attempts to address the world as it seems to be today. If anyone sees any potential problems with this sort of setup, then let me know... Thanks again, this has been a very enlightening discussion. -Neil
