httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: cvs commit: apache/src CHANGES conf.h http_main.c mod_cgi.c mod_userdir.c
Date Mon, 18 Mar 1996 09:51:57 GMT
Alexei Kosut wrote:
> 
> On Sun, 17 Mar 1996, Jim Jagielski wrote:
> 
> >                         If we hit the end of the UserDir list, and we
> >                         haven't  found a file, return NOT_FOUND; we were
> >                         returning OK before  with junk in the r->filename
> >                         slot
> 
> No! Absolutely not. This is unacceptable. There's a reason I did it the 
> way I did it, and it's important:
> 
> UserDir /foo/script.cgi
> 
> This should work. I use it personally. It needs to work. But if I call
> /~bob, the file /foo/script.cgi/bob does not exist. So I made it so the
> last entry returns OK no matter what, so this will work. If the file turns
> out not to exist, Apache will catch it later. I tested this thouroughly
> when I made the patch.

The you never bothereed to checked the error_logs because your patch
returns garbage in the r->filename slot.
> 
> And, at any rate, returning NOT_FOUND is the incorrect approach. You
> should return DECLINED, because another module may want to serve that
> request. (and it isn't necessary anyhow, because after the while loop -
> which is keyed on the userdir list - ends, it will return DECLINED).

But aren't you testing on whether userdirs is NULL, and if it is,
then you assume the file _will be found_ and so return OK?

    if (!*userdirs || stat(filename, &r->finfo) != -1) {

This seems incredibly wrong to me, esp when 'filename' can be garbage.
It really seems to me that if we reach the end of the list, and nothing
has been found, then something other than OK should be returned. 
Especially when we know that the file couldn't be 'stat'...

With the original version of code, if UserDir is 'public_html' and
someone enters the URL '/~bob' and 'bob' doesn't exists, then OK is
returned with r->filename being garbage... this then ends up in error_log
which is wrong.

Why, exactly, do we want to return OK when we can't even stat filename?
-- 
Jim Jagielski  << jim@jaguNET.com >>   |      "That's a Smith & Wesson,
  **  jaguNET Access Services  **      |       and you've had your six" 
      Email: info@jaguNET.com          |             - James Bond
++    http://www.jaguNET.com/         +++      Voice/Fax: 410-931-7060       ++

Mime
View raw message