Allow for the on-demand creation of a new SSLSocketFactory that wraps the
HttpsURLConnection.getDefaultSSLSocketFactory()
-------------------------------------------------------------------------------------------------------------------------
Key: HTTPCLIENT-1059
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1059
Project: HttpComponents HttpClient
Issue Type: New Feature
Components: HttpClient
Affects Versions: 4.1 Final, 4.0.3, 3.1 Final
Environment: Applications using webstart
Reporter: Mark Claassen
Fix For: Future
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
