Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Sean Mullan]

On 11/8/18 4:06 PM, Xuelei Fan wrote:
To make sure the SecureCacheResponse class work, two new tests are added 
(DefaultCacheResponse for default implementation, DummyCacheResponse for 
a test implementation):

     http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/


I think you mean http://cr.openjdk.java.net/~xuelei/8212261/webrev.05/

Looks good.

--Sean



Thanks,
Xuelei

On 11/8/2018 7:03 AM, Sean Mullan wrote:

On 11/7/18 7:22 PM, Xuelei Fan wrote:

On 11/7/2018 1:30 PM, Sean Mullan wrote:

   https://bugs.openjdk.java.net/browse/JDK-8213161
   http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/


I didn't see a test for SecureCacheResponse - is it possible?

JDK does not have the reference implementation of SecureCacheResponse.


Ah, I see. I am sure there is a good reason, but why doesn't it have 
an implementation?



You could also add a test case for IllegalStateExc.


Added in the same test file.

lines 108-113 of HttpsSession.java should be indented 4 more spaces. 
Otherwise looks ok to me.



Updated.

New webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/


Looks good.

--Sean

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

To make sure the SecureCacheResponse class work, two new tests are added 
(DefaultCacheResponse for default implementation, DummyCacheResponse for 
a test implementation):

http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/

Thanks,
Xuelei

On 11/8/2018 7:03 AM, Sean Mullan wrote:

On 11/7/18 7:22 PM, Xuelei Fan wrote:

On 11/7/2018 1:30 PM, Sean Mullan wrote:

   https://bugs.openjdk.java.net/browse/JDK-8213161
   http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/


I didn't see a test for SecureCacheResponse - is it possible?

JDK does not have the reference implementation of SecureCacheResponse.


Ah, I see. I am sure there is a good reason, but why doesn't it have an 
implementation?



You could also add a test case for IllegalStateExc.


Added in the same test file.

lines 108-113 of HttpsSession.java should be indented 4 more spaces. 
Otherwise looks ok to me.



Updated.

New webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/


Looks good.

--Sean

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Daniel Fuchs]

On 08/11/2018 15:03, Sean Mullan wrote:
Ah, I see. I am sure there is a good reason, but why doesn't it have an 
implementation?




IIRC there was an implementation in the deploy code.

best regards,

-- daniel

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Sean Mullan]

On 11/7/18 7:22 PM, Xuelei Fan wrote:

On 11/7/2018 1:30 PM, Sean Mullan wrote:

   https://bugs.openjdk.java.net/browse/JDK-8213161
   http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/


I didn't see a test for SecureCacheResponse - is it possible?

JDK does not have the reference implementation of SecureCacheResponse.


Ah, I see. I am sure there is a good reason, but why doesn't it have an 
implementation?



You could also add a test case for IllegalStateExc.


Added in the same test file.

lines 108-113 of HttpsSession.java should be indented 4 more spaces. 
Otherwise looks ok to me.



Updated.

New webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/


Looks good.

--Sean

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

On 11/7/2018 1:30 PM, Sean Mullan wrote:

   https://bugs.openjdk.java.net/browse/JDK-8213161
   http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/


I didn't see a test for SecureCacheResponse - is it possible?

JDK does not have the reference implementation of SecureCacheResponse.


You could also add a test case for IllegalStateExc.


Added in the same test file.

lines 108-113 of HttpsSession.java should be indented 4 more spaces. 
Otherwise looks ok to me.



Updated.

New webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/

Thanks,
Xuelei

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Sean Mullan]

On 11/5/18 1:52 PM, Xuelei Fan wrote:

Hi Chris and Sean,

There are a few feedback for the CSR approval.  I updated to use 
Optional for the returned value.  For more details, please 
refer to:

   https://bugs.openjdk.java.net/browse/JDK-8213161
   http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/


I didn't see a test for SecureCacheResponse - is it possible? You could 
also add a test case for IllegalStateExc.


lines 108-113 of HttpsSession.java should be indented 4 more spaces. 
Otherwise looks ok to me.


--Sean




Please let me know if you are OK with this change.

Thanks,
Xuelei

On 11/2/2018 11:42 AM, Xuelei Fan wrote:

Thanks for the review and suggestions, Chris and Sean.

I just finalized the CSR.

Thanks,
Xuelei

On 11/2/2018 5:58 AM, Chris Hegarty wrote:

Thanks for the updates Xuelei, some minor comments inline..

On 1 Nov 2018, at 23:42, Xuelei Fan > wrote:


On 11/1/2018 11:24 AM, Sean Mullan wrote:

On 10/31/18 11:52 AM, Chris Hegarty wrote:

Xuelei,

