I only included the hostname resolver in my constructor because it was a final variable.
> There is a SSLSocketFactory(SSLContext, X509HostnameVerifier) constructor > which is effectively equivalent to > SSLSocketFactory(javax.net.ssl.SSLSocketFactory X509HostnameVerifier) as far > as I can tell. I don't think so. This is the similar to what is in 4.2 beta1. I think I just need to use the default one from HttpsURLConnection. All the certificate stuff is handled internally to Webstart. Webstart has its own keystore information, but can also access the System's. I have not asked the Oracle deployment folks for all these gritty details, but the wrapping concept seems to work. I could try to check with Oracle, but I don't think another similar one could be created. I think I will submit a patch to HttpClient as you suggested and see what happens. Mark -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Monday, April 09, 2012 4:11 PM To: HttpClient User Discussion Subject: RE: Access to "system" SSL socket factory. On Mon, 2012-04-09 at 15:18 -0400, Mark Claassen wrote: > I have had some success wrapping the socket factory in HTTP Client > (v4.1.3) and getting that to work. :) However, I have a few > questions: > > First, how do you feel about having a constructor that would set the final > variables directly: > - javax.net.ssl.SSLSocketFactory > - HostNameResolver > - X509HostnameVerifier > Having this would have made what I needed to do very straight-forward > and simple since I could have just passed in the socket factory I wanted to > use. > Hi Mark HostNameResolver has been deprecated in 4.2 because it does not support multi-home hostnames. Moreover, the DNS resolution logic has been moved from scheme socket factory level to the connection operator level. There is a SSLSocketFactory(SSLContext, X509HostnameVerifier) constructor which is effectively equivalent to SSLSocketFactory(javax.net.ssl.SSLSocketFactory X509HostnameVerifier) as far as I can tell. But by all of means feel free to submit a patch. > Second, in this class there is a Socket created not through the > SocketFactory in one place, and I was wondering why. Here is what it > looks like in org.apache.http.conn.ssl.SSLSocketFactory > > public Socket connectSocket( > final Socket socket, > final InetSocketAddress remoteAddress, > final InetSocketAddress localAddress, > final HttpParams params) throws IOException, > UnknownHostException, ConnectTimeoutException { > if (remoteAddress == null) { > throw new IllegalArgumentException("Remote address may not be > null"); > } > if (params == null) { > throw new IllegalArgumentException("HTTP parameters may not be > null"); > } > >>>> Socket sock = socket != null ? socket : new Socket(); <<<< > > Shouldn't this be > Socket sock = socket != null ? socket : > socketfactory.createSocket(); > Yes, this is obviously conceptually wrong. Fixed in SVN trunk. Oleg > Later in the code, it then checks the Socket type, and since it will not be > an SSL socket, it will then call: > this.socketfactory.createSocket(sock, hostname, port, true); > > This seemed an odd pattern to me. I can see a potential reason for > it, but wasn't sure about it and was not sure if this would be a possible > point of failure in my situation. > > Thanks, > Mark > > -----Original Message----- > From: Mark Claassen [mailto:[email protected]] > Sent: Wednesday, April 04, 2012 5:01 PM > To: [email protected] > Subject: Access to "system" SSL socket factory. > > We are still using HttpClient 4.01 and were considering upgrading to > 4.1, but I see a feature we were using is gone. In 4.01, there was a > DEFAULT_FACTORY which was the defined from > HttpsURLConnection.getDefaultSSLSocketFactory(); > > This was very useful to us. The reason for this was because our app > is launched by Java Webstart. When using the default socket factory, we can > benefit from Webstart handling the prompting for things like host name > verification. > > More importantly, however, was webstart's ability to interface with > the Window's keystore. We have a client that uses certificated based > authentication for their SSL connections. Using the default socket > factory makes everything just work. The users would get prompted for > a certificate and then they could activate it off their hardware > devices. (Presumably, then, the SSL encryption is handled by the > device. I have no idea how I would do this without webstart.) > > I guess I would like to know what is my best path to take to get this > working. Could I just subclass it and then override the > connectSocket() methods? I noticed that the javax SSLSocketFactory has > similar createSocket() methods... > > Thanks, > Mark > > > > > --------------------------------------------------------------------- > 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]
