- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Thu, 30 Oct 2003 22:12:45 +0100
- To: w3c-rdfcore-wg@w3.org
I've looked through 2396bis http://gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html 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 empty. ]] 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 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Oct/0171.html 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. Jeremy
Received on Thursday, 30 October 2003 16:16:03 UTC