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 <ol...@apache.org> on 2005/08/27 01:40:05 UTC
[Cookie2] First impressions
Samit,
These are my first impressions about the overall design. All my
suggestions are primarily intended to minimize the impact on the
existing API. They are not necessarily the best ideas from the design
perspective. However, since we are redesigning 3.0 API anyway, I
personally do not see a big problem with that.
(1) We should not change the CookieSpec interface. I am not entirely
sure CookieSpec#getCookieVersion() is necessary at all. I think the
CookiePolicy class can be used instead to achieve the same net result. A
method of the CookiePolicy class that returns a cookie spec given the
cookie version may well do the job
(2) Cookie class changed to include RFC2965 specific attributes. I would
rather extend Cookie class and put all RFC2965 specific attributes into
a Cookie2 class, if that is feasible.
(3) We have 39 failing test cases
Test cases breakage must be fixed before the deadline. Other stuff is
subjective and thus can be addressed past Sept 1st, provided you agree
with my points
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] First impressions
Posted by Samit Jain <ja...@gmail.com>.
Roland,
Thats a good argument. I would like to add that even if the server is
RFC 2965 compliant or understands multiple cookie specs in the same
header (which I highly doubt), there is a high probability that it is
backward compliant with old specification and will understand old
style formatted cookies. In addition to this, we also send a Cookie2
header which informs the RFC 2965 compliant server that the client
understands Set-cookie2 cookies.
Samit
On 8/29/05, Roland Weber <RO...@de.ibm.com> wrote:
> Hi Samit,
>
> > There is some ambiguity regarding formatting cookies which include
> > both new-style and old-style cookies. I don't think it is appropriate
> > to format cookies differently in the same header. Therefore, if there
> > is an old-style cookie present amongst the cookies to be formatted, I
> > delegate all formatting to RFC2109 spec. But I may be wrong on this,
> > let me know ur suggestions.
>
> From RFC 2616, one could infer that multiple Cookie: headers must be
> concatenable into a single one. But there are two arguments against
> this conclusion:
>
> 1. Non-conforming Netscape style cookies (comma in date).
> 2. The "single-cookie-header" option has been introduced to HttpClient
> for interoperability with servers that are *not* fully conformant
> to the various HTTP related specs.
>
> If the server isn't able to understand multiple cookie headers, we
> should not expect it to understand multiple cookie specs in a single
> header either. I think your approach is appropriate.
>
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] First impressions
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Samit,
> There is some ambiguity regarding formatting cookies which include
> both new-style and old-style cookies. I don't think it is appropriate
> to format cookies differently in the same header. Therefore, if there
> is an old-style cookie present amongst the cookies to be formatted, I
> delegate all formatting to RFC2109 spec. But I may be wrong on this,
> let me know ur suggestions.
>From RFC 2616, one could infer that multiple Cookie: headers must be
concatenable into a single one. But there are two arguments against
this conclusion:
1. Non-conforming Netscape style cookies (comma in date).
2. The "single-cookie-header" option has been introduced to HttpClient
for interoperability with servers that are *not* fully conformant
to the various HTTP related specs.
If the server isn't able to understand multiple cookie headers, we
should not expect it to understand multiple cookie specs in a single
header either. I think your approach is appropriate.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] First impressions
Posted by Samit Jain <ja...@gmail.com>.
There is some ambiguity regarding formatting cookies which include
both new-style and old-style cookies. I don't think it is appropriate
to format cookies differently in the same header. Therefore, if there
is an old-style cookie present amongst the cookies to be formatted, I
delegate all formatting to RFC2109 spec. But I may be wrong on this,
let me know ur suggestions.
On 8/27/05, Michael Becke <mb...@gmail.com> wrote:
> The implementation of the RFC2965 spec itself appears to be fine, at
> least as a whole. The only big problem I see is with the integration
> into the rest of the code and compatibility with other cookie specs.
> I also agree with Oleg's comments. getCookieVersion() does not seem
> necessary, perhaps a CookieSpec2 interface would be better? Cookie2
> instead of changing Cookie also sounds good to me.
>
> In particular there are some issues with section 9 of the RFC.
> Currently there is no way to support just Set-Cookie2 and only RFC2109
> can be used in conjunction with Set-Cookie2. In addition the use of
> the Cookie2 header in the request does not appear to be correct by my
> reading. I also have some questions about what we should do when
> sending cookies as a single header and when there are old and new
> cookie to be sent.
>
> There are also some smaller things I noticed:
> - HttpMethodBase.buildCookie2RequestHeader() has default access which
> does not seem necessary.
> - There are a few System.out.println()s
> - The static vars added to Header and Cookie should be moved to
> HttpConstants and RFC2965Spec respectively.
>
> Mike
>
> On 8/26/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Samit,
> >
> > These are my first impressions about the overall design. All my
> > suggestions are primarily intended to minimize the impact on the
> > existing API. They are not necessarily the best ideas from the design
> > perspective. However, since we are redesigning 3.0 API anyway, I
> > personally do not see a big problem with that.
> >
> > (1) We should not change the CookieSpec interface. I am not entirely
> > sure CookieSpec#getCookieVersion() is necessary at all. I think the
> > CookiePolicy class can be used instead to achieve the same net result. A
> > method of the CookiePolicy class that returns a cookie spec given the
> > cookie version may well do the job
> >
> > (2) Cookie class changed to include RFC2965 specific attributes. I would
> > rather extend Cookie class and put all RFC2965 specific attributes into
> > a Cookie2 class, if that is feasible.
> >
> > (3) We have 39 failing test cases
> >
> > Test cases breakage must be fixed before the deadline. Other stuff is
> > subjective and thus can be addressed past Sept 1st, provided you agree
> > with my points
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] First impressions
Posted by Michael Becke <mb...@gmail.com>.
The implementation of the RFC2965 spec itself appears to be fine, at
least as a whole. The only big problem I see is with the integration
into the rest of the code and compatibility with other cookie specs.
I also agree with Oleg's comments. getCookieVersion() does not seem
necessary, perhaps a CookieSpec2 interface would be better? Cookie2
instead of changing Cookie also sounds good to me.
In particular there are some issues with section 9 of the RFC.
Currently there is no way to support just Set-Cookie2 and only RFC2109
can be used in conjunction with Set-Cookie2. In addition the use of
the Cookie2 header in the request does not appear to be correct by my
reading. I also have some questions about what we should do when
sending cookies as a single header and when there are old and new
cookie to be sent.
There are also some smaller things I noticed:
- HttpMethodBase.buildCookie2RequestHeader() has default access which
does not seem necessary.
- There are a few System.out.println()s
- The static vars added to Header and Cookie should be moved to
HttpConstants and RFC2965Spec respectively.
Mike
On 8/26/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> Samit,
>
> These are my first impressions about the overall design. All my
> suggestions are primarily intended to minimize the impact on the
> existing API. They are not necessarily the best ideas from the design
> perspective. However, since we are redesigning 3.0 API anyway, I
> personally do not see a big problem with that.
>
> (1) We should not change the CookieSpec interface. I am not entirely
> sure CookieSpec#getCookieVersion() is necessary at all. I think the
> CookiePolicy class can be used instead to achieve the same net result. A
> method of the CookiePolicy class that returns a cookie spec given the
> cookie version may well do the job
>
> (2) Cookie class changed to include RFC2965 specific attributes. I would
> rather extend Cookie class and put all RFC2965 specific attributes into
> a Cookie2 class, if that is feasible.
>
> (3) We have 39 failing test cases
>
> Test cases breakage must be fixed before the deadline. Other stuff is
> subjective and thus can be addressed past Sept 1st, provided you agree
> with my points
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] Patch checked in
Posted by Samit Jain <ja...@gmail.com>.
Hi,
I have created a new patch file (against
http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/branches/COOKIE_2_BRANCH/)
and attached it to bugzilla Bug 10813. I have also added this new file
(httpcookie2SVN-patch.082805-2100.diff) to
http://cvs.sourceforge.net/viewcvs.py/httpc-cookie2/httpc-cookie2/.
Summary of changes:
- Added Cookie2 class
- Added TestCookie2 class
- Updated RFC2965Spec class
- Updated TestCookieRFC2965Spec class
Current Status:
- Passed all tests
- Refactored code as per developers' comments
- Some TODOs remaining to be resolved in RFC2965Spec class.
Please review the code and let me know your valuable comments. Also,
please have a quick look at the TODO items in RFC2965Spec class and
let me know your suggestions.
thanks,
Samit.
On 8/28/05, Ortwin Glück <od...@odi.ch> wrote:
> Samit,
>
> Can you attach your patch file to the bugzilla issue report as well?
>
> Cheers
>
> Odi
>
> Samit Jain wrote:
> > Oleg,
> >
> > I think we have some problem with the COOKIE2 branch. The code in the
> > branch seems to be pretty old (not the one Ortwin reviewed). It was a
> > mistake on my part while updating the patch in the sourceforge
> > respository. I should always remove the patch file and add a new one,
> > since cvs will take the diff of patch files and then update the
> > repository patch.
> >
> > Anyways, now I will try to create a patch of my existing code and the
> > one in this branch and add a new patch file in sourceforge.
> >
> > I am making some changes to the code right now, so it will be done by
> > evening today.
> >
> > -Samit.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] Patch checked in
Posted by Ortwin Glück <od...@odi.ch>.
Samit,
Can you attach your patch file to the bugzilla issue report as well?
Cheers
Odi
Samit Jain wrote:
> Oleg,
>
> I think we have some problem with the COOKIE2 branch. The code in the
> branch seems to be pretty old (not the one Ortwin reviewed). It was a
> mistake on my part while updating the patch in the sourceforge
> respository. I should always remove the patch file and add a new one,
> since cvs will take the diff of patch files and then update the
> repository patch.
>
> Anyways, now I will try to create a patch of my existing code and the
> one in this branch and add a new patch file in sourceforge.
>
> I am making some changes to the code right now, so it will be done by
> evening today.
>
> -Samit.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] Patch checked in
Posted by Samit Jain <ja...@gmail.com>.
Oleg,
I think we have some problem with the COOKIE2 branch. The code in the
branch seems to be pretty old (not the one Ortwin reviewed). It was a
mistake on my part while updating the patch in the sourceforge
respository. I should always remove the patch file and add a new one,
since cvs will take the diff of patch files and then update the
repository patch.
Anyways, now I will try to create a patch of my existing code and the
one in this branch and add a new patch file in sourceforge.
I am making some changes to the code right now, so it will be done by
evening today.
-Samit.
On 8/27/05, Michael Becke <mb...@gmail.com> wrote:
> I would go with Oleg's suggestion. No point in muddying up the trunk
> until after 3.0 final. Merging in the cookie2 changes shouldn't be
> difficult as they are quite isolated and trunk is not likely to change
> much more until after 3.0.
>
> Mike
>
> On 8/27/05, Ortwin Glück <od...@odi.ch> wrote:
> > Hey Oleg,
> >
> > No problem really. I am thinking of how to merge the two when the work
> > is done. In my experience I learnt not to use CVS merge. I have no
> > experience with SVN merging. So I would do it completely manually i.e.
> > using "svn diff" and "patch". If (and only if) all changes are
> > completely orthogonal (e.g. patches to TRUNK never interfere with any
> > code that was touched on the branch) you can:
> > * svn diff the branch's head against the branch start
> > * apply this diff to trunk
> > This should work smoothly. If the changes are not orthogonal however you
> > will have a pain i.t.a. merging the two.
> >
> > But it is of course safer to keep the branch in sync by backporting and
> > applying every patch we make for the trunk. The work is minimal as:
> > * there won't (hopefully) not be many more patches until final 3.0
> > * we expect orthogonal changes, so no real backport work but just
> > apply the same patch
> > When the work on the branch is finished the branch code would then just
> > completely replace everything that is on the trunk. Very easy merge indeed.
> >
> > How do the others feel about it?
> >
> > Odi
> >
> > PS. The term "backporting" is maybe a bit misleading. Read it as
> > "integrating".
> >
> >
> > Oleg Kalnichevski wrote:
> > > Odi,
> > >
> > > I would not even bother keeping the COOKIE_2_BRANCH in sync with the
> > > TRUNK. The Cookie2 changes are meant to be completely orthogonal to the
> > > standard HTTP functions. The only critical bit are the changes to the
> > > HttpMethodBase class that are luckily confined to just one or two
> > > method. My Evil Plan (tm) is to let COOKIE_2_BRANCH evolve completely on
> > > its own until the final 3.0 release. Immediately after the release we
> > > may want branch off the 3.0 release tag the HTTPCLIENT_3_0_BRANCH, go
> > > through the pain of merging COOKIE_2_BRANCH to the trunk only once and
> > > live happily ever after
> > >
> > > What do you think about it?
> > >
> > > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] Patch checked in
Posted by Michael Becke <mb...@gmail.com>.
I would go with Oleg's suggestion. No point in muddying up the trunk
until after 3.0 final. Merging in the cookie2 changes shouldn't be
difficult as they are quite isolated and trunk is not likely to change
much more until after 3.0.
Mike
On 8/27/05, Ortwin Glück <od...@odi.ch> wrote:
> Hey Oleg,
>
> No problem really. I am thinking of how to merge the two when the work
> is done. In my experience I learnt not to use CVS merge. I have no
> experience with SVN merging. So I would do it completely manually i.e.
> using "svn diff" and "patch". If (and only if) all changes are
> completely orthogonal (e.g. patches to TRUNK never interfere with any
> code that was touched on the branch) you can:
> * svn diff the branch's head against the branch start
> * apply this diff to trunk
> This should work smoothly. If the changes are not orthogonal however you
> will have a pain i.t.a. merging the two.
>
> But it is of course safer to keep the branch in sync by backporting and
> applying every patch we make for the trunk. The work is minimal as:
> * there won't (hopefully) not be many more patches until final 3.0
> * we expect orthogonal changes, so no real backport work but just
> apply the same patch
> When the work on the branch is finished the branch code would then just
> completely replace everything that is on the trunk. Very easy merge indeed.
>
> How do the others feel about it?
>
> Odi
>
> PS. The term "backporting" is maybe a bit misleading. Read it as
> "integrating".
>
>
> Oleg Kalnichevski wrote:
> > Odi,
> >
> > I would not even bother keeping the COOKIE_2_BRANCH in sync with the
> > TRUNK. The Cookie2 changes are meant to be completely orthogonal to the
> > standard HTTP functions. The only critical bit are the changes to the
> > HttpMethodBase class that are luckily confined to just one or two
> > method. My Evil Plan (tm) is to let COOKIE_2_BRANCH evolve completely on
> > its own until the final 3.0 release. Immediately after the release we
> > may want branch off the 3.0 release tag the HTTPCLIENT_3_0_BRANCH, go
> > through the pain of merging COOKIE_2_BRANCH to the trunk only once and
> > live happily ever after
> >
> > What do you think about it?
> >
> > Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] Patch checked in
Posted by Ortwin Glück <od...@odi.ch>.
Hey Oleg,
No problem really. I am thinking of how to merge the two when the work
is done. In my experience I learnt not to use CVS merge. I have no
experience with SVN merging. So I would do it completely manually i.e.
using "svn diff" and "patch". If (and only if) all changes are
completely orthogonal (e.g. patches to TRUNK never interfere with any
code that was touched on the branch) you can:
* svn diff the branch's head against the branch start
* apply this diff to trunk
This should work smoothly. If the changes are not orthogonal however you
will have a pain i.t.a. merging the two.
But it is of course safer to keep the branch in sync by backporting and
applying every patch we make for the trunk. The work is minimal as:
* there won't (hopefully) not be many more patches until final 3.0
* we expect orthogonal changes, so no real backport work but just
apply the same patch
When the work on the branch is finished the branch code would then just
completely replace everything that is on the trunk. Very easy merge indeed.
How do the others feel about it?
Odi
PS. The term "backporting" is maybe a bit misleading. Read it as
"integrating".
Oleg Kalnichevski wrote:
> Odi,
>
> I would not even bother keeping the COOKIE_2_BRANCH in sync with the
> TRUNK. The Cookie2 changes are meant to be completely orthogonal to the
> standard HTTP functions. The only critical bit are the changes to the
> HttpMethodBase class that are luckily confined to just one or two
> method. My Evil Plan (tm) is to let COOKIE_2_BRANCH evolve completely on
> its own until the final 3.0 release. Immediately after the release we
> may want branch off the 3.0 release tag the HTTPCLIENT_3_0_BRANCH, go
> through the pain of merging COOKIE_2_BRANCH to the trunk only once and
> live happily ever after
>
> What do you think about it?
>
> Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] Patch checked in
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2005-08-27 at 12:55 +0200, Ortwin Glück wrote:
> Oleg Kalnichevski wrote:
> > I have just check-in your patch pretty much as is. Please review if
> > everything is as it should be:
> > http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/branches/COOKIE_2_BRANCH/
>
> Excellent. So from now on any patch will have to be (backported and)
> checked in on COOKIE_2_BRANCH and TRUNK.
>
Odi,
I would not even bother keeping the COOKIE_2_BRANCH in sync with the
TRUNK. The Cookie2 changes are meant to be completely orthogonal to the
standard HTTP functions. The only critical bit are the changes to the
HttpMethodBase class that are luckily confined to just one or two
method. My Evil Plan (tm) is to let COOKIE_2_BRANCH evolve completely on
its own until the final 3.0 release. Immediately after the release we
may want branch off the 3.0 release tag the HTTPCLIENT_3_0_BRANCH, go
through the pain of merging COOKIE_2_BRANCH to the trunk only once and
live happily ever after
What do you think about it?
Oleg
> Cheers
>
> Odi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Cookie2] Patch checked in
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> I have just check-in your patch pretty much as is. Please review if
> everything is as it should be:
> http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/branches/COOKIE_2_BRANCH/
Excellent. So from now on any patch will have to be (backported and)
checked in on COOKIE_2_BRANCH and TRUNK.
Cheers
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
[Cookie2] Patch checked in
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2005-08-26 at 18:06 -0700, Samit Jain wrote:
> Hi Oleg,
>
>
Hi Samit,
I have just check-in your patch pretty much as is. Please review if
everything is as it should be:
http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/branches/COOKIE_2_BRANCH/
Most important is to fix the test case breakage. There are 39 test
failures, mostly in TestCookieCompatibilitySpec and
TestCookieRFC2109Spec test suites. That means your patch is likely to
have broken code in other cookie specs. Please see what can be done
about it.
I'll continue with the code review and will be committing small changes
here and there. I'll leave all the major changes up to you. Nonetheless,
just in case do update your local snapshot before creating patches. As
of now please test your code and create patches against the
COOKIE_2_BRANCH, not trunk
I'll be posting to the dev list about all my findings during the process
of the code review. So, stay tuned
Cheers,
Oleg
> > (1) We should not change the CookieSpec interface. I am not entirely
> > sure CookieSpec#getCookieVersion() is necessary at all. I think the
> > CookiePolicy class can be used instead to achieve the same net result. A
> > method of the CookiePolicy class that returns a cookie spec given the
> > cookie version may well do the job
>
> Okay.
>
> >
> > (2) Cookie class changed to include RFC2965 specific attributes. I would
> > rather extend Cookie class and put all RFC2965 specific attributes into
> > a Cookie2 class, if that is feasible.
> >
>
> yes that sounds good.
>
> > (3) We have 39 failing test cases
> >
> > Test cases breakage must be fixed before the deadline. Other stuff is
> > subjective and thus can be addressed past Sept 1st, provided you agree
> > with my points
>
> Which tests are failing. I did run the tests on my machine before
> submitting. What is the best way to run all the tests?
>
> thanks,
> Samit
>
>
>
> >
> > Oleg
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org