Graham Leggett wrote: > I would disagree - if a proxy on the net cached every variant of every > page simply based on a cookie header, there would so many different > variants of the same page in the cache that from a system resource > perspective the cache might as well not be there. Cookies only make > sense in most cases when caching has been switched off, as the cookie is > usually targeted at that single user only. > > Your application is a unique one, in that you're trying to improve the > performance of a single server on the net. This should be done within > the design of that server, not by trying to change the RFC to accomodate > what is a special case.
Is this really such a special case? I can't believe nobody else has wanted to implement a server like this. If you want to have a setup where there is a heavy backend app server, with a lightweight reverse proxy front end, and you also want to have pages be cached, AND have personalization of pages based on cookies, then it makes perfect sense to store user options in a cookie, and then for the pages to be cached taking cookies into account. That's pretty much what cookies were made for. In this case, a cookie that set 'opts=xxx' can be seen as equivalent to having 'opts=xxx' in the request query string - but instead of the parameter having to be present in the query string, it's there in the cookie. This is much more useful, because it means that this parameter can be set once in the browser, so that this user always uses this option on this server. All pages which have the same request and same option cookie would be seen as the same page by browsers and caches. Any pages with the same request, but different option cookie are treated differently. To the caches, this is no different from passing the option in the query string. I can see that not every cookie should be seen in this way. The solution to this would perhaps be an additional property for cookies to determine how they are treated by caches and browsers. In order to not break existing behavior, the default could be what happens now - i.e. cookies are ignored as far as differentiating requests. But if there was some cookie setting that said "user param" or something similar, then it could be used by browsers and intermediate caches to differentiate. If a website used the query string to pass options around, then every page that had a different option would have to be cached differently anyway, so this really doesn't add any additional stress to the network. It's simply moving an option from the query string into the cookie area, so that links posted around the internet don't contain users' individual settings. It just doesn't make any sense for website user options to be stored in the URL, because it makes a nonsense out of the whole concept of setting options - anytime you happen to click on some other user's link to the same website, it wipes out any options you set yourself. Cookies are made for this sort of thing. Some cookies (random numbers, tracking cookies) don't have to be treated in this way, but I think having an additional property that makes a cookie be treated in the same way as a query string param would be very beneficial. I don't know what hope there is for getting anything like this actually implemented in the standards... but if anyone has any ideas, I'm all ears... Thanks again, -Neil
