hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: Httpclient under weblogic 7.0
Date Wed, 30 Mar 2005 07:52:50 GMT
Hello Petr,

this looks to me like the JSSE implements only part of the
socket methods. The problem originates from the fact that
java.net.Socket is a class rather than an interface. A class
that implements SSL sockets has to be derived from the
plain Socket class, and needs to override all methods that
will actually be used. Your JSSE implementation returns
a socket implementation that does override, among others,
Socket.getInputStream and Socket.getOutputStream, but
obviously not Socket.getSendBufferSize. When HttpClient
calls that method, the code in the base class java.net.Socket
gets executed. That code reports that the socket is not open,
because the base class method has never been asked to
open a socket, due to the overrides.
The best solution I can think of is to modify your factory
for SSL sockets. Instead of returning the SSL socket
directly, create another wrapper for it. The wrapper has
to forward the method invocations supported by the SSL
socket there, and can implement workarounds for other
methods - in this case getSendBufferSize. You should
experiment a little to determine the actual buffer size
used for sending, it's probably rather 2K or 4K than just
1 byte. Here is a code outline to get you started:

class MySocketWrapper extends java.net.Socket
  private Socket wrapped_socket;
  MySocketWrapper(Socket ws) { wrapped_socket = ws; }
  InputStream getInputStream() { return wrapped_socket.getInputStream(); }
  OutputStream getOutputStream() { return 
wrapped_socket.getOutputStream(); } 
  // lots more of the invocation forwarding stuff
  // and here are the workarounds
  int getSendBufferSize() { return 4096; } // or whatever fits
  // more, if necessary

hope that helps,

Andrš Petr (EXT) <PAndrs@CSAS.CZ> 
29.03.2005 17:17
Please respond to
"HttpClient Project"

"HttpClient Project" <httpclient-dev@jakarta.apache.org>

Httpclient under weblogic 7.0

Hi all,

I would like to reintroduce problem discussed here almost two years ago 
without solution. The problem is that HttpClient (I am using version 2.0.2 
but I observed the same behavior with 3.0RC1) doesn't work when used 
inside Weblogic application server version 7.0 SP4.

Here is nescessary to say, that it runs on JDK 1.3.1 and it cannot be 
changed because other JDK is not certified by BEA. Since there is no 
implementation of JSSE in JDK 1.3.1 Weblogic 7 has it's own which is 
actually implementation from Certicom (which is different from Sun's) and 
changing it would be similar problem as with JDK.

Exception stacktrace is as follows:

java.net.SocketException: Socket closed
        at java.net.PlainSocketImpl.socketGetOption(Native Method)
        at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:194)
        at java.net.Socket.getSendBufferSize(Socket.java:522)
.... unescessary stack trimmed.

The problem happens at line 750 of HttpConnection where 
socket.getSendBufferSize() is called an probably there is some problem, it 
is strange to me since I am not expert in this low level stuff. However, 
when I replaced this line and similar call socket.getReceiveBufferSize() 
on line 754 with harcoded value 1, things started to work.

to be complete here, logs WITHOUT described change when problem occurs 

systemout with both httpclient and weblogic SSL debug enabled:

