Hi Roger!
On 1/10/19 8:04 AM, Roger Riggs wrote:
Hi,
If we're going to break some apps that use non-conforming strings,
perhaps we should go fully strict and make sure they are all fixed at
the same time.
(Unless we have some stats on the distribution of non-conforming apps
that mitigates that).
That's my point: While going fully strict may break some applications
out there, rejecting only obviously incorrect input will likely affect
only those applications with a bug.
It can be thought as a first step toward full conformance to the RFC.
For now, reject only the most incorrect inputs, and leave the final
step, if desired, to JDK-8165199
<https://bugs.openjdk.java.net/browse/JDK-8165199>.
With kind regards,
Ivan
Roger
On 01/10/2019 02:27 AM, Ivan Gerasimov wrote:
Hi Joe!
From what I see, the discussion was about possibility to only accept
input strings with precisely sized parts, i.e. that matches
"\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}-
\p{XDigit}{12}".
And I'm proposing to only reject input with too large individual
parts, i.e. accept any input that matches
" \p{XDigit}{1,8}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- \p{XDigit}{1,4}-
\p{XDigit}{1,12}".
Currently, if one part is too large, we already "clip" it, using only
lower bits, so behavior looks buggy.
Instead, it seems better to report the issue throwing an exception.
With kind regards,
Ivan
On 1/9/19 11:08 PM, Joe Darcy wrote:
Hi Ivan,
How does this bug relate to the recent discussion of "JDK-8165199:
UUID.fromString(str) compliance checking?":
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html
Cheers,
-Joe
On 1/9/2019 3:23 PM, Ivan Gerasimov wrote:
Hello!
String representation of UUID should conform to RFC4122
<https://tools.ietf.org/html/rfc4122>, i.e. each its part has to be
of the fixed size.
Unfortunately, the UUID.fromString() method does not keep up to
this requirement:
- First, it permits the leading zeroes of any part to be omitted;
- Second, it permits some of the UUID parts to be larger then
allowed. In such a case, the value is effectively clipped with &
0x..FFFF.
While some existing application may depend on the former case --
i.e. be able to parse UUID with stripped leading zeroes, the later
case is likely to be an error.
In the past, the check on the input has already been strengthened
with JDK-8006627 <https://bugs.openjdk.java.net/browse/JDK-8006627>.
I propose we go further and make UUID.fromString() to reject such
string representations that contain too large individual parts.
If people agree on the proposal, I'll file CSR to fix the change of
behavior.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407
WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
