On Tue, 2003-10-28 at 21:54, Vincent Massol wrote:
Hi,
I've released Cactus 1.5-rc1 last week end. I bundle commons-httpclient
2.0 rc2 in it. I've just received this email below from a cactus user.
Is it true, as Ajay says, that commons-httpclient would only work on JDK
1.4 onwards (see
Mike, I see what you mean. Still, no matter how I look at it,
socket/connection timeout parameters on the HttpMethod level does not
seem right.
Let's approach the issue from a different angle. You seem to dislike the
idea of exposing HttpConnection objects contained by
I see, so the reason I don't see cookies in OC4J might be because they use
this method. Do you know if (and how) HttpClient supports this type of
session?
Arjan,
SSL support is completely independent from HttpClient. HttpClient simply
uses JSSE service to establish SSL connections. If JSSE
Ollie,
That was a conscious design decision. Ideally one should be using
HttpState#addCoookie method to add cookies to the HTTP state used by
HttpClient.
Lately, however, quite a few people complained about inability to add
'Cookie' request headers as a limitation of the existing cookie
a very
generic/extensible structure that would fit very well into other places
of our code.
Searching the archives revealed that Oleg Kalnichevski posted on Sept
23rd that he ported rc1 to be compatable with 1.1.8. Will this process
be continuing? Is there a 1.1.8 compatable version
Mike,
If you agree, I'll commit this one shortly.
Oleg
On Sun, 2003-10-19 at 17:16, Michael Becke wrote:
Looks good to me.
Mike
On Saturday, October 18, 2003, at 02:07 PM, Oleg Kalnichevski wrote:
I ran into a problem where the HttpClient kept thinking that the
connection
Patch committed to branch 2.0 and HEAD.
Oleg
On Sun, 2003-10-19 at 19:44, Michael Becke wrote:
Go for it.
Mike
On Sunday, October 19, 2003, at 12:50 PM, Oleg Kalnichevski wrote:
Mike,
If you agree, I'll commit this one shortly.
Oleg
On Sun, 2003-10-19 at 17:16, Michael Becke
junit.framework.*;
/**
* Simple tests for [EMAIL PROTECTED] HttpParser}.
*
* @author Oleg Kalnichevski
* @version $Id$
*/
public class TestHttpParser extends TestCase {
// Constructor
public TestHttpParser(String testName
PROTECTED] HttpParser}.
+ *
+ * @author Oleg Kalnichevski
+ * @version $Id$
+ */
+public class TestHttpParser extends TestCase {
+
+// Constructor
+public TestHttpParser(String testName) {
+super(testName
The fix is simple. But I failed to figure out is how on earth
responseBodyConsumed() got called with null responseConnection.
Tim, can you explain under what kind of circumstances NPE in
responseBodyConsumed occurs? A test case would be fantastic.
Cheers
Oleg
On Wed, 2003-10-15 at 23:28, Tim
Mike and all,
I would like one minor non-functional change to go in before the RC2 is
released. Any objections to that?
Oleg
On Mon, 2003-10-13 at 00:17, Michael Becke wrote:
2.0 RC2 has been tagged in CVS and the distribution has been created.
I would appreciate it if someone could verify
Chris,
Please see my comments in-line
On Fri, 2003-10-10 at 18:29, Christian Kohlschuetter wrote:
I completely agree with you that we all should write standards-compliant HTTP
web pages/CGI programs/Servlets etc.
Unfortunately, it is not always in our hands. As nearly everybody can write
+1
On Tue, 2003-10-07 at 23:16, Michael Becke wrote:
I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as
RC2 and proceed with a release. Please vote as follows:
--
Vote: HttpClient 2.0 RC2
Yue,
That can be done, of course. Feel free to file a feature request in the
bugzilla.
Oleg
On Mon, 2003-10-06 at 19:43, Yue Luo wrote:
Hi,
I wonder if in the next release a method like deleteAllCookies()
could be added to HttpState. I am developing a driver for a web
benchmark and
Mike,
Are there any reasons for NOT automatically releasing connection? I
can't think of any. We should still require
HttpMethod#releaseConnection() to be called explicitly regardless if
there was an exception or not, but in those cases where we can be sure
that the connection is not needed
Generally speaking I agree. I wanted to look at it more carefully
though to verify that a method that throws an exception has no case for
holding on to the connection. If you cannot think of any reason, then
that's good enough for me.
Mike,
You should not put too much faith into it. You
1.1 support as
far as my application is concerned. I doubt I would actively maintain
the port myself. Unless someone else steps in, the port would be pretty
much unmaintainable.
Oleg
Mike
Oleg Kalnichevski wrote:
Folks,
I just finished porting HttpClient 2.0rc1 to JRE 1.1. If there's enough
Mohsin,
Do you know what kind of HTTP server runs on the server side?
The HTTP server appears to be using the 'expect: 100-continue' handshake
even though the client did not request it.
You may what to try the following measures:
- activating 'expect: 100-continue' on the client side
- using
: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2003 11:52 AM
To: Commons HttpClient Project
Subject: Re: HTTP/1.1 status 100 help needed
Mohsin,
Do you know what kind of HTTP server runs on the server side?
The HTTP server appears to be using the 'expect
Folks,
I think we should release 2.0RC2 rather sooner than later. As far as I
can see there are only two things that are currently holding back the
release:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17569
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22654
Is there anything else on
Odi,
The patch looks fine to me. There is just a few minor points that I
would like to be considered before the patch is committed:
- DigestScheme#DigestScheme( String ) constructor should probably log a
warning message or even throw an exception if it encounters an
unrecognised 'qop' element.
Once of a sudden, testDuplicateProxyConnection started failing on me.
Anyone experiencing similar problem?
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Please take a look at the patch in bugzilla and let me know what you
think.
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
a RC1 currently. There is basically only
documentation and integration work going on. Oleg Kalnichevski, one of
the leading developers, is on vacation at the moment. So we will
probably not make a release until he returns (in two weeks time
AFAIK).
I am sorry that I can not give you an exact
Eric,
You are not the first one to complain about the problem. I think there's
a fairly easy way of solving it: all we have to do is to ensure that
only only automatically generated 'cookie' headers can ever be
overwritten.
Feel free to file a bug report.
Oleg
On Tue, 2003-08-26 at 03:10,
Roland, Mike and all.
Not only it appears to be a reasonable order of things, it also seems to
correspond to Sun's official recommendations
...
out.close();
in.close();
...
echoSocket.close();
...
These statements close the readers and writers connected to the socket
and to the standard input
I am back from holidays. I'll start working through the e-mails backlog
tomorrow and will try to catch up with things. Meanwhile, I am about to
submit the first draft of the new preference architecture. Let me know
what you think.
If you see better ways of implementing it, please let it be known.
Is it just that JCE/JSSE weren't combined with 1.2? So to be only
dependent on a single JDK [and not additional Sun jars], you'd need 1.4?
Not really. One can still happily run HttpClient on Java 1.2 (without
JCE JSEE installed at all) as long as HTTPS and NTLM are not used. An
attempt to
The reason for JDK 1.4 is due to trying to get more in. I think a JDK1.2
version should exist too, but it would not contain HttpClient (?) which I
thought might be 1.4 dependant now for SSL and would not include BeanUtils
with the current api munging.
Httpclient is still run-time
Folks,
I got indeed swamped with e-mails after having subscribed to Geronimo's
mailing list. sorry about that.
I already responded to Tim that I had no objections. Feel free to rename
the methods as you see fit.
Oleg
On Thu, 2003-08-14 at 04:50, Henri Yandell wrote:
Unless Oleg is a member of
lines of code to support 1.1.8 users.
Oleg
On Tue, 2003-08-05 at 18:07, Michael Becke wrote:
Ulrich Freyer-Hirtz wrote:
You're right. I've had a look into the Http.confs. On the Server are
to Apache installation. One runs as Proxie and uses SSL. The other is
a Webserver without SSL. So now I've to figure out, how to set the
.
Oleg
Kalnichevski To: Commons HttpClient Project
David,
As far as I can tell the code looks all right. My only guess was that
the parameters to NTCredentials constructor might have been messed up,
but that does not seem to be the case.
I just tested the latest snapshot of 2.0 branch and HEAD against Squid
proxy using Basic authentication
David,
I will make the fork available as soon as it is done. I do not think it
is going to happen too soon, though. I'll keep you posted.
Oleg
On Thu, 2003-08-14 at 21:36, [EMAIL PROTECTED] wrote:
Not extremely urgent, but I would definately be interested in using it when
you make it
Actually you helped us iron out quite a few issues with the
authentication logic. We should be thankful to you.
cheers
Oleg
On Wed, 2003-08-13 at 19:31, Rowe, David (CAG-CC MIS) wrote:
I know, it was missing an 'i' in Authentication, just for consistency.
Also, My credentials were
As I understood from your explanation, It is look like httpclient's initial
httpstate can not set to with above session / encrypted security cookies?
Is that right...
Reddy,
I am afraid my explanations so far have caused more confusion that
clarity. Of course, you can set any initial
OK. Now I know what is going on here. The server simply send the HTML
page body without ANY response header of what so ever. No wonder
HttpClient cannot find a status line. Stuff like that cannot work, as
far as I am concerned. Feel free to drop the webmaster of that site a
line.
Oleg
250k.)
Todd
- Original Message -
From: Oleg Kalnichevski [EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED]
Sent: Sunday, July 27, 2003 7:10 AM
Subject: Re: Performance Issue
Todd,
I think I have identified the problem or one of the problem
* Perhaps the isStale check is unnecessary for methods that can
simply repeat themselves, for example, GET, HEAD, OPTION, TRACE.
For those methods, we could allow a retry to fix the problem.
For methods such as POST and PUT, however, the isStale is probably
an
On Sun, 2003-07-27 at 14:24, Oleg Kalnichevski wrote:
Folks,
Sadly enough, I have to confirm the performance problem reported by Todd
Wolff [EMAIL PROTECTED]. HttpClient's performance as of 2.0 beta-1
degraded almost four-fold compared to 2.0 alpha-3. The problem is fairly
easy to reproduce
I think I tell the reason even without having seen the code. Since
beta-1 'expect: 100-continue' handshake is off per default, that can
make a huge difference in terms of performance with POST requests that
require authentication.
Just do the following
httppost.setUseExpectHeader(true);
Clemens,
Please see my comments below
On Fri, 2003-07-25 at 19:24, Clemens Marschner wrote:
Hi,
there are two issues I would like to bring up that were mentioned in this
list during the last months but were never resolved:
1. Java DNS handling as done by java.net.Socket is very
Yes, this is the algorithm. We decided to upgrade to ensure that URI
parsing was consistent across Apache. I think this was at the request
of Roy Fielding. Oleg, is that correct?
This is correct.
Oleg
-
To
- another option is to use the Expect: 100-continue header. This
feature requires HTTP 1.1 and is not well supported by all web servers.
Try HttpMethod.setRequestHeader(Expect, 100-continue)
David, one small correction. Instead of setting
HttpMethod.setRequestHeader(Expect,
Well said. The 2.0 release is really not what any of us wanted. I was
also looking to 2.1 as the first release 'done more or less right'. I
think we can still accomplish this. We may just have to ignore the
official guidelines for what constitutes a minor release.
It sounds like you
Mike and all
Is anybody planning to work on exception handling framework? If there
are any takers, please feel free to take the lead. Otherwise, I'll have
to do it, as it is really important fix that many other will depend
upon, and it has to be done rather sooner than later, IMHO.
Cheers
Oleg
can invest into it.
Cheers,
Oleg
On Sat, 2003-07-12 at 19:02, Michael Becke wrote:
Oleg,
Please feel free to start working on this. Though this bug is assigned
to me that was from the previous round of work and no longer applies.
Mike
On Saturday, July 12, 2003, at 11:32 AM, Oleg
Mike, BTW, the patch has not been applied to 2.0 branch. Did you just
forget about it or is there any particular reason why the patch should
not go into 2.0 release?
Oleg
On Fri, 2003-07-11 at 03:10, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED
Why is this the case? I have no idea. Anyone else has some thoughts on
this one?
Sung-Gu, maybe?
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This is one of many 'shady' areas of the HTTP spec. Basically there is
no standard way for the client to communicate to the server what coding
has been used to decode query parameters. I believe some browsers use
'Accept-charset or 'Accept-Language' headers to negotiate the locale
settings to be
I am a bit doubtful that the bug fix #20938 had anything to do with your
problem. Anyway, it can get the most recent nightly build at the
following location
http://cvs.apache.org/builds/jakarta-commons/nightly/commons-httpclient/
If the problem persists after upgrade, please refer to the
Yevgeni,
It is really hard to tell what is going on here. It can well be a
problem on the server side. What HTTP server are you targeting? You may
also want to consult the trouble-shooting for instructions on further
actions
http://jakarta.apache.org/commons/httpclient/troubleshooting.html
the same code with http and it works fine (as
expected I am getting a 404 from the server).
any light.. will be helpful.
-
NRR
--- Michael Becke [EMAIL PROTECTED] wrote:
The patch for 20938 should have been included in
beta 2.
Mike
Oleg Kalnichevski wrote:
I am a bit
) {
System.out.println(line);
}
} finally {
socket.close();
}
}
}
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:43 PM
To: Commons HttpClient Project
Subject: Re: HTTPClient exception
)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:250)
at com.Test.main(Test.java:32)
Exception in thread main
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:55 PM
To: Commons HttpClient Project
Subject: RE: HTTPClient
Mike,
Any objections to removing the most notoriously awful stuff like
Url*Method, disk buffering in GetMethod, as a first step?
Do you have any idea if '3.0 alpha1', '3.0 beta2', and '3.0 final'
milestone targets could be added to the Bugzilla?. I would like to go
through the open bug reports
HttpClient development team NO LONGER guarantees 2.0 API compatibility
of the CVS HEAD snapshots. Httpclient from now on is officially in alpha
development phase.
If your project relies on 2.0 API compatibility you should not be using
automatically generated nightly builds anymore. Please change
Release plan 2.1 committed.
Eric,
If there's still something that you want to add to or change in the
release plan, please let me know. If nobody volunteers, I'll start
writing 3.0 release plan shortly based on the architecture you suggested
Cheers
Oleg
On Fri, 2003-07-04 at 00:54, Michael
the socket. It works just fine for me.
Cheers
Oleg
On Thu, 2003-07-03 at 22:12, Laura Werner wrote:
Oleg Kalnichevski wrote:
Sadly enough, there's (there will be) no reliable way to interrupt a
request in the release 2.0. It is an unfortunate oversight on our part.
This feature is planned
Hi Eric
1) Some of the headers refer to 2.0, whereas the body of those same
sections refers to 2.1. I think you meant to change the headers
I have to confess that I am guilty of just taking 2.0 release plan as a
template, as I had never written release plans before. Apparently I have
by field of
interest, keyword, city, state, or other options and find the job you
want./title[\r][\n]
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 4:36 PM
To: Ross Rankin
Subject: RE: Cookie Issues
Ross,
Sorry for not being
. I don't even know
what else to try. Any suggestions?
Ross
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 2:18 PM
To: Commons HttpClient Project
Subject: Re: Posting Issues was RE: Cookie Issues
Ross,
I'd say giving
:14, Michael Becke wrote:
On Sunday, June 29, 2003, at 05:45 PM, Oleg Kalnichevski wrote:
Mike,
It does sound like a good idea to me, but could not it wait until 3.0,
as it does seem to be exactly what Eric has been proposing as a
framework of interfaces?
It might fall within
Zulfi,
First of all, Tomcat 4.0.4 can be considered fairly out-dated and is
known to have a few bugs. Do consider upgrading.
My guess is that the version of Tomcat you are running is having issues
with RFC2109 formatted cookies. Try using compatibility cookie policy
and see if it has any effect.
Ross,
However I noticed in my proxy traces the browser put all the cookies in one
line instead of separate lines for each cookie. Could that cause a problem?
Try using strict mode. In strict mode all cookies are sent as one
'Cookie' header.
cheer
Oleg
Zulfi, HttpClient never sends stuff it is not supposed to send. The
caller is responsible for providing the request body. HttpClient simply
transfers whatever content it is given. Please double-check your code
Oleg
On Fri, 2003-06-27 at 19:55, Zulfi Umrani wrote:
I am using a tunnel which shows
That's correct. We are well aware of the problem:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729
but cannot resolve it at this point as it would mean breaking existing
API. Once the release 2.0 is branched out, that is going to be one of
the first bug fixes
Cheers
Oleg
On Fri,
On Thu, 2003-06-26 at 23:40, [EMAIL PROTECTED] wrote:
I just got through Internationalizing a website... input and output. I
ran into the exact same issues, and as Andre states, you pretty much need
to check everywhere for byte[] -String and String-byte[].
Matt, we actually do. We do have
Amin,
It is not quite clear what is going on there. My best guess it that the
cookie sent by the target host is malformed and as such rejected by
HttpClient.
However, it is just a guess. We will be able to give more definitive
answers if you provide us with the wire log of the HTTP session in
the instructions given on
the link.
Please feel free to point out if I need to do something else or if I
should resend the file.
Regards,
Amit.
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2003 5:34 PM
To: Commons HttpClient
I fully agree. In 99% cases TRACE log produces no useful information. I
even usually grep through the logs excluding TRACE entries in order to
make them comprehensible.
Oleg
On Wed, 2003-06-25 at 10:42, Ortwin Glück wrote:
I think we should change the logging guide to set the log level to
Chris,
This problem is as old as software engineering itself. Code reuse
provides many benefits as well as many potential problems such as
versioning conflicts. In my opinion benefits still outweigh the
problems. Usually code reuse done right results in higher code quality,
provided that you get
Aaron,
I am afraid it is premature to draw such a conclusion. I will
double-check that it is not a bug in HttpClient and get back to you as
soon as I can.
Oleg
On Tue, 2003-06-24 at 18:15, Fa. MSG Hr. Liebling wrote:
After looking at the spec, the actual request looks ok (there should be 2
Matt,
No, there's no such mechanism in place. However, there's a way provide a
custom SSL implementation that meets your specific needs. Have a look at
the HttpClient SSL guide at the following location:
http://jakarta.apache.org/commons/httpclient/sslguide.html
There's a section on customising
Christian,
Let me present my take on these issues (See below):
On Wed, 2003-06-25 at 21:22, Christian Sell wrote:
hello all,
I am looking for a library to implement browser-like behavior, including
HTTP 1.1 conformat caching. I have 2 questions regarding HttpClient:
1. Has it ever
What I find a little disappointing is the fact that I am faced with
almost unsurmountable obstacles in doing this (i.e., if I want to avoid
hacking the code). Maybe someone with a better understanding of the
architecture has a suggestion..
Believe me, I am also REALLY unhappy with the
Mike, Laura, Adrian
In their pre-Java 1.4.1 form URLEncoder/URLDecoder classes are pretty
much unusable, as these classes always use default system charset, which
sometimes is not good enough. For instance, there's no way to properly
encode strings that simultaneously contain Cyrillic letters and
to plug in a custom CookieSpec.
I was wondering how to do it. For now, I will wait for 2.1 or download the
source and modify one of the CookieSpecs.
Thanks,
Ron Tower
- Original Message -
From: Oleg Kalnichevski [EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED
Rob,
This is a well known issue. According to the RFC 2109 comma is
considered a spacial character. Cookie values that contain special
characters MUST be in a quoted string. Please refer to the following bug
report for more details:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11240
The
Ron (I apologise for misspelling your name in my previous post),
You can easily subclass any of the CookieSpec classes. The trouble is
there's no way to plug a custom cookie spec into the existing
implementation of HttpClient. At the moment you have to modify
CookiePolicy class and recompile
Fix applied.
Oleg
On Fri, 2003-06-13 at 17:55, Thomas Winkler wrote:
hi,
there is NullPointer in HttpMethodBase.getResponseBody() when
HttpMethodBase.getResponseBodyAsStream() returns null.
InputStream is = getResponseBodyAsStream();
byte[] buffer = new byte[4096];
int len;
Fix applied. Please re-test against the most recent CVS snapshot
Oleg
On Thu, 2003-06-12 at 18:52, Kalnichevski, Oleg wrote:
Dan
I have to confirm that this is indeed a bug in HttpClient. The bug only affects
cookie paths that have one leading back slash, eg: '/whatever.php'. Cookie paths
Adrian,
I whole-heartedly support the idea of developing a suite of unit tests
dedicated to the proxied HTTP communication. The only catch here is that
such test cases would require a full blown proxy server. There seems to
be no way around it. In order to be able to test proxy related stuff I
As I said before, currently only Basic authentication can be used
preemptively. As far Digest scheme goes, theoretically it may be
possible to preemptively authenticate against a Digest protected
resource for which 'nonce', 'nonce count' and 'opaque' values are known.
There's no guarantee that a
with HttpClient URI are ../../../g and
../../../../g. I will look into these.
Mike
On Monday, June 9, 2003, at 03:35 PM, Oleg Kalnichevski wrote:
Folks,
It looks like this directly applies to us (see below). It also raises a
question of how we go about URI support in the future. Since
In general I think it would be nice for HttpClient to have more tools
for handling headers. One option would be to add a bunch of methods to
HttpMethod, but I think this would add too much clutter. Perhaps we
should have a HeaderUtil class with convenience methods for parsing,
Folks,
It looks like this directly applies to us (see below). It also raises a
question of how we go about URI support in the future. Since Sung-Gu has
pretty much retired from the project (he's been a no-show on this list
for several months already), URI stuff is ripe for a take over. Spinning
100 status code is supposed to be used internally by HTTP agents when
engaging in so-called 'expect: 100-continue' handshake. The target HTTP
server responds with status code 100 to tell the client that it is ok to
send the request body. The purpose of 'expect: 100-continue' handshake
is to avoid
Mike,
Why do not we indeed make a FAQ document out of this Q A session with?
Oleg
On Thu, 2003-06-05 at 22:18, Michael Becke wrote:
Om,
Nice set of questions. Looks almost like a FAQ :)
1. When I do httpclient = new HttpClient, the object is created by default
with the
+1
Oleg
On Mon, 2003-06-02 at 04:29, Michael Becke wrote:
Adrian Sutton has been an active contributor to HttpClient for some
time now. He has been a consistent and reliable contributor, and in
particular his work with NTLM and the developer documentation has been
invaluable.
I would
No objections from me.
Oleg
On Sat, 2003-04-12 at 19:59, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18596.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE
Mike,
In this world people routinely ignore RFCs. I think HttpClient has to
have a high degree of tolerance to those non-compliant date formats.
Besides, since we allow non-compliant variations in cookies, we should
treat other headers consistently.
Oleg
On Sat, 2003-04-12 at 23:28, Michael
Folks
All the outstanding bugs targeted for beta-1 release now have
corresponding patches available for review. As far as I can judge the
review of these patches can be completed by Wednesday/Thursday. It looks
like we are almost done. It appears we can't make HttpClient any better
unless we
Sergio,
This is a very valid point. I believe the entire retry logic should be
carefully revised and improved. Clearly, HttpRecoverableException should
be more informative by having a status flag or sub-classed into several
distinct exception classes.
I just feel that should be done in post 2.0
HttpClient is being used by a few Apache projects that only recently
abandoned 1.1 compatibility (after long and heated debates). I am afraid
if we want to play nicely with those folks, JDK 1.4 is no-go for years
to come.
Oleg
On Thu, 2003-03-27 at 18:15, Sergio Berna wrote:
One more question,
compatibility?
-Mensaje original-
De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Enviado el: jueves, 27 de marzo de 2003 18:32
Para: Commons HttpClient Project
Asunto: Re: NIO
HttpClient is being used by a few Apache projects that only recently
abandoned 1.1 compatibility (after
Busy wait has been fixed after 2.0a3 release. So, a recent nightly build
is needed. Besides, it turned out that Ken was using a rather old JDK
(1.2) which is known to have rather lousy JIT on Solaris platform. I
have already recommended Ken to upgrade both the JDK and the HttpClient
Cheers
Oleg
happening. Is there any
way to store the cookie which I can use for subsequent connections.
thanks a lot
Vijay.
From: Oleg Kalnichevski [EMAIL PROTECTED]
Reply-To: Commons HttpClient Project
[EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED]
Subject: Re: How to use
Sergio
I regret that your message has been left unanswered for so long. The
problem is that out of 4 committers I seem to be the only one currently
monitoring this forum on a regular basis, and I just happened to not be
using connection pooling much. So, I am not the best source to turn to
in
301 - 400 of 474 matches
Mail list logo