2005/03/29 12:55:25:032 CEST [DEBUG] HttpClient - -Java version: 1.3.1_15
2005/03/29 12:55:25:032 CEST [DEBUG] HttpClient - -Java vendor: Sun 
Microsystems Inc.
2005/03/29 12:55:25:032 CEST [DEBUG] HttpClient - -Java class path: 
2005/03/29 12:55:25:048 CEST [DEBUG] HttpClient - -Operating system name: 
Windows XP
2005/03/29 12:55:25:048 CEST [DEBUG] HttpClient - -Operating system 
architecture: x86
2005/03/29 12:55:25:048 CEST [DEBUG] HttpClient - -Operating system 
version: 5.1
2005/03/29 12:55:25:048 CEST [DEBUG] HttpClient - -SUN 1.2: SUN (DSA 
key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X
..509 certificates; JKS keystore)
2005/03/29 12:55:25:048 CEST [DEBUG] HttpClient - -SunRsaSign 1.0: SUN's 
provider for RSA signatures
2005/03/29 12:55:25:282 CEST [DEBUG] HttpConnection - 
2005/03/29 12:55:25:282 CEST [DEBUG] HttpMethodBase - -Execute loop try 1
2005/03/29 12:55:25:298 CEST [DEBUG] header - ->> "CONNECT 
www.verisign.com:443 HTTP/1.1"
2005/03/29 12:55:25:298 CEST [DEBUG] HttpMethodBase - -Adding Host request 
2005/03/29 12:55:25:298 CEST [DEBUG] header - ->> "User-Agent: Jakarta 
2005/03/29 12:55:25:298 CEST [DEBUG] header - ->> "Host: 
2005/03/29 12:55:25:298 CEST [DEBUG] header - ->> "Proxy-Connection: 
2005/03/29 12:55:25:298 CEST [DEBUG] header - ->> "[\r][\n]"
2005/03/29 12:55:27:439 CEST [DEBUG] header - -<< "HTTP/1.1 200 Connection 
2005/03/29 12:55:27:439 CEST [DEBUG] header - -<< "Via: 1.1 
2005/03/29 12:55:27:470 CEST [DEBUG] ConnectMethod - -CONNECT status code 
<29.3.2005 12:55:27 CEST> <Debug> <TLS> <000000> <SSL Session TTL
<29.3.2005 12:55:27 CEST> <Debug> <TLS> <000000> <SSL Session TTL
<29.3.2005 12:55:27 CEST> <Debug> <TLS> <000000> <Weblogic license
export limited>
<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> <SSLSetup: loading

trusted CA certificates>
<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> 
<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> <SSLManager, getting

trusted CAs from TrustedCAFile: trusted-ca.pem>
<29.3.2005 12:55:29 CEST> <Info> <Security> <090121> <Loaded 1
client root 
CAs from TrustedCA File.>
<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> <clientInfo has

programmatic TrustManagerJSSE>
<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> <clientInfo has

programmatic HostnameVerifierJSSE>
<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> <clientInfo settings

<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> <Filtering JSSE

<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> 
<SSLIOContextTable.addContext(ctx): 1316414>
<29.3.2005 12:55:29 CEST> <Debug> <TLS> <000000> 
<SSLIOContextTable.findContext(is): 4217377>

Communication "on wire" from capture tool is
client to server: 

CONNECT www.verisign.com:443 HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/2.0.2
Host: www.verisign.com
Proxy-Connection: Keep-Alive

from server to client:

HTTP/1.1 200 Connection established
Via: 1.1 BUDS0006 

After showing this on console and in wire capture tool, mentioned 
exception occurs. I am connecting via proxy (MS ISA server) and I have 
implemented my own socket factory which uses weblogic SSL and trusts any 
host and certificate (otherwise trust and hostname validation fails). 
Connection using Weblogic's variant of HttpsUrlConnection works perfectly, 
but it is quite low level and that is why I am really interested in using 
Jakarta HTTP Client.

After I implemented simple hack described earlier working around call to 
socket.getSendBufferSize() and socket.getReceiveBufferSize() things 
started to work and I am able to retrieve whole document and no exception 
occurs. I would really appreciate your expertise, whether there is some 
problem in my modification I didn't spot, probably I should wrap these 
method calls in try/catch block and set some hardcoded default value only 
when exception occurs. I would like to ask what default value I should 

I am attaching links to logs and traffic produced (since they are quite 
big with debug enabled) and would like to ask you to look at it and check 
whether there is no problem. Because I wasn't able to copy/paste from wire 
capture tool, screenshot is attached. Link to logs is: 

Thank you really much for any assistance you can provide.


To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message