At 03:08 PM 2/9/2004, [EMAIL PROTECTED] wrote: >Ben Laurie wrote: >>[EMAIL PROTECTED] 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 >>></Location> >>> >>>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.) Bill
