hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: bug report: invalid cookie format detected for IIS
Date Sun, 09 Jan 2011 20:00:34 GMT
On 9 January 2011 15:32, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sun, 2011-01-09 at 15:03 +0000, sebb wrote:
>> On 9 January 2011 11:38, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Sat, 2011-01-08 at 08:34 +0100, Magnus Leuthner wrote:
>> >> Hello developers,
>> >>
>> >> I've tried to use httpclient 3.x and 4.x with www.hotelextranet.com and
from
>> >> what I observe it always seems to get the cookie format wrong.
>> >
>> > The cookie is question violates the HTTP state management specification
>> >
>> >> The cookies
>> >> end up garbled unless I specifically set the "NETSCAPE" standard. The
>> >> "BESTFIT" of 4.x doesn't seem to be the best fit for this IIS6 server. The
>> >> headers are (anonymized):
>>
>> That's because there is no "expires" qualifier for the user cookie.
>>
>> The "expires" qualifier is unique to Netscape cookies, and is used to
>> identify them.
>>
>
> The "expires" attribute was defined as optional by the Netscape draft.
> Therefore, there can always be ambiguity as to whether or not a
> particular cookie conforms to the original draft document.

Indeed, that's what I meant

> Netscape
> style cookies are inherently ambiguous and there is simply no excuse to
> continue using them, especially on the server side, especially by
> companies like Microsoft.

True, however FIrefox handles the example OK, as does Opera.

So perhaps the BrowserCompatible Cookie Policy needs to be modified?

For example, if the Set-Cookie header has multiple elements, but only
the first has a value, and only the last has attributes, then it's
likely to be a Netscape cookie.

To be more certain, one could check all the Set-Cookie headers, and if
any have the expires attribute, then assume Netscape for all headers.
This might be harder to do, as the headers are normally processed independently.

Either or both of these could perhaps be added as an optional
behaviour (to avoid compatibility problems).

> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message