Re: URI Reference creation

Sebastian Pipping wrote:
> I had a first closer look at the test suite and stumbled upon four
> testcases that suprised me. They belong to normalization testing.
> Why are these four URIs expected not to be changed by normalization?
> 
> 'example://A/b/c/%7bfoo%7d' --> 'example://A/b/c/%7bfoo%7d'

Per RFC 3986 sec. 6.2.2.2, normalization of percent-encoding is achieved by 
decoding those percent-encoded octets that correspond to unreserved 
characters. %7b and %7d correspond to "{" and "}" which are reserved 
characters.

>   'a/b/../../c' --> 'a/b/../../c'
>   'a/b/././c' --> 'a/b/././c'
>   'a/b/../c/././d' --> 'a/b/../c/././d'

Per RFC 3986 sec. 6.2.2.3, normalization of dot segments in relative paths 
(such as these) occurs during the URI reference resolution process. Only dot 
segments in absolute paths would need to be normalized outside of that 
process.

> > We also do some special-casing to make sure the [Relativize] algorithm 
> > isn't tripped up by empty path segments.
> 
> Doesn't that change the "content" of URI?

I'm not sure what you mean.

I know one concern is that you don't want to ever have an empty path segment 
result in a reference that starts with "//" because the next segment in the 
reference would be interpreted as an authority component. A leading "." in the 
reference protects against that.

I think other concerns were implementation details related to comparing 
empty segments in the source and target URI. I'd have to get the author to
explain it further.

> Maybe it is used in a context where empty path segments must not be
> stripped. Can that happen?

Yes it can happen... the idea of the function is to provide a relative 
reference that will work for *any* source and target URI combo.

The test cases for Relativize() don't cover the possibility of both the 
original and target URIs having empty segments. I don't know if our algorithm
will handle that.

I'll see if the author is available to comment further, and I'll get back to 
you about licensing.

Received on Monday, 30 July 2007 20:45:48 UTC