Hi, I wanted to start an discussion/review-process some time ago, for a description of it see the previous tries below.
The actual webrev-url is: http://cr.openjdk.java.net/~sebastian/8022748/webrev.01/ -- Sebastian On 11/07/2015 09:43 AM, Sebastian Sickelmann wrote: > Hi, > > i fixed some typing and formatting errors. Thanks to Martijn. > > Please find the updated webrev at: > > http://cr.openjdk.java.net/~sebastian/8022748/webrev.01/ > > -- Sebastian > > On 11/06/2015 04:40 AM, Sebastian Sickelmann wrote: >> Hi, >> >> i wanted to start an discussion/review-process some time ago, see >> second-try below. >> >> Is there someone who wants to discuss/review this change? >> >> Else, should i link my result as reference into the JBS? >> >> -- >> Sebastian >> >> On 10/27/2015 05:24 AM, Sebastian Sickelmann wrote: >>> Hi, >>> >>> i investigated the problem described in JDK-8022748[1] i found that >>> the parser needed to be rescued for confusion while handling relative URIs. >>> >>> A URI created through the relativize-method is schemaless and so it >>> need to handle the special-case (a colon in the path-element). While >>> there is also another way to handle it (encode the colon as %3A) i think >>> we should not choose to encode everything. First it would introduce another >>> style of special-case handling of a colon in the path (see the method >>> maybeAddLeadingDot which is used while normalizing) and when resolving >>> it back we would need to decode it back or leave it the encoded way which >>> is not suggest by RFC2396 section "1.5 URI Transcribability". >>> >>> Also in Section 5 of RFC2396 it is suggested to rescue a colon in the >>> path-element in a relative URI through prepending a "./" just like in >>> maybeAddLeadingDot. >>> >>> I am not sure if it is worth to refactor the split(),join(),normalize() >>> methods to provide a reusable colon-detection and -handling. >>> >>> So, instead of split/join/normalize please find my webrev with a >>> simpler approach at: >>> >>> http://cr.openjdk.java.net/~sebastian/8022748/webrev.00/ >>> >>> -- Sebastian >>> [1] https://bugs.openjdk.java.net/browse/JDK-8022748 >>> >