hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <o.kalnichev...@dplanet.ch>
Subject Re: HttpClient as a full fledged Jakarta Project (was Re: Compatible Cookie Parsing)
Date Sun, 13 Apr 2003 20:29:43 GMT
Ryan,

I strongly believe that HttpClient has long outgrown the scope of Apache
Commons. However, not being actively involved in other Apache projects I
may have too HttpCleint-centric view on things. Clearly, if my opinion
counts, HttpCleint should be considered for promotion to a Jakarta level
project

Oleg   

On Sun, 2003-04-13 at 20:58, Ryan Hoegg wrote:
>  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
> >>>>        
> >>>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 


Mime
View raw message