httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: [STATUS] 1.3
Date Mon, 07 Jul 1997 00:05:01 GMT
At 09:10 PM 7/3/97 -0400, 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.

Philosophically, I'm not comfortable with the idea of one directive
specifically for disabling another.  Let's say Alexei proposes HandlerMatch
- do we keep up and propose DisableHandlerMatch?  

We already have a method for controlling access to directives, and that's
using the groups as controlled by an "AllowOverride" directive.  Right now
to prevent the problem one could say "AllowOverride None" or any
replacement for "None" except for "FileInfo".  However users then wouldn't
be able to add new MIME types or error documents, most noticeably.  

If what we're saying is that the "status" functionality shouldn't be
grouped with the others in FileInfo, then we have a problem with a
directive which goes beyond its original purpose.  One option is to have
the status module triggered not by a file type handler (which has always
confused me) but instead a directive unique for the status page, i.e.
"ShowStatus".  That directive can
be separately scoped.

Of course that would break backwards compatibility, and we might want to
save breaking things like that for 2.0.  

Perhaps another option - can the status module check to see where it was
triggered from?  And only allow it to be set in the server resource files?


"Why not?" - TL       - -

View raw message