a/./b/../c

Whether "a/./b/../c" in a path component is equivalent to
"a/c" is entirely dependent on the definition of
the URI scheme. Some schemes may define the two as
equivalent, others may not.  

The current definition of the 'http' URI scheme
(in RFC 2616) does not specify this equivalence,
although apparently popular browsers will turn
http://example.dom/a/./b/../c into
http://example.dom/a/c before sending.

Do you think it should apply to all URI schemes
that use the "generic syntax"? "rtsp:"? "ldap:"?
What about schemes that use something like
the "generic syntax" but make modifications?

Note that mailto:a/./b/../@test.com sends a message
to a/./b/../@test.com, i.e., it doesn't process
them.

I'm having trouble telling what happens without
a protocol trace with 
ftp://ftp.ietf.org/ietf/../ietf/00dec/, or
with ldap:. 

But I think it is a good idea to resist the
tendency to jump from examination of the
behavior of http URIs to assert properties
of all URIs.

Larry
-- 
http://larry.masinter.net


> > As to "." and "..", I agree with TimBL that it is violently 
> > inconsistent to restrict the special meaning of these syntaxes to 
> > the relative form of URIs.  If I am given the URI 
> > http://example.com/a/./b/../c I will always, 100% of the time, 
> > regard that as http://example.com/a/c. I have just verified that the

> > first two randomly-picked web browsers I picked in fact do this.  So

> > the assertion that this only applies to the relative form is, I 
> > assert, simply wrong and should be removed.

Received on Wednesday, 26 February 2003 00:58:12 UTC