From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 10:54 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.
> >
> > 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.)
> 
> So tell us how you -really- feel :-)

Let me fine-tune my statement.  Modules that use quick_handler bypass the _user's_ 
expectations,
and our documented behavior.  If this is ok for a given module, and is well 
documented, then fine.

I feel that nothing frustrates me more, personally, than to follow docs and observe a 
different
result than was doumented.  That's why I turned Greg to the <Location >/<Limit > 
combinations
for DAV, since they have odd side-effects.  

> I am looking at the map_to_storage hook to see how it works. Stay tuned.  The
> quick_handler hook was named after (and is used by) Mike Abbott's quick cache, an 
>-Apache-
> module. It is a specialized hook to serve a specialized purpose: serving web pages 
>as fast
> as possible from a user space resident cache. And it can be used without 
>compromising the
> security of the server.

The best example is loading the mod_proxy/proxy_http combination.  I have to say that 
the patch
to mod_proxy was about as clear as I've ever written.  It will give you a terrific 
feel for what 
can be done :)

>From an optimization perspective, see the <Location > patch from last night, it shows 
>what you
can do with pre-cached per_dir_config's, you would just need to use config wide pools 
and voila,
mod_file_cache can have preconstructed per_dir_configs too.  I'll be modifying 
<Directory > to
also observe any preconstruction, so all internal_internal_redirect and subreq 
entities can go
back through directory_walk without consuming significant CPU.

Bill

Reply via email to