Re: partial URLs ? (was

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

It's a potential security risk on *SOME* systems. Works fine on mine.
You're quite welcome to fetch <URL:>,
which will get index.html from the directory ".." in my public html

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


Received on Wednesday, 20 December 1995 09:07:44 UTC