hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19286] - httpClient incorrectly closing tunnelled connection right after tunnell established
Date Tue, 29 Apr 2003 16:30:09 GMT
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=19286>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19286

httpClient incorrectly closing tunnelled connection right after tunnell established





------- Additional Comments From olegk@apache.org  2003-04-29 16:30 -------
Bin,
I guess you are not subscribed to the HttpClient  mailing list. Usually, it is 
there important issues get settled there and important decisions are 
collectively made. 

Here’s the discussion thread you may want to visit in order to catch up with 
the things regarding SSL connection persistence with older JDKs

http://marc.theaimsgroup.com/?l=httpclient-commons-dev&m=105121551117984&w=2

The ultimate authority on this issue is Mike Becke. May he correct me if I err, 
but here’s my way of seeing things:

The problem, the side effects you are dealing with, has been a major headache 
for quite a while. It all boils down to a very unfortunate fact there’s no (we 
do not know of a) reliable way of telling in Java if a connection is stale. The 
only way to be sure if a connection is still good is actually to read on it. 
This is here that things get screwy for you. Recently introduced 
HttpConnection#isState() method attempts to read a single byte from the socket, 
and, if an exception is thrown or –1 is returned, declares it stale. As it 
later turned out that in older JDKs SSL socket returns –1 if not data is 
available instead of timing out as expected, even though the connection may 
still be perfectly ok. We consider it to be a bug in Java since this problem 
does not occur with JDK 1.4 or above. 

The decision was made to not provide a work-around, which would not work 100% 
anyway, but rather recommend the users to upgrade to JDK 1.4, should they want 
to use SSL, which is (at least in my humble opinion) a prudent thing to do 
anyway.

What I can recommend is to carefully revise HttpConnection#isState() method and 
introduce your own connection checks which may be Java version specific. In the 
worst case you may want to always return false when running on an older JDK 
over a secure connection. 

This is unfortunate but that's the way things are. I personally have to 
maintain my own fork of HttpClient because some of our clients still want Java 
1.1.8 compatibility. I hate having to do so, but I do not find it appropriate 
to impose such requirement on the rest of the universe just because some folks 
are absolutely adamant about supporting Mac OS 9.  

Oleg

Mime
View raw message