httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: [PATCH] configurable Location block speed up
Date Mon, 09 Feb 2004 21:26:04 GMT
At 03:08 PM 2/9/2004, wrote:
>Ben Laurie wrote:
>> wrote: 
>>>>>>or Joshua's "virtual" keyword on <Location >, which I like better
the more I think about it.
>>>>>ooops... s/Joshua/André/
>>>>>but Joshua has excellent points about "virtualness" being a property of
the handler.  Yes, the server-status handler should know that it is virtual, but the handler
hook is too late to skip the directory walk.  But the mod_status maintainers (i.e. us) know
that mod_status is virtual, so maybe it could tell the core earlier somehow.  An earlier hook?
 preferably something at config time since the virtualness doesn't ever change?
>>>>Isn't this going to be horribly messy? The current system says "oi, you -
here's a URL, do you handle it?" whereas you'd need to have "oi, you, here's a pattern that
might match a URL you handle, does it?".
>>>it should be clean.  I'm thinking the module somehow communicates to the core
that all its URLs are virtual, i.e., they don't map to the filesystem no way no how not ever.
 Then we still need the
>>><Location /server-status >
>>>   SetHandler status_handler    # or whatever it is
>>>config/processing to take care of the pattern matching of the URLs, just like
today.  If both of those things line up, then we can skip the directory walk.
>>Just to be clear: is the idea that you determine the handler (without a directory
walk), then determine whether to do the directory walk from that?
>right.  The first part already happens.
>>If so, aren't there cases where the handler gets determined during the directory walk,
by .htaccess?
>certainly.  But does it make sense for a given URL to have a handler set by location walk
whose content is known to be virtual, and then have yet another handler set during directory
walk/.htaccess processing?

Absolutely not.  In fact, if it's not a file resource, there should never be any
file-based .htaccess (it's left as an exercise to the reader to picture a zip file
handler which could extract .htaccess information relevant to the zip contents,
or an .htaccess resource in a database that corresponse to other database
records :-)

>With the config above, we already determine the handler today during the location walk.
 The change I'd like to see is that if this happens and also the module declares that its
content is virtual, we skip the directory walk/.htaccess.

Right on - if the *module* is virtual it should bypass these things.

>This means you couldn't have <Directory /server-status> or its .htaccess equivalent
do anything if we have the config above, assuming such a directory actually exists and we
declared that the status handler generates virtual content.  IMO that's goodness because it
is confusing as hell to support overlapping Location and Directory blocks*.  For me, that
falls into the "unpredictable results" category even though a few of us know what it will
do today.
>* with the possible exception of <Location /> which is documented as being global.

Agreed (<Location > always wins).  What is /server-status - is it a <File >
or a <Directory > ???  Of course it's neither and flip a coin on what Apache
does with it.  (Hint, if it isn't found and the leading segments exist as
directories, then it is a file, not a directory.)


View raw message