Zulfi,
If you expect us to react on this report, you have to be a little more specific on how
exactly you measured the performance, exactly what kind of HTTP methods your tests
included, exactly what pre-release-candidate you are referring to, and what exactly
you mean by but it is still
;
byte[] tmp = new byte[1024];
while ((l = instream.read(tmp)) = 0) {
outstream.write(tmp, 0, l);
}
}
}
-Original Message-
From: Kalnichevski, Oleg
Sent: Friday, August 20, 2004 9:39 AM
To: Commons HttpClient Project
Subject: RE: HttpClient performance
Karthi
HttpClient what version are you using 2.0.x (stable) or 3.0-alpha1. HttpClient 2.0
throws org.apache.commons.httpclient.HttpConnection.ConnectionTimeoutException to
signal a connect timeout. HttpClient 3.0 does
org.apache.commons.httpclient.ConnectTimeoutException
Oleg
-Original
/site/binindex.cgi. Is this the correct location to download
the jar files.
Thanks,
Karthi
Kalnichevski, Oleg [EMAIL PROTECTED] wrote:
Karthi
HttpClient what version are you using 2.0.x (stable) or 3.0-alpha1. HttpClient 2.0
throws
Query params are part of the request URL and as such can be used with any HTTP method.
A request body on the other hand can be sent by so called entity enclosing methods
only (such as POST and PUT). PostMethod.setRequestBody(NameValuePair[]) method takes a
array of name/value pairs and
(true);
}
result = is;
-Original Message-
From: Kalnichevski, Oleg
Sent: Wednesday, August 18, 2004 12:14 PM
To: Commons HttpClient Project
Subject: RE: Response content length is not known
Otherwise, dynamically generated content
Joseph,
Here's the response sent by the server
HTTP/1.0 200 OK[\r][\n]
Date: Thu, 19 Aug 2004 02:01:34 GMT[\r][\n]
Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE[\r][\n]
Content-Type: text/html[\r][\n]
As you can see the response does not contain a 'content-length' header which is
To: Commons HttpClient Project
Subject: RE: Response content length is not known
Hi Oleg,
Kalnichevski, Oleg [EMAIL PROTECTED] wrote on
18.08.2004 11:26:10:
HTTP/1.0 200 OK[\r][\n]
Date: Thu, 19 Aug 2004 02:01:34 GMT[\r][\n]
Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE[\r][\n]
Content
Subject: RE: Response content length is not known
it does'nt show the html
i just got
INFO:
http://203.215.79.212/reg-dir/submitApplication.do
WARN: Response content length is not known
--- Kalnichevski, Oleg
[EMAIL PROTECTED] wrote:
What does post.getResponseBodyAsString() produce?
Oleg
Mathias
It appears to be a problem with the server side script. Some badly written CGI scripts
generate HTTP status line + response headers in addition to those automatically
generated by the web server. If you produced the wire log of the session that exhibits
the problem, I'd be able to
Setting socket timeout to a positive value will do the trick
HttpClient client = new HttpClient();
client.setTimeout(6); // 60 sec timeout
-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 2:50 PM
To: Commons HttpClient Project
and excuse me for asking such questions.
I was searching with the TimeoutController class, and I've not seen the
obvious answer.
Kalnichevski, Oleg a écrit :
Setting socket timeout to a positive value will do the trick
HttpClient client = new HttpClient();
client.setTimeout(6); // 60 sec
method.getReponseBody can't throw a
SocketTimeoutException but that's this method who is giving me problems
Kalnichevski, Oleg a écrit :
You are more than welcome to ask any kind of HttpClient related questions
Oleg
-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Thursday
Karthi,
HostConfiguration associated with HttpClient instance represents default host
information. These settings are used only when the target host and port are not
explicitly specified on the HttpMethod level.
HttpClient agent = new HttpClient();
that of the server
Thanks,
Karthi
Kalnichevski, Oleg [EMAIL PROTECTED] wrote:
Karthi,
HostConfiguration associated with HttpClient instance represents default host
information. These settings are used only when the target host and port are not
explicitly specified on the HttpMethod level
(method.getHostConfiguration()).close().
Does this close the connection that was used to execute the method.
Thanks,
Karthi
Kalnichevski, Oleg [EMAIL PROTECTED] wrote:
Karthi,
Host configuration specified at the HTTP method level is not supposed to be propagated
back to the HTTP client level.
Try
class.
So using option 1, will close only the exact connection opened by the httpclient in
helper class. i.e the connection that is used to invoke the post method on the
httpclient. It does not close any arbitrary connection. Am I right?
Thanks,
Karthi
Kalnichevski, Oleg [EMAIL PROTECTED
-8);
Mathias
Kalnichevski, Oleg a écrit :
Mathias,
Try using the browser compatibility cookie policy. For details please refer to the
HttpClient cookie guide:
http://jakarta.apache.org/commons/httpclient/cookies.html
Oleg
-Original Message-
From: Mathias Cianci [mailto:[EMAIL
message :
21 juil. 2004 10:26:52 org.apache.commons.httpclient.HttpMethodBase
processResponseHeaders
ATTENTION: Cookie rejected: B=f24p1390fsa6mb=2. Illegal domain
attribute .yahoo.com. Domain of origin: fr.altavista.com
How can I accept this cookie transparently ?
Mathias
Kalnichevski, Oleg a écrit
Folks,
I apologize for 'waking up' so late, after already having cast my vote.
(1) There are two patches that I would like to see committed before the release is cut
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29897
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30175
Both problems
Jennifer,
(1) Are you using SSL?
(2) What's the JRE version you are using?
(3) What web server you are targeting?
(4) Are you going through a proxy?
Oleg
-Original Message-
From: Jennifer Ward [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 1:49
To: Commons HttpClient Project
Andre
This is a very common problem. Please consult 'Customizing SSL' section of the
HttpClient SSL guide for details on how the problem can be resolved
http://jakarta.apache.org/commons/httpclient/sslguide.html
Oleg
-Original Message-
From: Andre-John Mas [mailto:[EMAIL PROTECTED]
---BeginMessage---
Eric
There's a project currently hosted in the commons sandbox aimed at factoring multipart
code out of HttpClient and eventually merging it with commons [codec].
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/codec-multipart/
Feel free to take it as a starting
Hi Pavel
Could you please confirm my understanding that actiWATE is free but not open-source?
We tend to give a little more preferential treatment to open-source projects when it
comes to placement on the HttpClient's application list
Oleg
-Original Message-
From: Pavel Sher
Tim,
* What is the exact JRE version that you are using?
* Are you running HttpClient in a container (servlet container, EJB container)?
* What other libraries do you have on the JRE's classpath?
* Have you tried setting those system properties upon the JRE startup using -D
directive?
Oleg
Tim,
I have had good results with IAIK JCE SSL libraries. They are neither free nor
open-source but seem just fine otherwise
http://jce.iaik.tugraz.at/products/index.php
You'd still need to check with the IAIK's technical folks if their JCE implementation
is capable of handling larger keys
Tim,
You may want to completely override the default server certificate validation logic
and provide your custom implementation.
Feel free to take AuthSSLProtocolSocketFactory.java and AuthSSLX509TrustManager.java
classes below as a starting point
Himanshu,
Try setting socket timeout to a non-zero value. HttpMethod#recycle among many things
calls HttpMethod#releaseConnection which in its turn attempts to reads the remaining
response content to make sure that connection reusable. If the socket timeout is not
set, releaseConnection may
Arturo,
unable to find line starting with 'HTTP' error is reported
(1) when response (status line, to be exact) sent by the server is malformed
(2) if HttpClient fails to correctly parse the status line sent by the server
(3) when the target server accepts connection but then fails to send any
Folks,
I suggest HttpMethod#recycle method be deprecated in 2.0 and 3.0. This has already
been suggested by Eric a while ago. We should have listened
Oleg
***
The information in this email is
the redirect, it never comes...
What server are you running?
-Eric
Kalnichevski, Oleg wrote:
Juan,
Usually HttpClient reports 'unable to find line starting with HTTP' when the
target server drops the connection without returning any response. This can
happen, for instance
Oliver,
Unfortunately there's no (standard and easy) way to interrupt execution of an HTTP
method in HttpClient 2.0. This limitation has been fixed in the unstable branch
(HttpClient 3.0). For the stable branch (HttpClient 2.0) there's no way around forking
the stock version of HttpClient or
Hi Oliver
HttpMethod#abort should be what you want
Cheers,
Oleg
-Original Message-
From: Oliver Koell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 08, 2004 19:07
To: Commons HttpClient Project
Subject: Re: Interruption connections
Hi Oleg,
thanks for your reply, and all the good
Marc,
HttpClient does not directly deal with any aspects of transport security. One is
expected to provide a custom protocol socket factory in order to enforce the desired
transport security.
See HttpClient SSL guide for details
http://jakarta.apache.org/commons/httpclient/sslguide.html
Paulo,
Apparently you were looking at the HttpClient 3.0 code. The problem has indeed been
already fixed in CVS HEAD. Make sure you select HTTPCLIENT_2_0_BRANCH tag when
accessing CVS repository in order to retrieve the latest HttpClient 2.0 compatible code
Dave,
I believe you may be much better off implementing a custom connection manager and
still letting HttpClient take care of HTTP authentication, HTTPS tunneling and other
stuff.
Anyways, the sample below demonstrates how HTTPS tunneling can be implemented using
just plain HttpConnection
Juan,
Usually HttpClient reports 'unable to find line starting with HTTP' when the target
server drops the connection without returning any response. This can happen, for
instance, if the server is being under heavy load.
(1) If you have access to the target server, examine the server logs to
Paul,
The problem is obviously caused by the server's dropping connection right after
HttpClient is done sending the request. If you have access to the target server, check
the server logs to find out what prompted the server to do so.
I can think of two possibilities:
(1) The server did not
Nicholas,
HttpClient 2.0 relies on a fairly ugly trick to be able to simulate connect timeout on
older JDKs (1.2.x, 1.3.x). HttpClient simply spawns a dedicated thread that attempts
to instantiate a socket. If the process of socket instantiation takes longer than the
specified limit,
Hi Mark,
It's been a conscious design decision on our part to keep HttpClient content agnostic.
HttpClient makes no attempt to encode/decode (let alone guess) the request/response
content encoding. This logic can be (and usually is) highly application specific that
should be implemented on top
Chris,
In the 'strict' mode HttpClient 2.0 will send all cookies as one request header. I
believe that should take care of the problem. Some older HTTP servers appear to have
issues with multiple Netscape-style (version 0) 'cookie' request headers.
HttpClient 3.0 provides a granular option to
Brian,
This feature is available in HttpClient 3.0 only:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794
Please note, though, that HttpClient 3.0 is still in an early alpha state
Oleg
-Original Message-
From: Russell, Brian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 18,
Lee Francis,
Now it hit me.
When credentials are explicitly set to be used with a given host and/or realm only,
there'll never be used for preemptive authentication for security reasons. The
credentials will be used to respond to a direct authorization challenge originating
from the
Mike,
I feel we need a little stronger and more focused sales pitch. This is going to be a
very important release for all of us and our message must be loud and clear with
regards to what this release is intended to be and what its intended target is. If we
fail to generate enough interest in
---
-Original Message-
From: Kalnichevski, Oleg
Sent: Monday, May 17, 2004 13:47
To: Commons HttpClient Project
Subject: RE: 3.0 alpha1 build [PATCH] status news
Mike,
I feel we need a little stronger and more focused sales pitch
Almost forgot. Javadocs need fixing. I'll take care of the problem tonight unless
someone beats me to it
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Monday, May 17, 2004 6:11
To: Commons HttpClient Project
Subject: 3.0 alpha1 build
I've uploaded the
To: Commons HttpClient Project
Subject: Re: 3.0 alpha1 build
What in the Javadocs needs fixing?
Mike
On May 17, 2004, at 7:58 AM, Kalnichevski, Oleg wrote:
Almost forgot. Javadocs need fixing. I'll take care of the problem
tonight unless someone beats me to it
Oleg
-Original Message
The problem is that your server reports an incorrect Content-Length on
the 401 Response body.
Count yourself: It sais 282 bytes. But the response is 283 bytes. (the
two [0xfffd] sequences are one byte each). Nothing we can do here I fear.
Lee Francis,
I agree with Odi that incorrect
Sofya,
It does sound dubious. There's no way a new instance of SimpleHttpConnectionManager
can obtain an existing instance of HttpConnection. SimpleHttpConnectionManager
*always* creates a new instance of HttpConnection. It is perfectly possible, though,
that an open connection lingers in
John,
Please correct me if I am wrong (which may well be the case) SO_TIMEOUT only affects
socket read operations. I thought it had nothing to do with SSL inactivity timeout.
But it looks like it might.
There's another way to deal with recoverable exceptions. You can provide a custom
Himanshu,
HttpClient 2.0, unfortunately, cannot automatically handle cross-host redirects. But
this limitation is not difficult to work around. See the document below
http://jakarta.apache.org/commons/httpclient/redirects.html
HttpClient 3.0 will address this limitation
Oleg
-Original
Duzayak (I hope I got your name right),
You can create an instance of the HttpState class per thread and pass the respective
HttpState object along with the HTTP method to be executed:
// shared by all the worker threads
HttpConnectionManager connman = new MultiThreadedHttpConnectionManager();
Duzayak,
'Set-Cookie' (request) header is not the same thing as the 'Cookie' (response) header.
CookieSpec#formatCookieHeader() method produces a 'Set-Cookie' (request) header,
whereas CookieSpec#parse() method is intended to parse 'Cookie' (response) headers
I hope this clarifies things a
HttpClient project voted in favour of migration from Bugzilla to Jira
+1 votes -
Jeff Dever jsdever -at- apache.org
Ortwin Glück oglueck -at -apache.org
Adrian Sutton adrian -at- apache.org
Oleg Kalnichevski olegk -at- apache.org
Michael Becke mbecke -at- apache.org
Folks
I have filed a request with the infrastructure to migrate HttpClient issue tracking
from Bugzilla to Jira
http://nagoya.apache.org/jira/browse/INFRA-74
I hope we'll get luckier this time around
Oleg
As you know, I have a very relaxed oppinion of breaking API
compatibility. I am in favour of this change.
Same here. But I have to admit we might be a minority on this issue
Anything I can help here?
Only to help me drown my frustration in a few beers ;-) On a more serious note, I do
not
Please vote as follows:
-
Vote: Migrate HttpClient issue tracking from Bugzilla to Jira
[ ] +1 I am in favor of the proposal, and will help support it.
[ ] +0 I am in favor of the proposal, but am unable to help support it.
+1
-Original Message-
From: Kalnichevski, Oleg
Sent: Monday, May 10, 2004 11:03
To: Commons HttpClient Project
Subject: [VOTE] Migrate HttpClient issue tracking from Bugzilla to Jira
Please vote as follows:
-
Vote
Hi John,
The problem is caused by a bug in older Sun's JSSE implementations. Indeed, it has
nothing to do with HttpURLConnection.
The problem is actually an interplay of several factors
(1) Persistent connections.
HttpClient attempts to reuse HTTP connections whenever possible.
(2) 'Stale'
Andrea,
New HttpClient 3.0 API has not been properly documented yet (documentation and test
case coverage will become a top priority right after the 3.0-alpha1 release). The idle
connection management with the multi-threaded connection manager does take a little
bit of explaining. Per default
org.apache.commons.httpclient.HttpClientError;
import org.apache.commons.httpclient.params.HttpConnectionParams;
import org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory;
import org.apache.commons.httpclient.protocol.ReflectionSocketFactory;
Thanks again!
King regards
Thorsten
Kalnichevski, Oleg wrote
on commons pool
On 07/05/2004 10.38, Kalnichevski, Oleg wrote:
Andrea,
New HttpClient 3.0 API has not been properly documented yet (documentation and test
case coverage will become a top priority right after the 3.0-alpha1 release). The
idle connection management with the multi-threaded
(www.whatever.com, 443, myhttps);
is raising the Error: method getHostConfiguration() is undefined for the typ
httpclient.
Thank you very much (again) Oleg! You are always a great help!
Cheers!
King regards
Thorsten
Kalnichevski, Oleg wrote:
Thorsten,
There are currently two branches of HttpClient
httpclient has to be rewritten to be
compatible with EJB spec?
Regards
Andrea
On 07/05/2004 12.53, Kalnichevski, Oleg wrote:
Andrea,
Both 2.0 CVS HEAD nightlies are available
http://jakarta.apache.org/commons/httpclient/downloads.html.
This may sound a bit harsh, but I _personally_ do
Hi Andrea
I (all of us, I suppose) are very glad that you find HttpClient useful.
The commons-pool is a great and well tested library by itself. No discussion about
that. However, we should be very selective about external dependencies. This issue
would not be taken lightly. There are enough
know the results
Oleg
-Original Message-
From: Lili Liu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 20:26
To: Kalnichevski, Oleg
Subject: RE: IIS (NTLM) + proxy server (NTLM or basic) problem
Hi, Oleg:
I am focusing to get basic proxy + NTLM host work.
I downloaded
Frank,
You can start off by taking a look at the HttpClient cookie guide and redirect guide
http://jakarta.apache.org/commons/httpclient/cookies.html
http://jakarta.apache.org/commons/httpclient/redirects.html
If you happen to have any specific questions regarding HTTP cookies or redirect
Lili,
Truth to be told, NTLM proxy + NTLM host authentication has never been properly
tested, because none of us (HttpClient developers) has got access to a Microsoft Proxy
installation. I would not be surprised if it did not work at all with HttpClient 2.0.
I know for a fact that BASIC proxy
Hauke,
NTLM problems are notoriously difficult to troubleshoot. Usually it all boils down to
extensive guesswork.
(1) is user name in the fully-qualified format: domain/account? If yes, use the
account name only
(2) do you have any 'funny' characters in the password (like German umlauts, for
On a related note, Oleg, are you also working on updating the list of
contributors? If not, I will take a look at it.
Mike,
I found this to be quite a touchy issue. I have been thinking whether there's an
acceptable way to inject a little more structure into the standard Maven generated
Frank,
I just what to add one thing to what Roland has said: basically the authentication
with the developer.java.sun.com succeeded. You got the session cookie back. HttpClient
was simply unable to process the post-logon redirect, but this limitation is not
difficult to work around (see the
Chris,
We already have a bug report pending for this:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27026
My (unofficial) plan was to take care of it for the next releases: 3.0-alpha1
(expected within a month) and 2.0.1 (has not been discussed yet, but certainly
imminent). If it is
Fredrik,
This problem is clearly not HttpClient related, hence you have not been getting a lot
of responses. HttpClient simply expects JSSE to be there and be properly configured in
order for the HTTPS support to be functional. Please take a look at the HttpClient SSL
guide paying special
Jorrit,
HttpClient relies on commons-logging toolkit to do all its logging. The
commons-logging itself is merely an abstraction layer intended to provide a uniform
interface to different logging toolkits. If there is a toolkit capable of assigning
different appenders on per thread basis, then
Brit,
There are currently two HttpClient branches: CVS HEAD (development, no longer
compatible with the 2.0 API) and the 2.0 compatible branch (stable). I suspect you
have gotten the PostXML code off CVS HEAD, which does not compile against 2.0 final.
Please try examples shipped with
the online tutorial and examples to work you have to use the 2.0 Release
Source Build because the 2.0 Release Binary Build is missing methods.
If I am missing something here I apologize.
Brit
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Monday, April 26, 2004
to the HttpClient logo so that it's visible, but I assume we
may want to do something more permanent.
Mike
On Apr 20, 2004, at 8:22 AM, Kalnichevski, Oleg wrote:
Mark,
There is a few little problems generating HttpClient 2.0 site using
maven rc2:
(1) Currently we generate HttpClient site off the 2.0
Mark,
There is a few little problems generating HttpClient 2.0 site using maven rc2:
(1) Currently we generate HttpClient site off the 2.0 branch rather CVS HEAD. The same
changes made to the project.xml in CVS HEAD need to be made in the 2.0 branch. I'll
take care of that unless someone beats
how to make Maven
execute an Ant target as a part of release process. This is where I'd greatly
appreciate a bit of help
Oleg
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 16:53
To: Kalnichevski, Oleg
Cc: Commons HttpClient Project
Thanks, Mark. You rock
Oleg
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 18:22
To: Kalnichevski, Oleg
Cc: Apache Commons HttpClient (E-mail)
Subject: Re: Broken link on website
Ant can be executed within Maven failry easily. If you
Thorsten,
2004.04.20 18:30:54,378 [http8090-Processor4] WARN
org.apache.commons.httpclient.HttpConnection -
The host www.andaluciajunta.es:80 (or proxy null:-1) did not accept the connection
within timeout
of 15000 milliseconds
Something tells me that this looks suspiciously like a
Christian,
My apologies for having forgotten about you. Your SimpleHttpServer framework is the
coolest contribution of late, IMHO. My intention to eventually phase out all test
cases reliant on 'Webapp' and 'SimpleHttpConnection' stuff and have them replaced with
the test cases based on
Raj,
Please note that HttpClient simply makes use of JSSE and does not attempt to provide
any sort of transport security by itself. As far as HttpClient is concerned SSL is
just a transport layer which is supposed to be completely transparent to HttpClient.
I'll do my best to help you out,
Protocol(https, new
EasySSLProtocolSocketFactory(), 443));
Thanks
Raj
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 8:21 PM
To: Commons HttpClient Project
Subject: RE: HttpClient for Https gives Unrecognized SSL message..
Raj,
Please note
Steve,
We already have a feature request to implement instrumentation for timings
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10815
Currently it is not very high on our list of priorities and is targeted for the
release after the next one, which may take months or most likely years. I am
Hi Eric
Many thanks for taking time to correct my writing. All corrections make sense to me.
(BTW, no need to be over-diplomatic. I am perfectly aware that my English has its
limits, especially if I just type away. Just correct it. There'll be no questions
asked).
Do you still have the
Henri,
Jakarta commons did vote on this issue, though somewhat informally
http://marc.theaimsgroup.com/?t=10773881871r=1w=2
Oleg
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 13:52
To: Jakarta Project Management Committee List
Cc:
No worries, Odi
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 16:18
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 24869] - DigestScheme.authenticate returns
invalid authorization string when algorithm is null
DO NOT REPLY TO THIS
***
The information in this email is confidential and may be legally privileged. Access
to this email by anyone other than the intended addressee is unauthorized. If you are
not the intended
The message attached below was sent to general at jakarta.apache.org. Apparently
there's something brewing. You may know our fate soon.
Oleg
-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 18:29
To: Jakarta General List
Subject:
Gregory,
Does the site in question require authentication? If yes, it is quite likely you have
hit one of the known limitations of the HttpClient 2.0 branch. See HttpClient SSL
guide for details http://jakarta.apache.org/commons/httpclient/sslguide.html. This
problem has already been fixed in
Hi Vim
Are you absolutely sure you need all 100,000 threads running simultaneously? Probably
you should approach the problem from a different angle and try to pool the worker
threads rather than pooling HTTP connections?
Oleg
-Original Message-
From: Vimarsh Vasavada [mailto:[EMAIL
SQL Server 2000
O/S Windows 2000 Server with SP3
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 1:44 PM
To: Commons HttpClient Project
Subject: RE: Connection Pooling/Piplining
Hi Vim
Are you absolutely sure you need all
an encoded reader since that will
convert all bytes not used by the encoding to question marks. His patch
fixes the problem. My idea was just to provide sort of nicer output.
Odi
Kalnichevski, Oleg wrote:
Geir,
The wirelog displays (is intedned to display) what gets physically transmitted
All Mikes, Roland, and all
I believe it _might_ be possible to implement a generic SSL tunnelling mechanism using
stock version of HttpClient. The only API change it may requite is adding protected
HttpConnection#getSocket method. I may try to hack something up this weekend.
Oleg
Oleg,
I guess it's just a typo, but to be sure:
The CONNECT method is for establishing a
generic tunnel through an HTTP proxy.
SSL tunneling is just one application of that.
cheers,
Roland
Kalnichevski, Oleg [EMAIL PROTECTED]
26.03.2004 14:49
Please respond to Commons HttpClient Project
Gil, Roland
Pluggable cookie policies as well as ability to manually set cookie headers are
supported in the development branch only. For 2.0 there is no way around forking
HttpClient
Oleg
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004
unsecured.
thanks for your help,
John
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: 24 March 2004 13:26
To: Commons HttpClient Project
Subject: RE: Httpclient + HTTPS + Proxy + BASIC Authentication
John,
The connection between the client (the agent
---BeginMessage---
Folks,
I really think Java 1.3 does not bring anything to the table as far as HTTP
communication is concerned. I am not even sure you we need Socket#shutdownOutput() at
all. Currently HttpConnection#shutdownOutput is not used anywhere in HttpClient.
Java 1.4 is a totally
---BeginMessage---
(Some went badly wrong with my previous message. Damn Outlook. Retrying)
Folks,
I really think Java 1.3 does not bring anything to the table as far as HTTP
communication is concerned. I am not even sure you we need Socket#shutdownOutput() at
all. Currently
1 - 100 of 377 matches
Mail list logo
