Message-Id: <email@example.com> Date: Mon, 27 Jan 1997 13:58:35 -0500 To: Daniel LaLiberte <firstname.lastname@example.org> From: Tim Berners-Lee <email@example.com> Subject: Relative URLs -- addendum Cc: firstname.lastname@example.org Dan, Following on from my last message, You asked about relative URLs and // and the original intent. The parsing rules from RFC1630 (which has an error in the examples I'm afraid) allows and number of slashes, giving special significance to /// for example. This is much more powerful than the current draft has, and much preferable. ((This means that you should never write file:///c:apps but file:/c:/apps as a void path cannot (in any element) be tolerated by the syntax. Of course people *do* write /// but the clean thing to do and the consistent ting to do it to leave it for extension.)) Tim Rules from RFC1630: If the scheme parts are different, the whole absolute URI must be given. Otherwise, the scheme is omitted, and: If the partial URI starts with a non-zero number of consecutive slashes, then everything from the context URI up to (but not including) the first occurrence of exactly the same number of consecutive slashes which has no greater number of consecutive slashes anywhere to the right of it is taken to be the same and so prepended to the partial URL to form the full URL. Otherwise: The last part of the path of the context URI (anything following the rightmost slash) is removed, and the given partial URI appended in its place, and then: Within the result, all occurrences of "xxx/../" or "/." are recursively removed, where xxx, ".." and "." are complete path elements.