httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn <gs-apache-...@gluelogic.com>
Subject Re: [PATCH] configurable Location block speed up
Date Fri, 06 Feb 2004 17:55:55 GMT
On Fri, Feb 06, 2004 at 10:37:51AM -0500, gregames@apache.org 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

Mime
View raw message