httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Gunton <>
Subject Re: mod_proxy distinguish cookies?
Date Wed, 05 May 2004 21:42:13 GMT 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

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.


View raw message