You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Ryan Hoegg <rh...@isisnetworks.net> on 2003/04/13 20:58:25 UTC
HttpClient as a full fledged Jakarta Project (was Re: Compatible
Cookie Parsing)
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
>>>>
>>>>
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
>
>
>
>
Re: HttpClient as a full fledged Jakarta Project (was Re:
Compatible Cookie Parsing)
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
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
>