hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-1059) Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()
Date Tue, 22 Feb 2011 19:26:38 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997986#comment-12997986

Oleg Kalnichevski commented on HTTPCLIENT-1059:

A diff file (or a patch in Apache lingo) would be the easiest way to communicate the changes
you are proposing.


> 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: 3.1 Final, 4.0.3, 4.1 Final
>         Environment: Applications using webstart
>            Reporter: Mark Claassen
>              Labels: HttpsURLConnection, SSLSocketFactory, ssl, webstart
>             Fix For: Future
>   Original Estimate: 24h
>  Remaining Estimate: 24h
> 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<?>[])
> con.setAccessible(true);
> 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 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message