- 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