httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Gunton <n...@nilspace.com>
Subject Re: mod_proxy distinguish cookies?
Date Tue, 04 May 2004 13:33:25 GMT
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

Mime
View raw message