RFR: JDK-8145854 SSLContextImpl.statusResponseManager should be generated if required

[Xuelei Fan]

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