hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject HttpClient as a full fledged Jakarta Project (was Re: Compatible Cookie Parsing)
Date Sun, 13 Apr 2003 18:58:25 GMT
 From the user perspective, I think it is a little confusing for a 
Commons subproject to have a dependency on a Jakarta Project.  Are there 
other Commons subprojects who are doing this?

It seems that HttpClient might be ready to leave the Commons and become 
a full fledged Jakarta project.  Does anyone have any strong feelings 
for or against this?

Besides this small dependency issue, there is also the separate mailing 
list, the level of activity, and the large number of non-Apache projects 
using HttpClient.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Oleg Kalnichevski wrote:

>Brett,
>I expect 2.1 development trunk to be brunched out right after 2.0-beta1
>release which should take place within days. The regex patch for the 2.1
>branch will be quite welcome. 
>
>I guess we would still have to vote whether we want HttpCleint to be
>dependent on org.apache.oro. I personally a bit concerned about having
>too many external dependencies. However, the idea of leveraging regex
>package has been floated around by a few people, it does seem there will
>be little resistance. If we can get rid of all the ugly & error-prone
>custom parsing code in cookie & authentication classes, it would be
>worth paying the price
>
>Cheers
>
>Oleg
>
>On Sun, 2003-04-13 at 20:22, Brett Knights wrote:
>  
>
>>Granted the cookie violates rfc 2109 but isn't the purpose of
>>compatibility mode to allow us to work with sites that can be accessed
>>from the major browsers?
>>
>>Your example
>>    
>>
>>>Set-Cookie: visitorCookie=045uZ7jW,visitorCookie2=whatever
>>>      
>>>
>> would be parsed as 2 cookies.
>>
>>The approach I used was that the first cookie begins at the start of
>>the set-cookie header and breaks on the pattern /, *\w+ *=/. I suppose
>>it's possible to have a cookie like:
>>Set-Cookie: visitorCookie="045uZ7jW,visitorCookie2=whatever" but that
>>could also be handled by a Perl5 type regular expression. If a
>>decision is made to include the regular expression library I'd be
>>happy to add code and a test case to handle that as well.
>>
>>Each separate cookie is then run through a function that is almost the
>>same as the code currently used to parse individual cookies. The
>>special date handling section is no longer required because we are no
>>longer breaking on every comma. Dates, BTW, imply to me that the spec
>>writers probably didn't have the convenience of StringTokenizer in
>>mind for processing cookies.
>>
>>Brett
>>
>>PS
>>I totally agree with
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13031.
>>Regular expressions allow for much faster development, less code and
>>less and more flexible code. Sure care has to be taken so you don't
>>unduly slow down the system with the extra code that is running but
>>"it's easier to optimize code that runs than to get optimized code to
>>run" :-)
>>
>>----- Original Message -----
>>From: "Oleg Kalnichevski" <o.kalnichevski@dplanet.ch>
>>To: "Commons HttpClient Project"
>><commons-httpclient-dev@jakarta.apache.org>
>>Sent: Sunday, April 13, 2003 4:29 AM
>>Subject: Re: Compatible Cookie Parsing
>>
>>    
>>
>>>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
>>>>        
>>>>


Mime
View raw message