I think there are two issues that are getting confused here:
(1) whether it's OK to use ../../ in an HREF or SRC attribute
in an HTML document,
(2) whether it's OK to _send_ ../../ in the path field of
and HTTP request.
(1) is cool, (2) is not.
For example, if the example above was fetched from http://www.foo.com/a/b/c.html,
then to fetch the [Home] image, the client must combine the value of the HREF
attribute with the base URL as per RFC1808, yielding:
http://www.foo.com/a/gifs/btnhome3.gif
To access the resource at that address, it makes a TCP connection to port 80
of www.foo.com, and sends:
GET /a/gifs/btnhome3.gif HTTP/1.0
Accept: image/*
What's _not_ cool is to try to sidestep the processing of .. on the client side;
that is, to just combine the base and HREF into:
http://www.foo.com/a/b/../gifs/btnhome3.gifs
(which is _not_ a well-formed HTTP url) and send:
GET /a/b/../gifs/btnhome3.gif HTTP/1.0
This is illegal because it is a potential secruity risk. Consider a server
whose document root is /usr/local/etc/httpd/docs/ and a client who sends:
GET /../../../../etc/passwd HTTP/1.0
Accept: text/plain
a naive server implementation might just do:
fopen("/usr/local/etc/httpd/docs//../../../../etc/passwd")
and give away a bunch of sensitive info.
In stead, any server that sees /../ in the HTTP path is supposed to
issue a 403 Unauthorized response. (Is this in the HTTP specs somewhere?
YIKES! I can't find it in draft-ietf-http-v10-spec-02.txt!!!
HTTP-WG folks: this should be addressed in the HTTP 1.0 spec, no?
Dan
