It's a potential security risk on *SOME* systems. Works fine on mine.
You're quite welcome to fetch <URL:http://www.phone.net/home/mwm/../>,
which will get index.html from the directory ".." in my public html
directory.
> 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?
No. A server should be allowed to issue "403 Unauthorized" (or "404
Not Found") for any URL that the server considers insecure. On Unix
systems, I'd certainly consider "/../" to be such a string. On other
systems, another syntax (for instace "//") might be used for that end,
and the server is perfectly justified in rejecting any request
containing that string.
Yes, having ".." (or "") as a path component creates interesting
problems in writing relative URLs, and is probably a bad idea on any
server. Yes, an attempt to access "../../../../etc/passwd" is probably
someone trying to break into the system. However, it's up to the
people running the server, not the spec, to decide what is and is not
a security problem and deal with them. Unless some request can be
shown to create problems independent of the underlying platform, the
spec should not make any request illegal.
<mike