Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()

I have been using HttpClient for a while now with success. However, I have recently encountering some problems which I think have an easy solution, although it is not accessible to me through the current API.

Situation (my test enviroment):

ServerA:

• Runs Tomcat 6
• Contains jar files that are downloaded via webstart
• Only accepts non-SSL connections

ServerB:

• Runs Tomcat 6
• Contains jar files that are downloaded via webstart
• Contains a servlet
• Only accepts SSL connections

If I connect to serverB (via webstart) to download the jars, my app connects to the servlet on ServerB and everything is fine.
However, if I connect to ServerA (via webstart) and then the app tries to connect to ServerB, the SSL connection cannot be established.

I believe this has to do with the underlying socket factory that is being used. This is crucial, since I need to use the default socket factory managed by webstart that automatically prompts for certificate issues and allows for automatic use of client certificates.

Theory
----------------
Terminology:
javax.SSLSocketFactory = javax.net.ssl.SSLSocketFactory
apache.SSLSocketFactory = org.apache.http.conn.ssl.SSLSocketFactory

I am not exactly sure what is happening, but I have a theory. In my theory, the crux of the problem is that the DEFAULT apache.SSLSocketFactory is set in the static initializer of the apache.SSLSocketFactory class. In the first scenario above, webstart creates a new javax.SSLSocketFactory for the jar download, and makes this the default. This happens before the apache.SSLSocketFactory class is loaded, and, therefore, before the static initializer is executed. In the second scenario, this happens in the other order and the javax.SSLSocketFactory wrapped by the apache.SSLSocketFactory is not the one used by webstart

I need to ensure that the javax.SSLSocketFactory is initialized (and replaced) first, and then create an apache.SSLSocketFactory to wrap this. The apache.SSLSocketFactory does have a wrapping construtor, but it is the private no-argument constructor. If this were public in some manner, I could create my apache.SSLSocketFactory after I was sure that the HttpsURLConnection default socket factory was the one I needed.

Theory Corroborated
--------------------
I downloaded the httpclient 4.01 source (the version we are currently using), changed the no-arg constructor to be public, and used it to create a new apache.SSLSocketFactory after I initialized the HttpsURLConnection. This did indeed solve the problem. Perhaps there is more going on here than I realize, but it was not complicated and it worked.

Another far easier work-around would be to do something like this:

Constructor<SSLSocketFactory> con = SSLSocketFactory.class.getConstructor((Class<?>[]) null);
con.setAccessible(true);
fact = con.newInstance((Object[])null);

RFE
-------------

Make the no-arg constructor public or provide access to it though another method

I don't really see a down-side to making the no-arg constructor public. However, if this needs to be private to prevent certain types of subclassing, a static method could be added to create an apache.SSLSocketFactory that wraps the default javax.SSLSocketFactory. If the constructor is private just for historical reasons, than it may be easier to just make it public.

If making the constructor public is undesirable for some reason, here is a recommendation for a change with minimal impact on the API and existing clients:

Add method createSocketFactory(), as:

public static SSLSocketFactory createSocketFactory()

{ return new SSLSocketFactory(); }

This will:
1) Solve the problem
2) Preserve backwards compatibility
3) Encourage the new semantics
4) Ensure that any protections afforded by the private SSLSocketFactory constructor are still in place

In any case, after this change I think it is a good idea to deprecate the getSocketFactory() method. I would suspect that this method is not accessed frequently, so there is no real reason to optimize it in this way. I am also not sure if encouraging the use of a mutable* global shared socket factory is a good idea. If people want to use a particular socket factory, they should just create a new one, configure it how they want, and then keep it around to reuse as appropriate...without being in danger of another part of the application configuring it differently.

• It seems to be mutable only through a single deprecated method, however.