Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Subject: Re: Compatible Cookie Parsing
From: Oleg Kalnichevski <o.kalnichevski@dplanet.ch>
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
In-Reply-To: <001801c30188$a27baca0$bd18f4d8@knightsofthenet.com>
References: <24AFE4E4-6D64-11D7-AB90-00306557E112@u.washington.edu>
	 <001801c30188$a27baca0$bd18f4d8@knightsofthenet.com>
Content-Type: text/plain
Organization: 
Message-Id: <1050233396.1651.65.camel@kczrh-okt22.corp.bearingpoint.com>
Mime-Version: 1.0
Date: 13 Apr 2003 13:29:56 +0200
Content-Transfer-Encoding: 7bit

Hi Brett

This problem has already been been reported

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11240

The cookie grossly violates RFC 2109. Currently I do not see a clean
solution to the problem. There will always be ambiguity no matter what
kind of parser is employed, unless certain assumptions are made. For
instance, how is such cookie supposed to be parsed?

Set-Cookie: visitorCookie=045uZ7jW,visitorCookie2=whatever

The use of regular expressions has also been suggested in the past

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13031

I personally would not like to introduce an extra dependency unless
absolutely necessary. At the very least not before 2.0 release.

Oleg


On Sun, 2003-04-13 at 08:48, Brett Knights wrote:
> Hi,
> 
> I ran into a problem using HttpClient. It would not parse a cookie
> that is handled happily by both Mozilla and IE 6.
> 
> 
> The cookie was odd in that the cookie name contained commas.
> From the wire log the offending cookie was:
> DEBUG [main] httpclient.wire - << "Set-Cookie:
> visitorCookie=045uZ7jW,,,; Expires=Sat, 07-Jun-2003 15:25:54
> GMT[\r][\n
> 
> I have a fix for this that uses regular expressions and the
> org.apache.oro package.
> I have extended TestCookie to include my strange cookie and run the
> "test-nohost" tests.
> 
> Is it acceptable to include a new package? I believe it is under the
> same licensing terms as HttpClient itself is so that shouldn't be a
> problem.
> 
> It's also likely that the function the regex performs could be
> reproduced in code though I haven't got a lot of time for doing that
> right now.
> 
> 
> Brett Knights
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>