Relative URLs -- addendum

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.

Received on Monday, 27 January 1997 13:58:07 UTC