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 Wed, 05 May 2004 16:23:00 GMT
TOKILEY@aol.com wrote:
> If this fellow were to simply 'stuff' his Cookie into the
> 'extra text' part of the User-Agent: string and send
> out a "Vary: User-Agent" along with the response
> then it would actually work the way he expects it too.

Thanks to Roy and Kevin for your insight. Sorry if this thread is
perhaps a bit off-topic for this list, but I hope you can indulge me
just a little longer. When I saw Roy's response regarding the 'Vary'
header, I thought that this would be exactly what I was after - you
could set 'Vary: Cookie' and then the browser would see that it should
reget the page if the cookie has changed. But this didn't seem to work
at all in practice. I am testing with the following sequence:

1. Get a page, which has Cache-Control and Expires headers set so that
it will be cached
2. Go to another page, where I use a form to change the option cookie
3. The options form sets the cookie and redirects the browser back to
the original page
4. The original page is displayed, not new version - browser doesn't
revalidate.

I have set all the headers, this is an example:

shell> HEAD http://dev.crazyguyonabike.com
200 OK
Cache-Control: must-revalidate; s-maxage=900; max-age=901
Connection: close
Date: Wed, 05 May 2004 16:08:34 GMT
Server: Apache
Vary: Cookie
Content-Length: 7020
Content-Type: text/html
Expires: Wed, 05 May 2004 16:23:35 GMT
Last-Modified: Wed, 05 May 2004 16:08:34 GMT
Client-Date: Wed, 05 May 2004 16:08:35 GMT
Client-Response-Num: 1
MSSmartTagsPreventParsing: TRUE

So I am setting the Cache-Control to cache the page, and the client is
directed to revalidate. I say in the Vary header that Cookie header must
be taken into account. But the browser simply fails to revalidate the
original page at all. If I manually refresh then it gets the correct
version, but I can't control manual refreshes (or user options) on the
browser end. I would simply love to be able to hit that "sweet spot"
where the browser caches the page, but also sees that some magic
component has changed and thus the old version of the page in the cache
cannot be used any more.

When I saw Kevin's response, it made perfect sense at first, because
what he describes is exactly what I experienced above. Neither Mozilla
1.4 or IE 6 appear to take any notice of the 'Vary: Cookie' header. I
decided to try Kevin's suggestion re the User-Agent field, but after
looking at this further I am very confused. The User-Agent field is
something that is passed in *from* the client, not *to* the client from
a server. Why would IE or any other client even look at a User-Agent
field? Ok, ok, I understand, the whole point is that this is a "hack",
but even so it doesn't seem to work for me. I tried setting the
User-Agent field:

shell> HEAD http://dev.crazyguyonabike.com
200 OK
Cache-Control: must-revalidate; s-maxage=900; max-age=901
Connection: close
Date: Wed, 05 May 2004 16:08:34 GMT
User-Agent: Mozilla/4.0 (compatible; opts=300)
Server: Apache
Vary: User-Agent
Content-Length: 7020
Content-Type: text/html
Expires: Wed, 05 May 2004 16:23:35 GMT
Last-Modified: Wed, 05 May 2004 16:08:34 GMT
Client-Date: Wed, 05 May 2004 16:08:35 GMT
Client-Response-Num: 1
MSSmartTagsPreventParsing: TRUE

As you can see, I've encoded the opts cookie into the User-Agent header.
Am I doing this right? Nothing appears to change, indeed now IE doesn't
even get the proper version when I hit 'Refresh'. Maybe I'm being dense
and didn't read the instructions correctly, but it seemed like this was
what was being suggested.

Once again, I apologize if this is overly obvious or off-topic, but I
have the feeling that I'm just missing something obvious here. Any
insight would be much appreciated. In summary, the problem currently
appears to be that neither Mozilla or IE appears to even want to
revalidate the original page after the cookie has changed. When the
browser is redirected back to the original page (using identical URL)
from the options form, both browsers just use their cached version,
without even touching the server at all. No request, nothing. When I use
the 'Vary: Cookie' header, then manually refreshing does get the new
version. I know that browser settings can determine how often the
browser revalidates the page, but I can't tell random users on the
internet to change their settings for my site. I would have thought that
it should be possible for a page to be cached, and yet still be
invalidated by the cookie (or, in the general case, some 'Vary' header)
changing.

Anyway, thanks again...

-Neil

Mime
View raw message