Am I mistaken, or have the recent issues been dealt with?
-Eric.
Michael Becke wrote:
Looks like 2.0.2 has been cancelled for the moment. I'll call for a
vote again after we fix the recently discovered issues.
Mike
On Sep 29, 2004, at 11:05 AM, Michael Becke wrote:
release
Oleg
On Fri, 2004-09-03 at 00:00, Eric Johnson wrote:
My read on Odi's statistics is that the patch has a pretty consistent
1ms impact on every request. This corresponds pretty well with my
understanding of the theoretical improvements behind the patch. To the
effect that HttpClient's
Juan,
The one technique that I'm aware of for guaranteeing that the server
only processes the request once is to put in some sort of transaction ID
into the request, and the server will reject duplicate requests
(hopefully with an appropriate error message).
In short, it is an application
I don't know whether this would be a premature time to call for a new
release, but the prospect of significantly better performance out of
HttpClient has some people in my company very interested.
What are the chances of a 2.0.2 release with this fix in it? (I'm
willing to build from the
I thought about this as well this morning, and couldn't figure out any
flaws with the patch.
-Eric.
Oleg Kalnichevski wrote:
Mike,
I have been also thinking about repercussions on the reliability of the
stale connection check. I tend to conclude that with the existing
architecture (no HTTP
anything else.
Yet, it see no problem with another point release
Oleg
On Thu, 2004-09-02 at 19:06, Eric Johnson wrote:
I don't know whether this would be a premature time to call for a new
release, but the prospect of significantly better performance out of
HttpClient has some people in my company
[EMAIL PROTECTED] wrote:
[snip]
/**
* Keep hitting a URL, with no sleep time.
*/
class ClientThread implements Runnable
{
protected Thread m_thread;
protected boolean m_running = true;
public ClientThread( )
{
}
public
Jennifer Ward wrote:
On Jul 15, 2004, at 1:09 AM, Kalnichevski, Oleg wrote:
(3) What web server you are targeting?
We are using Apache Tomcat with Slide for WebDAV support.
Aha.
At least in Tomcat 4.0, it silently processes the Expect 100 Continue
so that the web-application never sees that part
Make sure you are using the MultiThreadedConnectionManager, and that you
call releaseConnection after each request. It strikes me that you could
be getting into a situation where the server thinks it is doing HTTP
pipelining, which HttpClient doesn't actually support, particularly if
you are
Andre,
At a quick glance, it appears that there is one problem that I've
experienced that the SSL guide doesn't seem to cover. Presumably, once
you've created your self-certified certificate, you added it to your
JVM's cacerts file using the keytool? I've found that a self-signed
certificate
Tim,
Make sure you imported the CA certificate with the -trustcacerts option.
If you do everything else correctly, and leave out this step, you'll see
the problem you reported. I've tripped over that mistake once or twice.
That's just a shot-in-the-dark as to what might be your problem, though.
Lukas,
I certainly cannot spend the time to help you, beyond this email, but
for the sake of correct knowledge in the HttpClient mail logs
Lukas Bradley wrote:
The response we have received from their technician is as follows:
Okay, this is making some sense now. We are not logging your
Oleg,
Or how about simply listing years in which contributors actually
contributed patches? And if you wanted to be more specific, you could
put a count for each year. Of course, I'm not much of a contributor
these days, except to come up with zany ideas on the mailing list..., so
treat the
-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 15:18
To: Commons HttpClient Project
Cc: Daniel C. Amadei
Subject: Re: [PATCH] SSL guide amendments (patch against 2.0 branch)
Oleg,
A few suggested edits I'm not a great editor myself (I frequently
miss bevies
The initial connection to the proxy server is actually done over an
unencrypted channel.
Subsequent communications are encrypted only after the connection to the
proxy has been established.
This isn't a restriction, rather I believe it follows the proxy
specification.
-Eric.
John Melody
Well, hmmm - I'm perfectly happy to have my name removed, or sign a CLA.
My quick scan of the files revealed what I suspect is a much longer list
of authors that probably haven't signed a CLA than just those two that
you indicate.
Rewriting the code is a drastic and expensive solution! I
Roland Weber wrote:
Hello Eric,
I was thinking about some kind of metrics, too.
Not as advanced as yours, of course :-) But then
I felt that a ranking is not the best approach. It
may lure people to use tricks just to improve
their ranking.
Too true. My perspective on this matter is colored by
At the risk of adding fuel to an unproductive discussion, I thought I'd
throw in my comments:
Legal:
* IANAL, however, it strikes me that there is at least some small
legal exposure in the @author tags. As a contributor of sorts,
but not an official committer, there are certain
John Keyes wrote:
For (a), Oleg's response is correct. You might easily be confused, in
the sense that HttpClient's API inverts the control. It is not that
you write to an OutputStream to send your data, it is that you
provide HttpClient with an InputStream, and it reads that stream
and sends
John,
Two separate questions:
a) sending a large post/put request, without buffering it in memory.
b) reading a large response to a request.
For (a), Oleg's response is correct. You might easily be confused, in
the sense that HttpClient's API inverts the control. It is not that you
write to an
The time seems right. I see no reason to wait!
-Eric.
Kalnichevski, Oleg wrote:
Folks,
I feel it is time we cut the final release. I am convinced we should get the long
overdue HttpClient 2.0 release out and fully concentrate on getting HttpClient 3.0
ready for the first alpha release.
Knowing the speed with which corporate legal departments can move, I
would hope for keeping the old license for the 2.0 release.
I think it would be unfair/surprising for clients to discover that they
would have to do a legal an unexpected legal review just for the sake of
eliminating a few
Dave,
*You* have to generate the wire log.
See this link http://jakarta.apache.org/commons/httpclient/logging.html
that Oleg pointed you to.
-Eric.
D Alvarado wrote:
Again, here is my noviceness coming out, but
where would I find this wirelog of the HTTP
session? I am running Apache Web
and reliably through proxy servers and routers
that might otherwise drop an idle connection.
-Eric Johnson.
David Webb wrote:
I have written a program that uses HttpClient to call servlets that do batch
jobs and wait for their return...usually no more that 15 minutes. I have the
Server timeout
Oleg Kalnichevski wrote:
Hi Tim,
See my comments in-line below
[snip]
My challenge is that the bank processes each GET request, even if it has
the same parameters as a previous request (yes, I know that GETs should
be idempotent but I don't have a choice). I can't charge people twice.
I
Well, I'm not sure how I would recommend going on this decision. So
here is my attempt at providing a slightly biased (in favor of Bugzilla)
view of the facts.
I looked at nagoya.apache.org, and checked out both the Scarab and Jelly
installations running there.
Random observations:
*
Jean-Remi,
You should re-read Oleg's previous response. Redirect on a POST request
is *not supported*, no matter how many times you set the flag.
You will have to follow the redirect yourself, as Oleg suggests
(http://jakarta.apache.org/commons/httpclient/redirects.html).
This stems from
This problem seems like it is the perfect candidate for the
ExpectContinueMethod.setUseExpectHeader() function. Isn't this exactly
the scenario for which this header was intended?
-Eric
Oleg Kalnichevski wrote:
Siddhartha,
I believe the solution to this problem is trivial. All it takes is
/logging.html, although if
you're using Log4J, you'll have to adopt the instructions as
appropriate. I suggest searching the HttpClient email archives
(http://nagoya.apache.org/eyebrowse/SummarizeList?listId=128) for Log4J
to see how other people have solved this.
-Eric Johnson
Lomvardias
Ugh - cross-posting. Seems like this question was meant for
httpclient-dev, so I've included that
I think the answer will come back from the regulars on the httpclient
dev list that the long term intent is to split the request, and
response parts of the HttpMethod interface into distinct
in that library.
-Eric Johnson.
J H wrote:
Hi. I found the HTTP-commons library and I was absolutely ecstatic!
I would appreciate some help though...I'm not sure how to coax it to
send data other than html...I've tried to set the request header to
method.setRequestHeader(Content-Type,content
I'm not sure that HttpClient should do anything different.
According to section 4.6 of RFC 2617, A user agent MUST choose to use
the strongest auth- scheme it understands and request credentials from
the user based upon that challenge.
Since Basic is pretty darn weak, I'd say NTLM wins out
Oleg,
You're discarding the possibility that HttpClient is approaching
perfection, and doesn't need much in the way of email commentary,
because it works so well.
Ah, er, sorry, I just had to day-dream for a moment there.
-Eric.
Oleg Kalnichevski wrote:
What's up, folks? I have never seen
My take is slightly different (and I wish I had time to implement it)
Start by virtualizing the access to the connection, and then, rather
than having multiple servers, just have different implementations of a
virtualized socket interface, for example. Then see to writing test
cases that
Sven,
I've not tried this, but if you send a Connection: close header on the
request, the server should echo that on the response. If that header is
on the response from the server, the the releaseConnection() function
will (or at least it should) immediately close the connection, rather
than
Odi,
This is a curiosity, I agree.
I take this documentation from System.gc() at face value:
When control returns from the method call, the Java Virtual Machine
*has* made a best effort to reclaim space from all discarded objects.
(emphasis added) - In other words, it is blocking, although
This would appear to be a character encoding issue.
In BasicScheme.authenticate, it currently does this:
return Basic + HttpConstants.getAsciiString(
Base64.encode(HttpConstants.getBytes(buffer.toString(;
I suspect it should be doing something like this:
return Basic +
that addresses your concerns somewhat.
Oleg
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 15:35
To: Commons HttpClient Project
Subject: Re: DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while
trying to retrieve status line
Christian
Brad,
No worries about which list you subscribe to. Many on this list are
happy to answer questions such as yours.
HttpClient uses commons-logging for its configuration. If you've
configued commons-logging properly, the message can be made to go away
as you indicated. Since you already
Oleg,
Dang, you're good! You complete fixes before others can even guess at them!
-Eric.
Oleg Kalnichevski wrote:
It strikes me personally that the warning in this particular context
is probably excessive, and it should be logged as a info or debug
message instead, but only in this
branch against Tomcat 4.1.29 after having read your message. Again, no failing test cases.
Did you keep your old server.xml file?
Oleg
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 17:11
To: HttpClient
Subject: Cookie test case failures
(attached below) to
disable stuff that I do not need. I's unlikely that it should have any
bearing on the problem, but who knows.
Oleg
On Tue, 2003-11-04 at 20:53, Eric Johnson wrote:
Oleg,
I hate bugs like this! I suppose if it is working for you, there's hope
it can work for me.
I'm working
Konstantin,
Konstantin Priblouda wrote:
--- Alexander Hvostov [EMAIL PROTECTED] wrote:
A little while ago, I wrote a base64 {en,de}coder in
Java. Huzzah. Since I've
found out that you guys wrote one too, I thought I
should submit mine. It's
implemented as an OutputStream and InputStream
for troubleshooting on the web site, and let us know.
-Eric Johnson
Karr, David wrote:
I'm apparently using version 2.0-alpha3-dev of HTTPClient.
I doubt this is a problem with HTTPClient, but I'm just trying to
understand my issue a little better.
I have a servlet running in WebLogic on my desktop
Jandalf,
I guess fighting the Balrog aged you a bit?
Given the collection of dedicated committers, I would hate for a non
binding +1 to be taken as a slight against anyone else, for it most
surely is not! Caveats aside, Michael seems like an excellent choice
from where I sit (+1).
-Eric.
, and Object. If you
really argue the point, you might further boil this down to just long
and double, but that really could consume lots more memory, at least
where short keys are concerned.
All of which might argue for defering the creation of these map classes
until needed.
-Eric Johnson
I would think that if your application has any reason to believe that
the response will be unbounded, then you should use getResponseBodyAsStream.
I suppose would could add functions that took a limit parameter for the
functions getResponseBody() and getResponseBodyAsString(). Something like:
At a lower level, the potential failure points are undoubtedly there.
Unless you could point to a real-world server that causes them, or a
security bug that stems from them, any such fixes would be academic in
nature.
Can you cause an out of memory failure while using
Christian,
I would add to my previous two suggestions about using HTTP 1.0 level
support and the Connection:close header, an additional suggestion.
Provide your own connection manager that does not attempt to re-use
connections in a persistent manner, or at least, lets you control
whether to
Ernst,
You might check out the troubleshooting guide. See about turning on
wire logging, for example. Then let us know what you find in the log.
The server can, of course, decide that it wants to expire your
cookies. The server doesn't need to return them with each response.
Cookies can
David,
You might try setting the logging level for the Logger called
httpclient.wire.
In other words, add this:
log4j.category.httpclient.wire=
with the debug level of your choice. If you look carefully at the
logging.html page, you can dig this tidbit out from this line:
Danch,
Note the bugs:
http://issues.apache.org/bugzilla/show_bug.cgi?id=23137
http://issues.apache.org/bugzilla/show_bug.cgi?id=22841
If you can, pull the latest code from CVS, or grab a nightly build, and
try it again, as the bug may very well be fixed already.
Let us know how it goes.
- Eric
Oleg,
Thanks for doing the research!
If my math is correct, this means:
2.0b2 - average of 10.23ms per request
2.0rc1 without isStale - average of 8.16ms per request
This would seem to correlate exactly with the code - we know that the
penalty of calling isStale() should be approximately one
Quent,
You might also read Bruce Schneier's book called Applied Cryptography,
(and his other books, too). Every security system has its inescapable
flaws. HTTPS/SSL/TLS, for example, depends on the certificates not
being compromised while they're still valid, and on the computational
Oleg,
It doesn't matter too much to me either way. I've sent an email to the
slide-dev group suggesting that they switch to the 2.0 branch, but no
action has been taken yet.
Slide is an interesting test case, if only because it is representative
of how other clients are using HttpClient, at
Kalnichevski, Oleg wrote:
I would just make 'stale' connection check optional and off per default. Making the check pluggable would require too much of a change for what is essentially a release candidate. That should be better done as a part of 3.0 redesign IMO.
As I recall, the isStale
Daniel,
Sorry I didn't respond sooner, but I was on vacation. I'm hoping you've
gotten an answer on the Slide mailing list, but I've not had a chance to
check.
I've been doing some work to keep the latest code in Slide up-to-date
with the latest of HttpClient 2.0.
You should have success
Kalnichevski, Oleg wrote:
Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now.
Of course, I can put up the
on but can't get it to work. I pasted
the code to set the system properties but that doesn't work. Is it possible
to use the wire log with Log4J?
Thanks
Michael
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 3:23 PM
To: Commons HttpClient Project
Michael,
You might try turning on the wire and/or trace logging (which sounds
like it might generate a lot of data), but it would also tell you
exactly where the delay occurs.
Knowing where the culprit occurs would provide additional detail that
might clearly identify whether the problem lies
Oleg,
Thanks for digging into this.
Oleg Kalnichevski wrote:
One of the major shortcomings of the existing architecture is unclear
and convoluted exception handling framework.
Here's the list of my personal gripes with it
- there is no clear-cut distinction between protocol exceptions (that
Adrian,
+1
OK, my vote is non-binding, but with no test cases, and no code in
HttpClient that uses the functions, we SHOULD deprecate them.
Even if we decide later, as Sung-Gu suggested, that we might need to
ressurrect them, we should still deprecate them! Deprecating them is a
flag for
Mike,
Thanks for starting this discussion. I've been contemplating this one
for a while.
My development approach follows along the lines of revolution through
evolution. Which means, with respect to HttpClient, that on the one
hand I don't want to encourage too many fundamental changes for
had a model such as the above, where most people used the one giant
JAR instead of the individual ones, the creation of a separate commons
URI project would be largely one of focus and interest, rather than an
additional dependency quagmire.
-Eric Johnson
Sung-Gu wrote:
Hi all,
I suggest
Adrian,
Good of you to bring up the topic...
Adrian Sutton wrote:
Howdy all,
We now have a license for clover to analyze our test cases and am now
just starting to work through adding test cases to improve our code
coverage. I've very quickly come to the realization that 100% code
coverage
be a dead lock.
Eric Johnson wrote:
MultiThreadedHttpConnectionManager.doGetConnection() - line 302,
which reads connectionPool.wait(timeToWait),
This is a limited wait. Not infinite. Oleg, do we ensure that
timeToWait0 somehow?
You seem to be echoing one of my recommendations - the code should
Mike,
I think you're roughly agreeing with what I would conclude, but I wasn't
sure and I wanted to get other's feedback.
Michael Becke wrote:
Doing something time-consuming from the event thread is a little
questionable I think. It's an easy way to keep a user from using the
UI but it
to implement my
own pooling?
It should be sufficient to use the MultiThreadedHttpConnectionManager,
which actually serves multiple tasks, one of them being pooling.
I am sure I have other questions, but this will do for now. :)
Thanks.
Om.
Good luck.
-Eric Johnson
as
host
// entries too. -- Eric Johnson 12/13/2002
if (LOG.isDebugEnabled()) {
LOG.debug(Adding Host request header);
}
//appends the port only if not using the default port for the
protocol
if (conn.getProtocol().getDefaultPort() != port
Sergio,
As best I can tell, your stated requirement is one that needs to be
handled at the server. Consider:
Your client application -- HttpClient -- JRE -- Client OS -- HTTP
-- Server OS -- HttpServer -- Server application.
and then:
Your client application -- HttpClient -- JRE -- Client OS
Mike,
I like the idea of a cap on the total number of connections as a
configurable default.
Perhaps HttpClient doesn't need to implicitly perform connection
recycling on idle connections, but how about adding an explicit method
on MultiThreadedConnectionManager that clients can call -
Oleg,
It looks like a fine submission to me. I think your package name
suggestion is a good one. Perhaps a different class name, though. I'm
thinking HttpMethodCloner.
-Elric.
Oleg Kalnichevski wrote:
Folks
How about making this utility class the first contribution to our yet
non-existent
James,
The way I built my mental model, a multipart/form-data post consists
of two distinct kinds of parts, file parts, and string parts. The
fundamental distinction is one of binary versus text data, although
the distinction is, as always, somewhat arbitrary. I think the
nomenclature comes
the socket factory instead of the calls
to SSLSocketFactory.getDefault() used in
SSLProtocolSocketFactory.
I think this idea ought to replace
SSLProtocolSocketFactory FWIW. I just hadn't had time
to send it in or type up the code for it yet.
Eric Johnson (not the one that regularly contributes,
but one
Great!
I also noticed that Sun's HttpsURLConnection class
allows you to specify a HostNameVerifier. I'm not
really sure how this works but it might be worth
thinking about including in httpclient.
Eric
--- Michael Becke [EMAIL PROTECTED] wrote:
Attached is a patch that adds an
pointers,
Aurelien
-Eric Johnson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hello,
I was looking into using the httpclient in an
application that requires client certificate
authentication. According to the JSSE documentation,
the mechanism for doing this is to get your
SSLSocketFactory from an SSLContext, which allows you
to specify the KeyManager and TrustManager. I
on
the server, in any case. An InputStream is a one-shot thing. You get
to read it once. Your second attempt to read above
(in.read(reqContent); )will not actually read anything.
-Eric Johnson
-
To unsubscribe, e-mail: [EMAIL
() - a convenience wrapper around
getResponseBody().
* releaseConnection() - just calls close directly on the equivalent
of the result from getResponseBodyAsStream().
Hopefully this clarifies, rather than confuses!
-Eric Johnson
There is one further alternative to Jeffrey's suggestion. You can call
executeMethod, then get the response stream, then call close() on
that. The close on the response stream will trigger the right
sequence of events.
-Eric.
Simon Roberts wrote:
I guess the problem is really mine. I was
Michael Becke wrote:
[snip]
I've been looking into this a little more and I'm actually not sure if
AutoCloseInputStream should close the stream or not. I vaguely
remember when this was first written and the various interactions are
quite complex. In most cases the AutoCloseInputStream is
Jandalf,
In contemplating your post, I had several thoughts:
* We should not remove functions from the APIs unless they are
already deprecated. To do otherwise will cause people to abandon
HttpClient (again!) as unstable. Rather, we should maintaining
deprecated
Based on the recent URI discussion, and some other points, it strikes me
that we could take a little more credit for the work that has gone into
HttpClient.
On the HttpClient home page
(http://jakarta.apache.org/commons/httpclient/index.html) four RFCs are
listed.
Given all the discussion
83 matches
Mail list logo
