On Thu, Jun 24, 2010 at 9:11 AM, Jeff Trawick <traw...@gmail.com> wrote: > On Thu, Jun 24, 2010 at 9:00 AM, Eric Covener <cove...@gmail.com> wrote: >>> A general capability would need to be added to the server to handle >>> this situation (e.g., restrict one/all handler adjustment from >>> .htaccess when FileInfo can be overridden, or something else >>> altogether). >> >> How about two mod_status directives: >> >> * option for "ServerStatus ON|OFF" valid in <Location> >> * a per-server option to only respond to the new flag >> >> Perhaps with differing defaults for the latter in 2.2 and 2.4 > > mod_info, mod_anything-activated-via-sethandler
hmmm, maybe the big picture isn't what I think it is... here's what I see from looking at an issue in a third-party module: * the module is activated via SetHandler * the module ought to bypass directory walk (like mod_status/mod_info in theory, though they don't implement that) * core doesn't set r->handler from SetHandler until fixups hook ** the handler setting is readily available in translate name from core's dir config, but that isn't an API somewhat related issues: * I think using mod_rewrite or some other mechanism to set r->handler to override some module that thought it was a non-filesystem-request could be broken (directory walk already bypassed) Either r->handler should be available prior to translate name && (don't-do-that if mod_rewrite/mod_foo resets r->handler to a filesystem request after directory walk was bypassed || directory walk should be triggered when needed (ha!)) or non-filesystem requests shouldn't set/look at/otherwise rely on r->handler until fixups ---/--- If the latter, then mod_status could/should be changed to use its own enablement flag instead of SetHandler for multiple reasons (bypassing dir-walk and .htaccess issues). --/-- Thoughts? Any expertise on the nuances of r->handler to be shared?