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