httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@ast.cam.ac.uk (David Robinson)
Subject Re: New version of B60-leading-slash-2.txt for 0.5.1
Date Wed, 12 Apr 1995 12:49:00 GMT
Roy wrote:
> > The current situation:
> > So the URL spec does not mandate any specific action in response to
> > GET /path/../path2/file.html. We can do whatever we want. However, I think
> > we would be insane not to map this onto /path2/file.html
>
> Ummm, either way is okay; I personally am in favor of rejecting invalid
> URLs in the most painful way possible (to the user), so that they won't
> continue using them.  "PR" is not a problem where I work. ;-)
> Note, however, that if a CGI script controls that part of the resource
> name mapping, you cannot safely (and should not) change the path.
> I can't remember what needs to be done for PATH_TRANSLATED.

I'm not sure I agree. I had already thought about this, and the conclusion
I had come to was:
 if the server defines ../ to remove the previous path element, then it
 would be too confusing not to do this in all circumstances. Consider
 /dir/file.html/../file2.html     -> /dir/file.html
 But what about
 /dir/script.cgi/patharg/../file2.html
 Currently, script.cgi gets a PATH_INFO of /file2.html.
 It _could_ be given /patharg/../file2.html but I would argue that in the
 context of the behaviour of httpd, it would be wrong for the script to
 treat this as anything but /file2.html
 And what about
 /dir/script.cgi/../file2.html
 Is this the file /dir/file2.html or the script /dir/script.cgi with
 PATH_INFO=/../file2.html ??
I'm not sure what the best solution is.

> > My question (actually just an comment):
> > What should we do with http://host/../path/file.html, i.e. a
> > GET /../file.html ? Currently httpd will map this to /file.html. I was
> > suggesting that this is wrong, and that this should return 400 or 404.
>
> 404 Not Found -- there is nothing wrong with the request itself
> (other than there does not exist any resource starting with "/../").
> Same goes for "/./" and "//", though these ones are more innocuous.

Yes. /./ is removed. 

 David.

Mime
View raw message