> Strange the way these technical mailing lists all go quiet the minute
> anyone mentions anything on topic isn't it? ;-) Wonder if I've
> offended everyone...
>
> My question was approximately if anyone knows of a place where
>
> http://www.foo.com/x/y/../z isn't the same as
> http://www.foo.com/x/z
>
> The one thing that has come up that I would like to clarify, is I mean
> real URLs in real documents. I'm aware of things like ftp sites where
> you can't directly reverse a directory change.
> but I think I have never seen such a URL. If anyone knows that they don't
> exist I'd be interested... if anyone knows where they do exist I'd also
> be really interested.
The problem is that your question in pretty much meaningless in http. The
mapping of http://www.foo.com/x/y/../z to http://www.foo.com/x/z is done
on the _client side_ 99.99+% of the time. The remaining << 0.01% is nearly
all broken clients and people manually typing URLs. Handling by servers of
the /../ case is therefore almost entirely a "fallback" mode and so there
is no point in trying to make /../ cases behave differently on a server
than as specified in the http protocal.
> If the reason everyone is being quiet is because
> they've never seen this, then I'd like to know why Tim Bray (related, I
> think to one of the search engines. I've only got a quote in another
> message handy) said in a message a while ago (see the list archives) that
> knowing the real meaning of /xxxx/./../x/../y/ is a problem.
/xxxx/./../x/../y is simply a weirdly formed request. My initial read is
that is it trying to request the 'y' object in the root directory.
To see this, iteratively evaluate the terms from left
to right (you will go crazy trying to evaluate right to left):
/xxxx/./ -> /xxxx/
/xxxx/../ -> /
/x/ -> /x/
/x/../ -> /
/y -> /y
This collapse would be performed by a _client_ virtually all the time. So
the server would only see a request for '/y' normally. There is an
order-of-operations ambiguity present that is probably what Tim Bray is
referring to when he says knowing what it really means is a problem, but I
believe most implementors use left to right evaluation in practice
(intuitive judgement from my own experience as a programmer).
With FTP, the moves up and down the tree are normally managed on
the _server_ side - which frequently allows operating system oddities
involving reversing symbolic links to leak through to the client.
With http, the '/../' and '/./' mappings are explicity specified in the
protocal as operations on the URL itself rather than state changes on
the server, and normally handled on the client side anyway - so those
oddities don't appear. While in theory a server could mis-implement '/../'
and '/./', in practice any such mis-implmentation would be be pointless
because clients don't depend on the server to perform the '/../' and
'/./' mappings.
-- Benjamin Franz