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 14:29:39 GMT
Graham Leggett wrote:
> There is already a mechanism for caching different variants of a page -
> simply encode the info into the URL. This is supported on all browsers
> and cannot be switched off through user preference (as cookies can).
> Because a mechanism already exists, there isn't much point in changing
> the standard to accomodate a second method to do the same thing.

As I said previously, storing user options in the URL is "broken"
because following someone else's link to the same website erases your
options. I use this currently on my website, to pass an option for size
of pics (thumbnail, small or large). Every time someone posts a link to
a page on my website on some message board or email, they inevitably
include the whole query string, with whatever option they happen to have
at that moment. So every person who clicks on the link gets their option
overwritten by the pic option of the person who posted the link. I don't
see how anyone could see this as being a good way to do things.
 
> But you're also fighting with existing websites that use cookies to try
> and track individual requests, and there are a lot of them out there. If
> each different cookie was cached separately, then you're effectively
> caching separate copies of every page, which makes caching a waste of time.

I suggested expanding the cookie definition to include a type or
qualifier that could be used to say whether the cookie should be treated
as a param. Using cookies in this way would not put any more load on the
net than at present, if the default cookie behavior was left as it is
now (i.e. with additional qualifier being required in order to have the
cookie taken into account). Using a special cookie or using the URL are
both functionally equivalent as far as information being passed, the
crucial difference being that using a different URL would not erase your
options - they are being passed via cookie.

To emphasize: I am not suggesting that EVERY cookie out there already be
used by caches, but rather that we amend the standard so that certain
cookies CAN be taken into account. This would be very useful, imho.

One could make the argument that more traffic might be generated if
websites started using the cookie qualifier to make ALL cookies be used
by caches (thus ensuring that they would "see" every click by a
particular user, making tracking all that much easier). However I don't
think this would make any difference in reality, since websites that
want this functionality can already get it by setting the pages to be
no-cache. The cookie qualifier would add the benefit of being able to
cache pages that have the same options set as the same cache entry. 

The addition of a cookie cache qualifier would not break any existing
systems, because the default behavior of cookies remains unchanged. It
would also not put any more load on the net than would be caused by
sites passing options in the URL, since each request with a different
option in the URL would have to be cached differently anyway. We gain
something, and lose nothing, as far as I can tell.

All the best,

-Neil

Mime
View raw message