A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

I removed the deprecation parts in the update.  Here is the new webrev:
    http://cr.openjdk.java.net/~xuelei/8212261/webrev.01/

And the CSR was updated accordingly.
    https://bugs.openjdk.java.net/browse/JDK-8213161

Thanks,
Xuelei

On 11/1/2018 4:57 AM, Chris Hegarty wrote:
> 
>> On 31 Oct 2018, at 20:03, Xuelei Fan <xuelei.fan at oracle.com 
>> <mailto:xuelei.fan at oracle.com>> wrote:
>>> ...
>> Yes.  I had the same concern about the optional operation.  However, I 
>> came to a different conclusion if I'm from viewpoint of these users 
>> that need to use this new operation.
>>
>> If an application have to use this new operation, for example to 
>> access the negotiated TLS version, this operation is essential to it. 
>> Unfortunately, because of compatibility impact, we cannot force all 
>> implementation supports this new added operation.  It is a potential 
>> problem to those applications that need it.
>>
>> It would be nice if an implementation can support this operation as 
>> soon as possible.  If we just add the operation, providers may not 
>> aware there is a need to update their implementation.  Unfortunately. 
>> there is not much we can do to notify the provider.
>>
>> If we deprecated the duplicated methods, it is easier for providers to 
>> catch up with this new added operation, and move forward to support 
>> it. As the deprecating will show up building warnings, or even error 
>> if run in strict building mode.
> 
> I have no issue with the addition of the new method to access the
> SSLSession. Unfortunately, due to the evolutionary constraints of this
> API, the `getSSLSession` method will likely need to be specified to
> throw UOE. The actual JDK's HTTPS protocol handler implementation will
> not throw UOE.
> 
> Clearly there is a desire for non-JDK HTTPS protocol handler
> implementations to quickly determine the need to update their code and
> override the default implementation of `getSSLSession` ( to do something
> useful ), hence the request to deprecate the the existing individual
> security parameter accessor methods.
> 
> I don't believe that deprecating these individual security parameter
> accessors is a good idea for the following reasons:
> 
> 1) Deprecated warnings are only issued at compile-time, so only HTTPS
>     protocol handler implementations being recompiled may encounter the
>     warnings. Existing binary artifacts will not.
> 
> 2) More importantly. Forever more, developers wanting access to say,
>     the peer principle or the server's certificate chain, will be
>     encouraged to get them through an optional API ( rather than a
>     non-optional API ). This increases the risk that the code will
>     encounter an UOE. I don't think that this increased risk is justified
>     by the desire to not-have-two-ways-to-do-the-same-thing. I would
>     agree if this were a new API, but it is not.
> 
> HTTPS protocol handler implementations actively being maintained will
> likely quickly get requests from their users to provide a better
> implementation of this new method, as folk move towards TLS 1.3, etc.
> Maybe such requests will be sufficient to help adoption, at which point
> the deprecation of these methods could then be re-considered.
> 
> -Chris.
> 
>