I will revert it. I'm not going to argue with you about this.. I thought
it might have provided better debugging.
317 public byte[] produce(ConnectionContext context) ...
324 public byte[] produce(ServerHandshakeContext shc) ...
433 public byte[] produce(PostHandshakeContext hc) ...
I did not get the point to use three methods here. Read more inlines,
please.
I had decided to separate them because I want multiple instanceOf
checks, but will merge them.
Not a concern of mine to separate them if necessary. I thought it is
related to the following bound values issue and did not get the idea.
On 7/15/2019 4:04 PM, Anthony Scarpino wrote:
I've updated the webrev
http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/
As I need to push this by wednesday, please review it soon.
There are fixes for the comments that were made, added a NST for
boundVaules, a very basic test to make sure the post handshake NST is
sent after boundValues have changed.
Did you mean send a new NST of the boundValues is changed? What if
the previous NST was used for resumption?
Yes. It is up to the client to manage which NST it uses. If you want
some mechanism of keeping track tickets. It will have to go into 14.
Sorry for the confusing. I did not mean to keeping track to tickets.
For TLS 1.2, I think the current update does not solve the boundVaules
issue, right? I see these lines in SSLSessionImpl.java.
1363 if (protocolVersion.useTLS13PlusSpec()) {
1364 updateNST = true;
1365 }
which limit the scope to TLS 1.3+ versions only.
Why sending a new NST solves the bound values problem? I did not find
the code that restores the bound values set after the handshaking in
session resumption. The bound values are still missed if using
stateless ticket, right? I may miss something.
Xuelei
Update:
http://cr.openjdk.java.net/~ascarpino/8226338/webrev.02/
Tony
