- 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>
> 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 UTC