W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2003

RE: test xmlbase/test012

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 30 Oct 2003 13:42:29 +0100
To: "Brian McBride" <bwm@hplb.hpl.hp.com>, "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: <w3c-rdfcore-wg@w3.org>
Message-ID: <BHEGLCKMOHGLGNOKPGHDOEDCCCAA.jjc@hpl.hp.com>


> I probably have my facts wrong - I haven't checked the documents:
>
> There are two possible behaviours:
>
> a) leave extra ".."'s in the path
> b) delete extra ".."'s.
>
> a is legal in 2396 and not in 2396bis
> b is legal in 2396 (but not recommended) and in 2396bis
>
> You are recommending we fix on a?
>
> Brian
>

My earlier understanding was that b was not legal but tolerated in RFC 2396.

Unfortunately, I had misread RFC 2396 - I just reviewed it ...

It seems that my understanding was correct except that a is not legal
either, but tolerated to a greater extent. Hence the pedant in me suggests
the test should in fact be an illegal document.

I'll have a look at 2396bis - to see if that helps.


On this topic - the section I had read said:

[[
C.2.  Abnormal Examples

   Although the following abnormal examples are unlikely to occur in
   normal practice, all URI parsers should be capable of resolving them
   consistently.  Each example uses the same base as above.

   An empty reference refers to the start of the current document.

      <>            =  (current document)

   Parsers must be careful in handling the case where there are more
   relative path ".." segments than there are hierarchical levels in the
   base URI's path.  Note that the ".." syntax cannot be used to change
   the authority component of a URI.




Berners-Lee, et. al.        Standards Track                    [Page 30]

RFC 2396                   URI Generic Syntax                August 1998


      ../../../g    =  http://a/../g
      ../../../../g =  http://a/../../g

   In practice, some implementations strip leading relative symbolic
   elements (".", "..") after applying a relative URI calculation, based
   on the theory that compensating for obvious author errors is better
   than allowing the request to fail.  Thus, the above two references
   will be interpreted as "http://a/g" by some implementations.
]]

with the earlier paragraphs suggesting the behaviour of retaining the .. is
recommended and the behaviour of stripping the .. is implementation
variation.

However, in the main body it says:

[[
5.2. Resolving Relative References to Absolute Form

...

      g) If the resulting buffer string still begins with one or more
         complete path segments of "..", then the reference is
         considered to be in error.  Implementations may handle this
         error by retaining these components in the resolved path (i.e.,
         treating them as part of the final URI), by removing them from
         the resolved path (i.e., discarding relative levels above the
         root), or by avoiding traversal of the reference.

]]

which suggests that the normative behaviour is to barf.
Received on Thursday, 30 October 2003 07:43:31 EST

This archive was generated by hypermail pre-2.1.9 : Thursday, 30 October 2003 07:43:35 EST