RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

[Chris Hegarty]

Sean,

> On 20 Jul 2018, at 18:07, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 7/20/18 11:08 AM, Chris Hegarty wrote:
>> This is ambiguous, and needs to be clarified. Surely, it is
>> better to use the same wording as the serial filter:
>>  "Whitespace is significant and is considered part of the value."
> 
> Kind of on the fence on that one. If this were a general property/value format, I would agree, but these values are fixed and not potentially complicated expressions.

Sure, they are simple strings consisting of only printable characters.

> For example, does this mean:
> 
> jdk.includeInExceptions=hostInfo,jarInfo
> 
> and
> 
> jdk.includeInExceptions=hostInfo, jarInfo
> 
> are different? And I assume the latter " jarInfo" would be ignored?
> 
> If you are strongly in favor of this, I would highly recommend logging a warning when there is an unknown value, otherwise typos and such would be hard to detect (although this doesn't necessarily need to be in the specification).

My original whitespace handling avoided the potential issue where a 
rogue lead or trailing whitespace accidentally found its way into a
value, therefore avoiding the scenario above ( and potentially emitting
a warning ).

Whitespace is significant and should be specified as such, since ...
  
  jdk.includeInExceptions=“host   Info” 
    IS NOT equal to
  jdk.includeInExceptions=“hostInfo”
    and system property values can contain spaces
  jdk.includeInExceptions=“foo bar,hostInfo,jar Info,” 

After given this some more thought, I now think that I gave in to the
comment to change whitespace handing too easy. While maybe not
consistent, with the already inconsistent, whitespace handling in
java.security, I think ( for this particular case ) the original - trim
leading and trailing - is the right thing to do. It avoids your above
scenario where someone accidentally adds a leading space, which could be
difficult to debug/find without a warning - which we should avoid if
possible.

I’d like to re-propose the original webrev for consideration ( whitespace
handling is the only change ):

  http://cr.openjdk.java.net/~chegar/8207846/webrev.00/


-Chris.