httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: mod_cern_meta.c - MetaFiles <on|off>
Date Tue, 25 Jun 1996 15:54:07 GMT
  Instead of expanding bitspace, is there a way we can make "Options" sort
  of a meta-config-directive directive?

Hmmm... when I've been talking about dynamic assignments of names to bits,
I've been *meaning* to talk mostly about AllowOverride, which really does
need to be done that way, as far as I can tell, thought this probably
wasn't clear at all from the text ;-).

As to Options... Brian's right --- the main reason this exists at all
is for back-compatibility with the old NCSA server.  Unfortunately, as
a way of adding *new* stuff, it has several disadvantages:

1) You can't put different Options under control of different 
   AllowOverride bits.

2) You can't change the state of one Option in, say, a .htaccess file,
   without having to explicitly reset the state of all the others; there's
   no way to explicitly say "I want site-wide defaults except for *this*".

3) If a config file anyplace says "Options All" or "Options None", that
   will effect the new option bit in ways that are almost certainly
   unintended, and perhaps inappropriate.  This is why I left MultiViews
   out of Options All ages ago (in Apache 0.6.x, pre-Shambhala) --- but
   a proliferation of quirks like that can only promote confusion, and
   it still leaves potential perniciousness in Options None.

Unfortunately, I can't see a way to fix (2) and (3) and still stay
compatible --- and compatibility is the only reason to support the
Options command in the first place.  (BTW, note that none of these
objections applies particularly much to AllowOverride, as currently
used --- particularly since it isn't currently allowed in .htaccess
files at all).

So, my personal preference would be that new functionality is defined
in terms of explicit flag commands (e.g., "MetaFiles On", or whatever
Andy called it), that we create a way for modules to request new
AllowOverride bits (ideally at 'Configure' time, but at runtime init
would be OK), and that we leave Options basically the way it is.

If people are offended by the nonuniformity of this (I am --- Options
has been a wart on this thing from the start), we could try to move to
doing the existing Options as flag-commands as well --- for instance,
by defining a new command in some appropriate module for each existing
Option, and using the value set in Options only as a default if the
flag-command is unset.  (Having done this, we could declare "Options"
as deprecated, and drop it in a future release).

Anyway, those are my random thoughts... subject to future modification
as and when I'm caffeinated enough to think straight.

rst

Mime
View raw message