Re: partial URLs ? (was <p> ... </p>)

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