RE: remove dot segment

> I don't care, and neither does anyone else.  The purpose of the 
> algorithm
> is to create a safe and consistent result regardless of the string given
> as a reference.  It is not supposed to create good URIs out of obviously
> bogus references.  These examples were considered and rejected a year 
> ago
> because they have no applicability in practice and would needlessly
> complicate implementations.

Well, we can talk about URIs without any relation with the concrete scheme,
why not. I agree that the argument about empty segments in other URIs is
very important.

Then from the general point of view relative references of the form "..//"
are so correct as other (with the respect to the specification).
The URI can be represented as a string or as a sextuple of the scheme,
authority, path, query and fragment. The decomposition must be done before
merging paths. If we transform the URI reference and the base URI into the
target URI (as it is described in the section 5.2.2 - 5.2.4), and then
recompose components into the string (as it is described in the section
5.2.5), after reparsing we don't obtain the same components.

I we are talking about specification, it is not relevant, if those examples
appears in practice or not. I would at least expect that specification
contain a mention of this behaviour. I expect a sentence like: It is an
error, if the path of the base URI is relative and the path of the target
URI is absolute or if the authority of the target URI is undefined and the
path of the target URI begins with "//".

If we take the current specification strictly, applications conforming the
specification must always consider the result of the remove_dot_segments
function to be correct. I want to say that the assumption "recomposing
followed by parsing has the same result" is so important, that specification
should treat it.

Martin

Received on Friday, 19 November 2004 13:45:07 UTC