You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <o....@dplanet.ch> on 2003/04/13 22:29:43 UTC
Re: HttpClient as a full fledged Jakarta Project (was Re:
Compatible Cookie Parsing)
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....@dplanet.ch>
> >>To: "Commons HttpClient Project"
> >><co...@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
>
Re: HttpClient as a full fledged Jakarta Project (was Re: Compatible
Cookie Parsing)
Posted by Jeffrey Dever <js...@sympatico.ca>.
I have these feelings as well. We have made some moves towards
seperation from commons proper with the mailing list and such as Ryan
stated. One key criteria of a top level project is that it have a
distinct "community". I'd say HttpClient clearly satisfys this
requirement. My expectation was that 2.0 would go out the door and then
we would discuss the idea of promotion.
I would be a strong supporter of promotion and would be willing to lead
the charge when the time comes.
Jandalf.
Oleg Kalnichevski wrote:
>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....@dplanet.ch>
>>>>To: "Commons HttpClient Project"
>>>><co...@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
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>