W3C home > Mailing lists > Public > uri@w3.org > February 2003

Re: a/./b/../c

From: Dan Connolly <connolly@w3.org>
Date: Wed, 26 Feb 2003 08:52:41 -0600
To: Larry Masinter <LMM@acm.org>
Cc: uri@w3.org, "'Williams, Stuart'" <skw@hplb.hpl.hp.com>, "'Tim Bray'" <tbray@textuality.com>
Message-id: <1046271160.2417.98.camel@dirk.dm93.org>

On Tue, 2003-02-25 at 23:58, Larry Masinter wrote:
> Whether "a/./b/../c" in a path component is equivalent to
> "a/c" is entirely dependent on the definition of
> the URI scheme.

No, it's not. The algorithm for expanding
a URI reference to absolute form w.r.t. a
base is scheme-independent, as is
  x + (y-x) = y

So http://example.dom/a/./b/../c isn't
a URI, if you ask me. Nor is

. and .. are only allowed as path segments
in URI references, not in (absolute) URIs.

>  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?

Schemes can refine the generic syntax, but
they can't change it.

> Note that mailto:a/./b/../@test.com sends a message
> to a/./b/../@test.com,

well, it identifies that mailbox, anyway.

>  i.e., it doesn't process
> them.

URIs don't process anything.

> 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.

The / in URI syntax is there to provide
a scheme-independent syntax for hierarchy.

> Larry
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 26 February 2003 09:52:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC