W3C home > Mailing lists > Public > uri@w3.org > July 2007

Re: URI Reference creation

From: Sebastian Pipping <webmaster@hartwork.org>
Date: Tue, 31 Jul 2007 21:34:29 +0200
Message-ID: <46AF8EC5.20509@hartwork.org>
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

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:49 UTC