httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [STATUS] 1.3
Date Mon, 07 Jul 1997 00:24:15 GMT
Cool.  Unfortunately my run_method performance improvement patch in 1.3
makes DisableModule hard to do... something I forgot about when
re-advocating this a few minutes ago.  Disabling a handler is easier.  I
wonder if any modules would have side-effects if their other methods get
to run but their handler doesn't get to run.  They *shouldn't*, it
violates the spirit of the API, but you never know.

Dean

On Thu, 3 Jul 1997, Rodent of Unusual Size wrote:

> >From the fingers of Dean Gaudet flowed the following:
> >
> >Contrib stuff / future:
> >  
> >  * status module available from .htaccess files; Ken posted patch
> 
>     I was never terrifically happy with this, since it was incredibly
>     specific to the info and status modules.  I'm working on take 2.
> 
>     The patch I'm constructing adds a DisableHandler directive, which
>     takes a list of handler names to be made unusable at the current (and
>     subordinate) scope.  AddHandler directives (that mention the
>     disabled handlers) within the scope are made as though they didn't
>     happen, and SetHandler directives that *follow* the DisableHandler
>     reference are ignored.  SetHandler directives that apply to the
>     scope and appear *before* the DisableHandler are honoured.
> 
>     The result is as follows:
> 
>     1)  AddHandler server-status .status
>     2)  AddHandler server-info .info
>         <Location /server-info>
>     3)    SetHandler server-info
>         </Location>
>     4)  AddHandler server-info .INFO
>         <Location />
>     5)	  DisableHandler server-info
>         </Location>
>         <Location /info>
>     6)    SetHandler server-info
>         </Location>
> 
>     [1] Processed and works throughout the scope.
>     [2] Processed, but made ineffective by [5].
>     [3] Processed and works because it occurs *before* [5].
>     [4] Same as for [2].
>     [5] Turns off all handler-by-type processing for the server-info
>         handler within the scope, and causes subsequent SetHandlers for
>     	it to be ignored - likewise within the scope.
>     [6] Ignored because it follows [5] in a subordinate scope.
> 
>     This is particularly useful/important for `administrative function'
>     type modules like info and status.
> 
>     Any thoughts/comments on this approach?
> 
>     I want to do a related patch for RemoveHandler that undoes the
>     effects of AddHandler within a scope, but that'll come later.
> 
>     #ken    :-)}
> 


Mime
View raw message