httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apr/file_io/win32 filestat.c dir.c
Date Mon, 29 Jan 2001 19:00:58 GMT
> From: Bill Stoddard [mailto:bill@wstoddard.com]
> Sent: Monday, January 29, 2001 12:50 PM
> 
> I cannot imagine using GetSecurityInfo in a production level 
> server if this is how it performs.

You are being an Apache-head :-)  Remember that APR is for many,
many different things, including the setup phase (a one time
occurance) of Apache, the running server, support utilities
(which will need to do some security manipulation) and completely
unrelated applications.

> Just my .02... Apache really only needs to know four things about a file to
> serve pages: whether the file exists (if the running process cannot read the
> file due to security restrictions, then it doesn't exist for our purposes),
> the size of the file, when it was modified and the file type. We gotta get to
> the point where we can make apr_stat report just those things (via a flag I
> suppose).

Great idea, I should have thought of that :-)  Of course this is true,
and is already in the server.  The big question is what fields do our
modules look at (a review I'm doing now), and how do we communicate
what we retrieved to third party modules (finfo->valid.)

> Perhaps mod_dav needs more info, but hopefully the code path where
> it needs the security info is not invoked very often.

Unless the user is querying or replacing the security properties, I'm
pretty sure we can avoid some of the pain here.
 
> We also need to handle canonicalization of the filename w/o calling apr_stat
> multiple times per request.

Yes, yes, yes.  Why no canonical function yet in APR?  It was the wrong
design.  Apache will be stating each component -as needed-, as part of
the directory walk, and those platforms that have case sensitivity issues
will have to respond with the 'true name' of the file.  Not a big change
from where we are right now.

> We should not hold up the beta to 'fix' the Windows port, but we should darn
> well warn users what to expect. I have been peddling the performance
> enhancements to Apache 2.0 for Windows for at least two ApacheCon's so the
> expectations have been set; we should at least ack in the beta announcement
> that we are still experimenting with Windows and that the performance is in
> the dumper for beta 1.

Or we squeeze more vars out r->finfo and prepare module authors for 
the inevitable conclusion that we won't be telling them everything, 
and if they care, they may have to ask again for more details.

My .01$ on top of your thoughts :-)

Bill


Mime
View raw message