On Fri, Feb 06, 2004 at 10:37:51AM -0500, [EMAIL PROTECTED] wrote:
> 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?
That got me thinking about a "handler capabilities" set of flags,
say, r->handler_attr, which is initialized to zeroes for each request.
The first single bit capability would be for, say,
HANDLER_ATTR_VIRTUAL_PATH (as opposed to filesystem-backed).
In processing directives, SetHandler code could modify r->handler_attr
so that mod_status could set HANDLER_ATTR_VIRTUAL_PATH, after which
<Directory> and <Files> would be skipped. Hopefully it could be worked
out that <Directory> and <Files> would be handled up until the point
where the request became virtual (/directory/path/then/virtual_path)
When it comes time to run the handler hook, modules could check this
flag in the same way that they check r->handler and r->content_type
to see if they should go ahead or DECLINE. Alternatively, the 'module'
structure could be expanded to included a capabilities set and only
modules that flagged a capability would be given a chance to handle
the request. Since the default handler only handles filesystem-backed
requests, it and other filesystem-backed modules would never see the
request.
e.g. if (!(r->handler_attr & HANDLER_ATTR_VIRTUAL_PATH)
|| (foo_module->capabilities & HANDLER_ATTR_VIRTUAL_PATH))
Cheers,
Glenn
