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

Re: More test cases to be confirmed

From: Adam M. Costello BOGUS address, see signature <BOGUS@BOGUS.nicemice.net>
Date: Fri, 20 Feb 2004 10:47:18 +0000
To: uri@w3.org
Message-ID: <20040220104718.GB3603~@nicemice.net>

Graham Klyne <GK@ninebynine.org> wrote:

> But now that RFC2396bis explicitly allows results of base+relative
> resolution that look like relative directory paths, I think it is more
> consistent to allow leading '../' segments.

I think I may agree that keeping the leading ".." makes more sense
than dropping it.  On the other hand, anyone who puts "." or ".." in a
relative reference presumably expects it to get processed on the client,
not on the server, so I'm still a little suspicious.  In any case, the
name remove_dot_segments would be misleading if it keeps initial "..".
Maybe collapse_dot_segments?

> I didn't know about the Unix behaviour.

Me neither, until today, when I was trying to figure out what motivated
RFC-2396 to permit that behavior.  Aside from the fact that Unix does
it, it seems wrong that ../a and ../../b/c might end up at different
depths.

The one thing I have no qualms about is the statement in RFC-2396 that
'If the resulting buffer string still begins with one or more complete
path segments of "..", then the reference is considered to be in error.'

I like errors to be caught.  If it were up to me to pick one of the
three permitted behaviors to standardize, that would be it.

> Here's mine (in Haskell):

Wow, I don't think I've ever seen a language like that.  :)

AMC
http://www.nicemice.net/amc/
Received on Friday, 20 February 2004 05:47:20 UTC

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