Hmmm, that's a good point. Let me look into lazy initialization and see
if I can come up with something reasonable.
--Jamil
On 02/22/2016 04:20 PM, Xuelei Fan wrote:
Hi Jamil,
A comment for safe and robust.
Suppose in the future, JDK enables OSCP stapling in server side by default
jdk.tls.server.enableStatusRequestExtension = true
the following code might be not ideal in practice:
SSLContextImpl.java
87 if (serverEnableStapling) {
88 statusResponseManager = new StatusResponseManager();
89 }
if an application is always run in client side, for example open a HTTPS
URL:
URL url = "https://www.example.com";;
url.openConnect(); // statusResponseManager may be generated
I may use a lazy loading mode, and statusResponseManager would not be
initialized until it get used.
Thanks,
Xuelei
On 2/22/2016 4:37 AM, Jamil Nimeh wrote:
Hello all,
This fix makes a change to SSLContextImpl so it only creates a
StatusResponseManager if OCSP stapling has been enabled on the server
side. This fix also takes care of a deviation from the design in terms
of how SSLSockets/Engines determine if stapling has been enabled. The
new code matches the design, that SSLSockets/SSLEngines created from an
SSLContextImpl will all share the enable/disable state at the time the
SSLContext was created. If changes happen to the properties and another
SSLContextImpl is made then those properties will be evaluated at
instantiation time.
Bug: https://bugs.openjdk.java.net/browse/JDK-8145854
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8145854/webrev.01/
Thanks,
--Jamil
