httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: cvs commit: httpd-2.0/server core.c request.c
Date Mon, 27 Aug 2001 15:04:22 GMT
From: "Ryan Bloom" <>
Sent: Monday, August 27, 2001 8:41 AM

> > map_to_storage is definitely not the same as quick_handler. But
> > quick_handler does have a use so it stays in.
> Actually, they are closer than you might think.  quick_handler's purpose is to allow
> requests to be served as quickly as possible.  It skips a lot of phases of the
> request to accomplish that.  If map_to_storage is tweaked a bit, it can accomplish
> the same thing.

It's not going to be tweaked (you security sloths, you :)  We need to look at each of
the hook phases, and figure out how a module can selectively bypass that hook, when
it should, and why.  I'll probably start a paper detailing how the current Apache system
exposes hooks, and what's the harm in using/bypassing those hooks.

Quick_handler bypasses everything.  We ignore the client's headers, the server's 
configuration, everything.  Frankly, quick_handler is not Apache, and anyone who writes 
a quick_handler hack and calls it a module for 'Apache' is full of sh*t.  Powered by the 
Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.)

> Basically, the map_to_storage function that succeeds would tell the server how many
> of the hooks that follow map_to_storage that it should skip before the handler phase.

No... I thought long and hard about that, and I dislike it.  It's full of opportunities
to mess up security and bypass things you didn't expect (in v. 2.1 or whenever.)

hook_to_storage (named wrong, we agree) is the trap to walk a set of dir_config's that are
customized for the module.  50% of the modules serve files, so they _don't_ hook this call.

40% of the modules invent content in a "yes or no" sort of way.  They are generally driven
by the <Location > block, so that block can contain their access restrictions.  They
want us to hook up any extra dir_config's, so they may hook this call and just return OK.

10% of the modules (e.g. proxy, perhaps a database-driven content store) don't have 'files'
in the traditional sense, but they want a tree mapping of restrictions, and it won't
correspond to our <Directory ><Files > sections in a 1:1 manner.  For those modules,
can hook and replace dir_walk/file_walk with their own (e.g. proxy_walk.)

> This has a couple of advantages over quick_handler, the first one being that it
> is more general, and the second that it means we go back to having one location that
> data is sent to the network.

Yes - it's definately a design decision that an author needs to be aware of.  We aren't
working well enough with too many modules as it is (take mod_autoindex/negotation/mime
security reports, or tomcat security reports.)  We don't want module authors to suffer
from a slow model.  But we don't want them wandering too far out of the fold, until they
fall in the pit that so many modules have landed in.

> If that change is made to map_to_storage, then I would be with OtherBill, and
> suggest that quick_handler should be removed.

I'm about to suggest that as well, but I don't think we can do so until we optimize our
whole server.

That is, I just optimized the two-pass <Location > parsing.  Unless the URI is remapped
(a significant context change that requires rewalking the location), or we have been mapped
to a virtual server with a different set of locations (they probably wern't inherited from
the base server), then we will do zero or one directory merges.  Zero merges if no module
modified the per_dir_config since we left it (no dir/file/proxy walk), or one merge if we
see someone reset per_dir_config, so we will overlay it.

Almost every hook can be a bit more optimized this way.  I'm most concerned about subreq
and internal redirect mechansims, and will continue to work to assure 1. they do the same
thing, even in different contexts, and 2. they rely on the original request as much as
possible to drop cpu/filesystem load.

An example ... dir_walk can do the same thing as location_walk does.  If we already walked
the first 3 directory elements, and come back with a subreq for a subdir, why duplicate the
work?  We have some great opportunities here for cleaner, smaller and faster code.  Then
I'll suggest dropping quick_handler, and have a document to back up my position :)


View raw message