Laurent,
I did some additional research and what I have found seems to only reinforce my
previous assumptions
1.) The problem is perfectly reproducible with IBM JDK and IBM JSSE. There's no need
for WAS.
[DEBUG] HttpClient - -Java version: 1.3.0
[DEBUG] HttpClient - -Java vendor: IBM Corporation
<snip>
[DEBUG] HttpClient - -Operating system name: Windows 2000
[DEBUG] HttpClient - -Operating system architecture: x86
[DEBUG] HttpClient - -Operating system version: 5.0
[DEBUG] HttpClient - -SUN 1.2: SUN (DSA key/parameter generation; DSA signing; SHA-1,
MD5 digests; SecureRandom; X.509 certificates; JKS keystore)
[DEBUG] HttpClient - -JSSE 1.0: IBM JSSE provider
[DEBUG] HttpClient - -IBMJCE 1.2: IBMJCE Provider implements the following: HMAC-SHA1,
MD2, MD5, MARS, SHA, MD2withRSA,
<snip>
[DEBUG] HttpConnection - -HttpConnection.setSoTimeout(0)
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:198)
at java.net.Socket.getSendBufferSize(Socket.java:526)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:700)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:659)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:527)
at org.apache.commons.httpclient.Test.main(Test.java:17)
Exception in thread "main"
2.) Plain socket test worked fine with the same setup.
3.) I think I know why the problem only manifests itself with newer HttpClient versions
As you can see from the log, something goes wrong when trying to determine send buffer
size of the underlying socket implementation. This clearly looks like a bug in the IBM
JSSE.
Invocation of java.net.Socket.getSendBufferSize is a fairly new addition, which was
not there in late February.
4.) Please make sure that version of IBM JSSE that you have is indeed 1.0.3 or newer.
HttpClient has been reported to fail with the similar exception when run with IBM JSSE
1.0.2 or below. IBM JSSE 1.0.3 appears to have fixed the aforementioned problem with
the send buffer size.
Execute your test application with the debug log enabled and watch for a similar
statement
[DEBUG] HttpClient - -JSSE 1.0: IBM JSSE provider
HTH
Oleg
-----Original Message-----
From: Laurent Garcia [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2003 14:19
To: Commons HttpClient Project
Subject: Re: IBMJSSE implementation issue
Oleg,
I try to disabling stale connection and I have still Socket closed.
I don't want to take your time but you can do a very simple, test this code
in a servlet with WSAD 5.0 (with the default JSSE)
HttpClient httpclient = new HttpClient();
httpget = new GetMethod("https://www.verisign.com/";);
httpclient.executeMethod(httpget);
I assume that I am not the only people that use http-client in a servlet in
WSAD-WAS 5.0 environment.
Laurent
----- Original Message -----
From: "Kalnichevski, Oleg" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 11:54 AM
Subject: RE: IBMJSSE implementation issue
Laurent,
HttpClient relies on underlying JSSE library to establish SSL connections.
If there's something wrong with SSL, in the overwhelming majority of cases
it has nothing to do with HttpClient as such. Usually SSL problems are
caused by misconfigured JSSE stack.
Please refer to the troubleshooting section of our SSL guide and see if the
plain SSL socket test works for you
http://jakarta.apache.org/commons/httpclient/sslguide.html
Oleg
-----Original Message-----
From: Laurent Garcia [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2003 11:44
To: Commons HttpClient Project
Subject: Re: IBMJSSE implementation issue
Oleg,
Thank you for your (quick) response, I edit the Manifest file (I made a copy
below) and it seems that the version is 1.03
Manifest-Version: 1.0
Created-By: Ant 1.4.1
Name: com/ibm/jsse/ com/ibm/net/ssl/www/ com/ibm/net/ssl/ com/ibm/net/ss
l/internal/www/protocol/https/ com/ibm/net/ssl/www/protocol/http/ com/i
bm/net/ssl/www/protocol/https/ com/ibm/pkcs11/ com/ibm/pkcs11/nat/ com/
ibm/security/cert/ com/ibm/sslight/ com/ibm/sslite/ javax/net/ javax/ne
t/ssl/ javax/security/cert/
IBM-Reusable-JVM-Compatible: True
Build-Level: -20021008
Implementation-Vendor: IBM Corporation
Implementation-Title: JSSE Package
Implementation-Version: 1.0.3
Laurent
----- Original Message -----
From: "Kalnichevski, Oleg" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 11:34 AM
Subject: RE: IBMJSSE implementation issue
Laurent,
Make sure that the version of IBMJSSE library WSAD is using is 1.0.3.
Oleg
-----Original Message-----
From: Laurent Garcia [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2003 11:30
To: [EMAIL PROTECTED]
Subject: IBMJSSE implementation issue
Hi,
I was working with an old commons-httpclient lib (18/2/2003) that work
correctly for https connexion with both SUN adn IBM jsse implemention.
But I just replaced my commons-httpclient by commons-httpclient-2.0-rc1.jar
and now it is still working with SUN but I have a systematic socked closed
error If I try this code in a sevlet (with WSAD 5.0) :
System.out.println("HttpsTestServlet starting test...");
GetMethod httpget;
try {
HttpClient httpclient = new HttpClient();
httpget = new GetMethod("https://www.verisign.com/";);
httpclient.executeMethod(httpget);
System.out.println(httpget.getStatusLine().toString());
} catch (Exception e) {
System.out.println(e);
}
System.out.println("HttpsTestServlet test completed...");
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:214)
at java.net.Socket.getSendBufferSize(Socket.java:548)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:700)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:625)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500)
is it a bug ? or I did something wrong ?
Thank you
Laurent
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
