hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Claassen (JIRA)" <j...@apache.org>
Subject [jira] Created: (HTTPCLIENT-1059) Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()
Date Fri, 18 Feb 2011 14:39:38 GMT
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):

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

* 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.

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<?>[])
fact = con.newInstance((Object[])null);


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

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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message