W3C home > Mailing lists > Public > uri@w3.org > October 2001

Re: checklink:

From: Tim Bagot <tsb-w3-validator-0006@earth.li>
Date: Sat, 13 Oct 2001 18:43:09 +0000 (UTC)
To: "www-validator@w3.org" <www-validator@w3.org>
cc: <uri@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Message-ID: <Pine.LNX.4.33.0110131840020.1629-100000@windle.cipe>
At 2001-10-13T02:08+0200, Bjoern Hoehrmann wrote:-

> Hm, checklink relies on URI.pm, which actually implements RFC 1808:
>
> [...]
>    Similarly, parsers must avoid treating "." and ".." as special when
>    they are not complete components of a relative path.
>
>       /./g          = <URL:http://a/./g>
>       /../g         = <URL:http://a/../g>
> [...]
>
> Note that I may create '..' paths, thus http://www.example.org/../ may
> actually point to some other resource than http://www.example.org/ I
> can't see anything in RFC 2396 that states such URIs are invalid, I'm
> not sure if this is what I should read out of 'considered to be in
> error'. How would I then create URIs to such resources? Using %2E%2E
> wouldn't work either, would it?

Such URIs are perfectly valid; some relative URI references one might
derive from them are in error. Path segments of "." and ".." are special
only in relative path references, so abolute URIs and absolute path
references containing them would be fine. No, %2E%2E would not work, since
escaping unreserved characters does not alter the semantics.

Appendix C (Examples of Resolving Relative URI References) of RFC 2396
actually disagrees with Chapter 5 (Relative URI References), suggesting
that the correct behaviour is that of RFC 1808, but pointing out that some
implementations will instead drop those segments. Therefore the behaviour
specified by RFC 1808 is the only consistent interpretation of RFC 2396
after all, and so checklink / URI.pm should not be modified. What fun.


Tim Bagot
Received on Saturday, 13 October 2001 14:43:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:29 GMT