Re: mod_proxy distinguish cookies?

[TOKILEY]

> Roy T. Fielding wrote:
>
>> I do wish people would read the specification to refresh their memory
>> before summarizing.  RFC 2616 doesn't say anything about cookies -- it
>> doesn't have to because there are already several mechanisms for marking
>> a request or response as varying.  In this case
>>
>>    Vary: Cookie
>>
>> added to the response by the server module (the only component capable
>> of knowing how the resource varies) is sufficient for caching clients
>> that are compliant with HTTP/1.1.
>
> Graham wrote...
>
> My sentence "RFC2616 does not consider a request with a different cookie
> a different variant" should have read "RFC2616 does not recognise
> cookies specifically at all, as they are just another header". I did not
> think of the Vary case, sorry for the confusion.
>
> Regards,
> Graham

"Vary" still won't work for the original caller's scenario.

Few people know this but Microsoft Internet Explorer and other
major browsers only PRETEND to support "Vary:".

In MSIE's case... there is only 1 value that you can use with
"Vary:" that will cause MSIE to make any attempt at all to
cache the response and/or deal with a refresh later.

That value is "User-Agent".

MSIE treats all other "Vary:" header values as if it
received "Vary: *" and will REFUSE to cache that
response at all.

This means that if you try and use "Vary:" for anything
other than "User-Agent" then the browser is going to
not cache anything (ever) and will be hammering away at
the unlucky nearest target ProxyCache and/or Content Server.

Why in the world an end-point User-Agent would only be
interested in doing a "Vary:" on its own name ( which it
already knows ) ceases to be a mystery if you read the
following link. The HACK that Microsoft added actually
originated as a problem report to the Apache Group itself
back in 1999...

URI title: Client bug: IE 4.0 breaks with "Vary" header.

http://bugs.apache.org/index.cgi/full/4118

Microsfot reacted to the problem with a simple HACK that
just looks for "User-Agent" and this fixed 4.0.

That simple hack is the only "Vary:" support MSIE really
has to this day.

The following message thread at W3C.ORG itself proves
that the "Vary:" problem still exists with MSIE 6.0 ( and other
major browsers )...

http://lists.w3.org/Archives/Public/ietf-http-wg/2002AprJun/0046.html

There is also a lengthy discussion about why "Vary:" is a
nightmare on the client side at the mod_gzip forum.
The discussion centers on the fact that major browsers will
refuse to cache responses locally that have
"Vary: Accept-encoding" and will end up hammering
Content Servers but the discussion expanded when it
was discovered that most browsers won't do "Vary:" at all.

http://lists.over.net/pipermail/mod_gzip/2002-December/006838.html

As far as this fellow's 'Cookie' issue goes... there is, in fact, a
TRICK that you can use ( for MSIE, anyway ) that
actually works.

Just defeat the HACK with another HACK.

If a COS ( Content Origin Server ) sends out a
"Vary: User-Agent" then most major browsers
( MSIE included ) will, in fact, cache the response
locally and will 'react' to changes in "User-Agent:"
field when it sends out an "If-Modified-Since:'
refresh request.

If you create your own psuedo-cookies and just hide
them in the 'extra' text fields that are allowed to be
in any "User-Agent:" field then Voila... it actually WORKS!

I know that's going to send chills up Roy's spine but
it happens to actually WORK OK.

Nothing happens other than 'the right thing'.

MSIE sees a 'different' "User-Agent:" field coming
back and could actually care less WHAT the
value is... it only knows that it's now 'different' and
so it just goes ahead and accepts a
'fresh' response for the "Vary:".

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.

Nothing else is going to solve the problem with MSIE,
I'm afraid, other than this 'HACK the HACK'.

Later...
Kevin