On 30/10/18 20:55, Xuelei Fan wrote:

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need 
richer information for the underlying TLS connections, for 
example the negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated 
methods, by the end of Nov. 2, 2018.


Here is the proposal:
https://bugs.openjdk.java.net/browse/JDK-8213161
Are there any security issues associated with returning the 
SSLSession, since it is mutable?
It should be fine.  The update APIs of the session (invalidating, 
bind values) does not impact the connection.


Alternatively, as is done in the new HTTP Client, an immutable
SSLSession instance can be returned.

+ *   SHOULD override this method with appropriate 
implementation.

s/appropriate/an appropriate/
I would probably not capitalize "SHOULD" and just say "should". 
"SHOULD" is more common in RFCs. I don't see that much in javadocs.
+ * @implNote The JDK Reference Implementation supports this 
operation.
+ *   As an application may have to use this operation 
for more
+ *   security parameters, it is recommended to support 
this

+ *   operation in all implementations.
I think it should be obvious that the JDK implementation would 
override this method so not sure that first sentence is necessary. 
The other sentence seems like it could be combined with the 
previous sentence, ex:
"Subclasses should override this method with an appropriate 
implementation since an application may need to access additional 
parameters associated with the SSL session."

Updated accordingly, in the CSR and webrev:
https://bugs.openjdk.java.net/browse/JDK-8213161


The CSR looks good. I made a few minor edits to the verbiage
and added myself as reviewer.

The title will need to be updated to reflect the addition of the
new method in SecureCacheResponse. Maybe:

"Add SSLSession accessors to HttpsURLConnection and
SecureCacheResponse"

-Chris.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Chris Hegarty]

> On 5 Nov 2018, at 18:52, Xuelei Fan  wrote:
> 
> Hi Chris and Sean,
> 
> There are a few feedback for the CSR approval.  I updated to use 
> Optional for the returned value.  For more details, please refer 
> to:
>  https://bugs.openjdk.java.net/browse/JDK-8213161
>  http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/

Looks ok to me.

-Chris.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

Hi Chris and Sean,

There are a few feedback for the CSR approval.  I updated to use 
Optional for the returned value.  For more details, please 
refer to:

  https://bugs.openjdk.java.net/browse/JDK-8213161
  http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/


Please let me know if you are OK with this change.

Thanks,
Xuelei

On 11/2/2018 11:42 AM, Xuelei Fan wrote:

Thanks for the review and suggestions, Chris and Sean.

I just finalized the CSR.

Thanks,
Xuelei

On 11/2/2018 5:58 AM, Chris Hegarty wrote:

Thanks for the updates Xuelei, some minor comments inline..

On 1 Nov 2018, at 23:42, Xuelei Fan > wrote:


On 11/1/2018 11:24 AM, Sean Mullan wrote:

On 10/31/18 11:52 AM, Chris Hegarty wrote:

Xuelei,

On 30/10/18 20:55, Xuelei Fan wrote:

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need 
richer information for the underlying TLS connections, for example 
the negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated 
methods, by the end of Nov. 2, 2018.


Here is the proposal:
https://bugs.openjdk.java.net/browse/JDK-8213161
Are there any security issues associated with returning the 
SSLSession, since it is mutable?
It should be fine.  The update APIs of the session (invalidating, 
bind values) does not impact the connection.


Alternatively, as is done in the new HTTP Client, an immutable
SSLSession instance can be returned.

+ *   SHOULD override this method with appropriate 
implementation.

s/appropriate/an appropriate/
I would probably not capitalize "SHOULD" and just say "should". 
"SHOULD" is more common in RFCs. I don't see that much in javadocs.
+ * @implNote The JDK Reference Implementation supports this 
operation.
+ *   As an application may have to use this operation 
for more
+ *   security parameters, it is recommended to support 
this

+ *   operation in all implementations.
I think it should be obvious that the JDK implementation would 
override this method so not sure that first sentence is necessary. 
The other sentence seems like it could be combined with the previous 
sentence, ex:
"Subclasses should override this method with an appropriate 
implementation since an application may need to access additional 
parameters associated with the SSL session."

Updated accordingly, in the CSR and webrev:
https://bugs.openjdk.java.net/browse/JDK-8213161


The CSR looks good. I made a few minor edits to the verbiage
and added myself as reviewer.

The title will need to be updated to reflect the addition of the
new method in SecureCacheResponse. Maybe:

"Add SSLSession accessors to HttpsURLConnection and
SecureCacheResponse"

-Chris.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

Thanks for the review and suggestions, Chris and Sean.

I just finalized the CSR.

Thanks,
Xuelei

On 11/2/2018 5:58 AM, Chris Hegarty wrote:

Thanks for the updates Xuelei, some minor comments inline..

On 1 Nov 2018, at 23:42, Xuelei Fan > wrote:


