- From: <tritan@agora.com>
- Date: Wed, 20 Dec 1995 15:24:26 -0500
- To: BearHeart@bearnet.com
- Cc: connolly@beach.w3.org, www-html@w3.org
| >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!!! | | I have a copy of ...spec-04 and it's not in there either. But, | you're right it should be. (and 403 is "Forbidden" which is where | this ought to fall.) Why should that have to be in the spec? A server can legally say that you are forbidden to view any file it so chooses based on any criteria it want to, no? (eg. who you are, what you requested, time of day, phase of the moon...) Therefore it is already reasonable for a server to refuse to serve you /../../etc/password. On the other hand, if I *want* to let you look at my entire disk, including /etc/password, I should be allowed to write a server that does so, no? My point is that the spec should be minimalist in telling me what I should let users do. On the other other hand, a request for /../ is a bit wierd, because it's not clear that you are supposed to be able to do that; it's more like asking for something the server might misinterpret. That is, you're assuming that URLs on a server map somehow to the filesystem and that there is something above the document root, neither of which is really necessarily true. Perhaps it makes more sense to return an "I don't know what you want (invalid request)" type error code rather than "Forbidden" which implies that I know what you want, but you aren't allowed to look there. -Fred tritan@agora.com
Received on Wednesday, 20 December 1995 15:24:35 UTC