r->handler and non-filesystem requests, mod_status

[Jeff Trawick <tr...@gmail.com>]

On Thu, Jun 24, 2010 at 9:11 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Jun 24, 2010 at 9:00 AM, Eric Covener <co...@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?