On 11/1/2018 11:24 AM, Sean Mullan wrote:

On 10/31/18 11:52 AM, Chris Hegarty wrote:

Xuelei,

On 30/10/18 20:55, Xuelei Fan wrote:

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need 
richer information for the underlying TLS connections, for example 
the negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated 
methods, by the end of Nov. 2, 2018.


Here is the proposal:
https://bugs.openjdk.java.net/browse/JDK-8213161
Are there any security issues associated with returning the 
SSLSession, since it is mutable?
It should be fine.  The update APIs of the session (invalidating, bind 
values) does not impact the connection.


Alternatively, as is done in the new HTTP Client, an immutable
SSLSession instance can be returned.

+ *   SHOULD override this method with appropriate 
implementation.

s/appropriate/an appropriate/
I would probably not capitalize "SHOULD" and just say "should". 
"SHOULD" is more common in RFCs. I don't see that much in javadocs.
+ * @implNote The JDK Reference Implementation supports this 
operation.
+ *   As an application may have to use this operation 
for more

+ *   security parameters, it is recommended to support this
+ *   operation in all implementations.
I think it should be obvious that the JDK implementation would 
override this method so not sure that first sentence is necessary. 
The other sentence seems like it could be combined with the previous 
sentence, ex:
"Subclasses should override this method with an appropriate 
implementation since an application may need to access additional 
parameters associated with the SSL session."

Updated accordingly, in the CSR and webrev:
https://bugs.openjdk.java.net/browse/JDK-8213161


The CSR looks good. I made a few minor edits to the verbiage
and added myself as reviewer.

The title will need to be updated to reflect the addition of the
new method in SecureCacheResponse. Maybe:

"Add SSLSession accessors to HttpsURLConnection and
SecureCacheResponse"

-Chris.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Chris Hegarty]

Thanks for the updates Xuelei, some minor comments inline..

> On 1 Nov 2018, at 23:42, Xuelei Fan  wrote:
> 
> On 11/1/2018 11:24 AM, Sean Mullan wrote:
>> On 10/31/18 11:52 AM, Chris Hegarty wrote:
>>> Xuelei,
>>> 
>>> On 30/10/18 20:55, Xuelei Fan wrote:
 Hi,
 
 For the current HttpsURLConnection, there is not much security parameters 
 exposed in the public APIs.  An application may need richer information 
 for the underlying TLS connections, for example the negotiated TLS 
 protocol version.
 
 Please let me know if you have concerns to add a new method 
 HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, 
 by the end of Nov. 2, 2018.
 
 Here is the proposal:
  https://bugs.openjdk.java.net/browse/JDK-8213161
>> Are there any security issues associated with returning the SSLSession, 
>> since it is mutable?
> It should be fine.  The update APIs of the session (invalidating, bind 
> values) does not impact the connection.

Alternatively, as is done in the new HTTP Client, an immutable
SSLSession instance can be returned.

>> + *   SHOULD override this method with appropriate 
>> implementation.
>> s/appropriate/an appropriate/
>> I would probably not capitalize "SHOULD" and just say "should". "SHOULD" is 
>> more common in RFCs. I don't see that much in javadocs.
>> + * @implNote The JDK Reference Implementation supports this operation.
>> + *   As an application may have to use this operation for more
>> + *   security parameters, it is recommended to support this
>> + *   operation in all implementations.
>> I think it should be obvious that the JDK implementation would override this 
>> method so not sure that first sentence is necessary. The other sentence 
>> seems like it could be combined with the previous sentence, ex:
>> "Subclasses should override this method with an appropriate implementation 
>> since an application may need to access additional parameters associated 
>> with the SSL session."
> Updated accordingly, in the CSR and webrev:
>https://bugs.openjdk.java.net/browse/JDK-8213161 
> 
The CSR looks good. I made a few minor edits to the verbiage
and added myself as reviewer.

The title will need to be updated to reflect the addition of the
new method in SecureCacheResponse. Maybe:

"Add SSLSession accessors to HttpsURLConnection and
SecureCacheResponse"

-Chris.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

On 11/1/2018 11:24 AM, Sean Mullan wrote:

On 10/31/18 11:52 AM, Chris Hegarty wrote:

Xuelei,

On 30/10/18 20:55, Xuelei Fan wrote:

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need 
richer information for the underlying TLS connections, for example 
the negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated 
methods, by the end of Nov. 2, 2018.


Here is the proposal:
 https://bugs.openjdk.java.net/browse/JDK-8213161


Are there any security issues associated with returning the SSLSession, 
since it is mutable?
It should be fine.  The update APIs of the session (invalidating, bind 
values) does not impact the connection.




+ *   SHOULD override this method with appropriate 
implementation.


