- From: Sebastian Pipping <webmaster@hartwork.org>
- Date: Tue, 31 Jul 2007 21:34:29 +0200
- To: Mike Brown <mike@skew.org>
- CC: uri@w3.org
Mike Brown wrote:
>> '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.
---------------------------------------------------------------
Yes, but shouldn't the host "A" become lowercase and "%7b" and
"%7d" become uppercase?
---------------------------------------------------------------
>> '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.
---------------------------------------------------------------
I see, will have to fix that for uriparser.
---------------------------------------------------------------
>>> 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 meant that maybe "a/b///c" and "a/b/c" are different
for some applications and therefore fixing it would
not work for them.
Sebastian
Received on Tuesday, 31 July 2007 19:40:41 UTC