You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Kalnichevski, Oleg" <ol...@bearingpoint.com> on 2002/11/29 18:52:38 UTC
[PATCH] Cookie default version fix, Cookie.parse() method refactored
Changes:
1) This patch fixes the problem of Cookie class assuming Netscape cookie format per default. With this fix RFC 2109 compliant validation applies unless the cookie version is explicitly set to 0 (Netscape cookie draft)
2) I have also taken liberty in heavily refactoring the Cookie.parse() method
- I have tried to restructure the code by separating parsing and validation processes. The code is a bit more modular now
- I have improved (or so I'd like to hope) exception handling and logging, which was next to awful, at least in my humble opinion. Stuff should be more consistent now
- The code should have gotten somewhat cleaner. (Code clarity is a subjective matter, though, so critique is always welcome)
All unit tests run fine, however I sense more testing may be needed.
Let me know what you think
Oleg
-----Original Message-----
From: Oleg Kalnichevski [mailto:o.kalnichevski@dplanet.ch]
Sent: Thursday, November 28, 2002 22:03
To: Commons HttpClient Project
Subject: Re: Special domains as defined by Netscape do not seem to
make much sense (Cookies of all countries, unite!!!)
Brett,
You are absolutely right. Cookies with version attribute set to 0 should
still be treated in accordance with the Netscape's draft. The problem is
that currently the HttpClient assumes cookie version 0 per default. That
is the cause of the problem. I believe unless version 0 is explicitly
specified cookie format should be assumed conforming to the RFC 2109.
That's it. That will solve the problem. Anyone sees that differently?
Oleg
On Thu, 2002-11-28 at 20:30, Brett Knights wrote:
> > From: "Danny Burkes" <db...@netable.com>
> > It seems clear to me that HttpClient should conform to RFC2109,
> which
> > superceded Netscape's draft. Section 4.3.2 of RFC2109 clearly lays
> out the
> > rules of cookie rejection, and HttpClient should implement to those
> rules.
> > IMHO, Netscape's draft is just some old cruft, and you shouldn't
> worry about
> > it. Stick to the RFC.
>
> I haven't read the whole of rfc2109 but it does say that cookies
> complying with it are version 1 cookies and should contain a version
> field identifying it as such.
>
> The netscape spec is for version 0 cookies.
>
> If rfc 2109 is a cleaned up superset of the netscape spec then by all
> means ignore the netscape spec.
> If, however, the netscape spec defines different behaviour then you
> should still conform to the netscape spec for version 0 cookies except
> in the case where it is clearly wrong or doesn't reflect a commonly
> accepted practise (the case here)
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Oleg Kalnichevski <o....@dplanet.ch>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Cookie default version fix, Cookie.parse() method refactored
Posted by Jeffrey Dever <js...@sympatico.ca>.
Committed. Factoring looks good. Still a bit verbose on logging, but
an improvement.
-jsd
Kalnichevski, Oleg wrote:
>Changes:
>
>1) This patch fixes the problem of Cookie class assuming Netscape cookie format per default. With this fix RFC 2109 compliant validation applies unless the cookie version is explicitly set to 0 (Netscape cookie draft)
>
>2) I have also taken liberty in heavily refactoring the Cookie.parse() method
>- I have tried to restructure the code by separating parsing and validation processes. The code is a bit more modular now
>- I have improved (or so I'd like to hope) exception handling and logging, which was next to awful, at least in my humble opinion. Stuff should be more consistent now
>- The code should have gotten somewhat cleaner. (Code clarity is a subjective matter, though, so critique is always welcome)
>
>All unit tests run fine, however I sense more testing may be needed.
>
>Let me know what you think
>
>Oleg
>
>
>
>
>
>
>-----Original Message-----
>From: Oleg Kalnichevski [mailto:o.kalnichevski@dplanet.ch]
>Sent: Thursday, November 28, 2002 22:03
>To: Commons HttpClient Project
>Subject: Re: Special domains as defined by Netscape do not seem to
>make much sense (Cookies of all countries, unite!!!)
>
>
>Brett,
>You are absolutely right. Cookies with version attribute set to 0 should
>still be treated in accordance with the Netscape's draft. The problem is
>that currently the HttpClient assumes cookie version 0 per default. That
>is the cause of the problem. I believe unless version 0 is explicitly
>specified cookie format should be assumed conforming to the RFC 2109.
>That's it. That will solve the problem. Anyone sees that differently?
>
>Oleg
>
>
>On Thu, 2002-11-28 at 20:30, Brett Knights wrote:
>
>
>>>From: "Danny Burkes" <db...@netable.com>
>>>It seems clear to me that HttpClient should conform to RFC2109,
>>>
>>>
>>which
>>
>>
>>>superceded Netscape's draft. Section 4.3.2 of RFC2109 clearly lays
>>>
>>>
>>out the
>>
>>
>>>rules of cookie rejection, and HttpClient should implement to those
>>>
>>>
>>rules.
>>
>>
>>>IMHO, Netscape's draft is just some old cruft, and you shouldn't
>>>
>>>
>>worry about
>>
>>
>>>it. Stick to the RFC.
>>>
>>>
>>I haven't read the whole of rfc2109 but it does say that cookies
>>complying with it are version 1 cookies and should contain a version
>>field identifying it as such.
>>
>>The netscape spec is for version 0 cookies.
>>
>>If rfc 2109 is a cleaned up superset of the netscape spec then by all
>>means ignore the netscape spec.
>>If, however, the netscape spec defines different behaviour then you
>>should still conform to the netscape spec for version 0 cookies except
>>in the case where it is clearly wrong or doesn't reflect a commonly
>>accepted practise (the case here)
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>------------------------------------------------------------------------
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>