[
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.
Oleg
> 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<?>[]) 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]
