Rather just use URL parameters. As I recall RFC2616 does not consider a request with a different cookie a different variant, so even if you patch your server to allow it to differentiate between cookies, neither the browsers nor the transparent proxies in the path of the request will do what you want them to do :(
Well, that truly sucks. If you pass options around in params then whenever someone follows a link posted by someone else, they will inherit that person's options. The only alternative might be to make pages 'No-Cache' and then set the 'AccelIgnoreNoCache' mod_accel directive (which I haven't tried, but I assume that's what it does)... so even though my server will get hit a lot more, at least it might be stopped by the proxy rather than hitting the mod_perl.
This is probably your best bet.
From what you are saying, it would appear that HTTP is broken with regard to cookies and caching. I thought they had all that sorted out a while back. Never mind...
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.
Regards, Graham --