s/appropriate/an appropriate/

I would probably not capitalize "SHOULD" and just say "should". "SHOULD" 
is more common in RFCs. I don't see that much in javadocs.


+ * @implNote The JDK Reference Implementation supports this operation.
+ *   As an application may have to use this operation for more
+ *   security parameters, it is recommended to support this
+ *   operation in all implementations.

I think it should be obvious that the JDK implementation would override 
this method so not sure that first sentence is necessary. The other 
sentence seems like it could be combined with the previous sentence, ex:


"Subclasses should override this method with an appropriate 
implementation since an application may need to access additional 
parameters associated with the SSL session."



Updated accordingly, in the CSR and webrev:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.02/

Thanks,
Xuelei

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Sean Mullan]

On 10/31/18 11:52 AM, Chris Hegarty wrote:

Xuelei,

On 30/10/18 20:55, Xuelei Fan wrote:

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need richer 
information for the underlying TLS connections, for example the 
negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated 
methods, by the end of Nov. 2, 2018.


Here is the proposal:
 https://bugs.openjdk.java.net/browse/JDK-8213161


Are there any security issues associated with returning the SSLSession, 
since it is mutable?


+ *   SHOULD override this method with appropriate 
implementation.


s/appropriate/an appropriate/

I would probably not capitalize "SHOULD" and just say "should". "SHOULD" 
is more common in RFCs. I don't see that much in javadocs.


+ * @implNote The JDK Reference Implementation supports this operation.
+ *   As an application may have to use this operation for more
+ *   security parameters, it is recommended to support this
+ *   operation in all implementations.

I think it should be obvious that the JDK implementation would override 
this method so not sure that first sentence is necessary. The other 
sentence seems like it could be combined with the previous sentence, ex:


"Subclasses should override this method with an appropriate 
implementation since an application may need to access additional 
parameters associated with the SSL session."



--Sean

Re: 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 > 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.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Chris Hegarty]

> On 31 Oct 2018, at 20:03, Xuelei Fan  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.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

On 10/31/2018 8:52 AM, Chris Hegarty wrote:

Xuelei,

On 30/10/18 20:55, Xuelei Fan wrote:

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need richer 
information for the underlying TLS connections, for example the 
negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated 
methods, by the end of Nov. 2, 2018.


Here is the proposal:
 https://bugs.openjdk.java.net/browse/JDK-8213161

Thanks,
Xuelei


The new method looks fine.

On the deprecation, minimally the annotation should contain
the "since" element, which will have a value of `12`.


Hm, it looks better now if using the "since" element.  Thanks!


Also, I wonder, now that I see the spec, whether or not it is
actually a good idea to deprecate these methods. The reason
I ask this is that the new method, getSSLSession, can throw
UOE, which effectively makes it an optional method. Access
to the specific security parameters provided by the existing
methods is non-optional. This is a clear difference, and
possibly a reason, for folk not interested in the "new"
parameters, to continue to use the existing methods.

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.


To make it more clear, I added a implNote in the getSSLSession() method, 
and recommend to support it in all implementations.


I prefer to deprecate these methods a little bit more, but not very 
strong.  If there is a strong preference, I can live with it.


BTW, I also updated the java.net.SecureCacheResponse accordingly.  I'm 
not sure if SecureCacheResponse is really used in practice.  I did not 
find the implementation of it in JDK.


Here is the webrev if you want to look at the implementation details:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.00/

Thanks,
Xuelei

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

[Chris Hegarty]

Xuelei,

On 30/10/18 20:55, Xuelei Fan wrote:

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need richer 
information for the underlying TLS connections, for example the 
negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, 
by the end of Nov. 2, 2018.


Here is the proposal:
     https://bugs.openjdk.java.net/browse/JDK-8213161

Thanks,
Xuelei


The new method looks fine.

On the deprecation, minimally the annotation should contain
the "since" element, which will have a value of `12`.

Also, I wonder, now that I see the spec, whether or not it is
actually a good idea to deprecate these methods. The reason
I ask this is that the new method, getSSLSession, can throw
UOE, which effectively makes it an optional method. Access
to the specific security parameters provided by the existing
methods is non-optional. This is a clear difference, and
possibly a reason, for folk not interested in the "new"
parameters, to continue to use the existing methods.

-Chris

A new proposal to add methods to HttpsURLConnection to access SSLSession

[Xuelei Fan]

Hi,

For the current HttpsURLConnection, there is not much security 
parameters exposed in the public APIs.  An application may need richer 
information for the underlying TLS connections, for example the 
negotiated TLS protocol version.


Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, 
by the end of Nov. 2, 2018.


Here is the proposal:
https://bugs.openjdk.java.net/browse/JDK-8213161

Thanks,
Xuelei