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

Hmmm...

TimBL has asserted the axiom:

>     rel(u, base)      and abs(u, bae)
>
>and to point out that you can use abs(rel(u, base), base) for u in all
>circumstances.
-- http://lists.w3.org/Archives/Public/uri/2003Jan/0005.html

Which I think works only if you can always use a .-normalized form of a 
hierarchical form URI.

#g
--

At 09:58 PM 2/25/03 -0800, 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. 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.

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Wednesday, 26 February 2003 10:57:29 UTC