Return-Path: 
 <dev-return-41020-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: (qmail 39327 invoked from network); 6 Feb 2004 22:11:01 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 6 Feb 2004 22:11:01 -0000
Received: (qmail 57537 invoked by uid 500); 6 Feb 2004 22:10:41 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 57473 invoked by uid 500); 6 Feb 2004 22:10:39 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
list-post: <mailto:dev@httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 57451 invoked from network); 6 Feb 2004 22:10:39 -0000
Received: from unknown (HELO Boron.MeepZor.Com) (204.146.167.214)
  by daedalus.apache.org with SMTP; 6 Feb 2004 22:10:39 -0000
Received: from apache.org (dmz-firewall [206.199.198.4])
	by Boron.MeepZor.Com (8.11.6/8.11.6) with ESMTP id i16MAjd09113
	for <dev@httpd.apache.org>; Fri, 6 Feb 2004 17:10:45 -0500
Message-ID: <4024107F.4020909@apache.org>
Date: Fri, 06 Feb 2004 17:09:03 -0500
From: Greg Ames <gregames@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701
X-Accept-Language: en
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [PATCH] configurable Location block speed up
References: <4021669F.1060904@apache.org> <40226E22.80005@modperlcookbook.org>
 <4023B0F6.10505@apache.org> <4023B4CF.2040808@apache.org>
 <20040206175555.GA9304@netspace.org>
In-Reply-To: <20040206175555.GA9304@netspace.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Glenn wrote:
> 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).

something like that.  I don't know if there are other uses for handler 
capabilities so it might be overkill at the moment.

> In processing directives, SetHandler code could modify r->handler_attr

a nit - I think we would want to hide this type of info in something private to 
the core, like the core_request_config.

> 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)

I'm still thinking of an all-or-nothing approach, i.e. it's in the filesystem or 
it's not, at least at first.  That's a pretty big change - look at the comments 
I'm getting and the cases I missed.

> 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
> 
> 
f