[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    [jira] Resolved: (HTTPCLIENT-1059) Allow for the on-demand creation
From:       "Oleg Kalnichevski (JIRA)" <jira () apache ! org>
Date:       2011-03-14 19:03:29
Message-ID: 564107270.1585.1300129409590.JavaMail.tomcat () hel ! zones ! apache ! org
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/HTTPCLIENT-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Oleg Kalnichevski resolved HTTPCLIENT-1059.
-------------------------------------------

       Resolution: Won't Fix
    Fix Version/s:     (was: Future)

Mark,
Please re-open the issue when you are ready to contribute a patch.

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


[prev in list] [next in list] [prev in thread] [next in thread]