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

[Jamil Nimeh]

Hello Xuelei, et. al:

I have an updated webrev that does lazy instantiation of the 
StatusResponseManager.  It will happen if the enabling property is true 
and a ServerHandshaker attempts to get the SRM from the context.  If it 
has not been created it will be at that point in time.

http://cr.openjdk.java.net/~jnimeh/reviews/8145854/webrev.02/

Thanks,
--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