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


From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Thu, 30 Oct 2003 22:12:45 +0100
To: w3c-rdfcore-wg@w3.org
Message-Id: <200310302212.45454.jjc@hpl.hp.com>

I've looked through 2396bis


It seems to be as the commentator said - there is a change and .. are 
systematically eliminate during URI resolution.

In the change log:

Separated the path merge routine into two routines: merge, for describing 
combination of the base URI path with a relative-path reference, and 
remove_dot_segments, for describing how to remove the special "." and ".." 
segments from a composed path. The remove_dot_segments algorithm is now 
applied to all URI reference paths in order to match common implementations 
and improve the normalization of URIs in practice. This change only impacts 
the parsing of abnormal references and same-scheme references wherein the 
base URI has a non-hierarchical path. 

The most relevant bit of the text is:
5.2  Obtaining the Referenced URI 

6. All prefixes of "<segment>/../" in the buffer, where ".." and <segment> are 
complete path segments, are iteratively replaced with "/" in order from left 
to right until no matching pattern remains. If the buffer ends with 
"<segment>/..", that is also replaced with "/". Note that <segment> may be 
particularly the last sentence.

I would be happy with any of the possible solutions here:

A) remove the test and make no comment on this
B) support the test as in my msg, modifying the comment
C) change the test to an illegal test case, justified on quote from RFC 2396
If the resulting buffer string still begins with one or more
         complete path segments of "..", then the reference is
         considered to be in error.
D) change the test to the 2396bis pattern, justifying it with the following 
text from 2396
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.

I suspect (A) is the right course - if anyone uses this they don't get 
interoperability - their problem.


Received on Thursday, 30 October 2003 16:16:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:08 UTC