On 5/23/19 11:16 AM, Sean Mullan wrote:
On 5/21/19 7:24 PM, Anthony Scarpino wrote:
Hi All,
Please review the CSR for the stateless Server Side
https://bugs.openjdk.java.net/browse/JDK-8223922
Some initial comments/questions:
I think the scope should be "JDK" since you are adding new JDK-specific
system properties that users can set to change the behavior.
Sure
For previous system properties that enable extensions, we have used a
boolean property with the naming convention
"jdk.tls.client.enable<ExtensionName" (for example
"jdk.tls.client.enableStatusRequestExtension", so we should probably
stick to that convention and call it
"jdk.tls.client.enableSessionTicketExtension" (with value true/false).
In those other cases with "enable<ExtName>" are they never on by
default. I don't have a problem with renaming it for consistency. But,
when the property is enabled by default, it seems a bit funny
wording-wise to have to use "j.t.c.enableSessionTicketExtension=false"
I was wondering if you really need the jdk.tls.server.sessionCacheState
system property and if so, why the default is not "mixed". Shouldn't the
server decide to cache or not depending on whether the client sends the
SessionTicket Extension?
Thanks,
Sean
