This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds and have James Denton on-line!
See this thread for details.
Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

HTTPS over Apache Commons HttpConnection.  RSS feed

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have an EJB that connects to a web server over HTTPS and reads some data. It connects to the server using a url similar to the following...
https://my.host.name/path/to/some.cgi?queryString
Using standard java.net.URL or java.net.URLConnection, everything works fine.
Except now I'mm supposed to implement a socket-level timeout to keep it from waiting too long for a connection. So, I used the Apache Commons project's HttpClient version 2.0 alpha 2 package to replace the URL code.
There is infuriatingly little documentation on HttpClient, and absolutely none about using HTTPS. So I'm not 100% sure I've done it correctly.
The problem is that I get an exception:
javax.net.ssl.SSLHandshakeException: FATAL Alert:HANDSHAKE_FAILURE - The handshake handler was unable to negotiate an acceptable set of security parameters.
I don't understand. Why does the EJB connect fine when using the java.net.URL object, and not the HttpsClient code? I'm using the same server, same certfiles, same everything.
The EJB is hosted on a Weblogic 6.1 server, and trying to connect to an Apache server. I have no control over the configuration of the Apache server, and I know nothing about it other than it is apache, and it works fine when I use java.net.URL, or when I browse to it with a web browser.
Here is a code snipet...
----------------
String urlText = "https://my.host.name/path/to/some.cgi?queryString";
URI myUrl = new URI( urlText );
Protocol myProtocol = Protocol.getProtocol(myUrl.getScheme());
HttpConnection connection = new HttpConnection(myUrl.getHost(), 443, myProtocol);
connection.setSoTimeout(10000);
HttpState state = new HttpState();
GetMethod method = new GetMethod(myUrl.toString());
// This is where the exception is thrown.
//
method.execute(state, connection);
--------------------------
I've also tried other classes in the HttpClient API, actually creating a HostConfiguration object and using the actual HttpClient class and all that, but I found an example of doing almost exactly the same thing I'm doing, but only using HTTP, and it was done in the way indicated above.
Does anyone have any idea why this would be happening? Again, remember, it works fine when I use plain old java.net.URL.
 
J Norm
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, nevermind. I solved the problem.
For the record, the problem is the order of jars in my weblogic server classpath. I found a related problem in a Weblogic newsgroup that suggested putting the JSSE jars in the classpath before the weblogic.jar. So I tried that and now everything works.
It is still very odd that this problem only pops up when I use the HttpClient package, not when using java.net.URL.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!