httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabien COELHO <coe...@cri.ensmp.fr>
Subject what Apache configuration file should/could be
Date Mon, 28 Dec 1998 09:49:14 GMT

Here is a little analysis of the current status of apache configuration
stuff,  and the area for improvements I can see. And suggestions. This is
a contribution to the great thinking about version 2, but I think that
1.3.5 would be a reasonnable release target... Here I'm focussing on the
what from the user point of view, not on the how from the developper point
of view. 


I REQUIREMENTS (What is needed to configure a software such as APACHE)

 1 CONFIGURABILITY (anything that could be configured must be configurable)
 . no arbitrary inforced defaults (as 3 configuration files...)
 . csq: many settings and options, thus many keywords...
    => apache configuration WILL BE VERBOSE
    => some general utils could help in this area...

 2 MODULARITY (apache is an open software!)
 . easy addition of new modules and their configuration.
   (ok with textual confs, but what about GUI?)
 . csq: - need loose constraints (char/lex/syntax)
        - delagated parsing (to enable extensions such as perl sections...)
 . status: ok 
        - raw text configuration files.
        - backslash-continued keyword-controlled lines
        - html-like nested sections

 3 SIMPLE (easy expression of HTTP concepts)
 . integrated concepts such as VirtualHost, Directory, Location, Limit...
 . no escaping, direct expressions, usual conventions
   [e.g. <VIRTUALHOST NAME="this" PORT="80"> -> <VirtualHost this:80>]

 4 USER-FRIENDLY (some*ONE* is to configure apache)
 . textual conf ok to administrators (vi/emacs), web/gui for others...
   diversity is great!
 . the more homogeneous the better
 . the looser the better (?, for instance, case-insensitive keywords).
 . nice error messages help (location, explanations, tips...)


II CRITERIONS (to evaluate "improvements";-)
 1 compatible?
 2 simple
 3 homegenous
 4 modular
 5 user-friendly


III SUGGESTIONS
 1 publish guidelines for extensions (for simplicity, homogeneity...)
 2 provide general utils at the core level.
 3 make apache core features meet these guidelines.
 4 but provide backward compatibility (with warnings) if changes are necessary.


IV PROPOSED GUIDELINES 
 (they already +- exists. it's a recommended good practice)
 1  make everything configurable [so drop hard-wired 3-files stuff]
 2  use capitalized keywords [update "order deny require allow ..."]
 3  use html-like simple nested sections.
 4  make case insensitive what can be.
 5  use simple names/phrases for options ["deny,allow" -> "DenyThenAllow"]
 6  use default lexing (char * ap_get_keyword(...))
 7  avoid junk 
    [ "allow blabla ..." -> "AllowFrom". "<Limit ...> skipped junk here" ]
 8  avoid implicit default options...
 9  please detect inconsistencies (e.g. if "order" is specified twice, say it!)
 10 try to prefix keywords per module (SSL*, AuthDBM*...)
 11 a path can be relative to ServerRoot
 12 use "!" if you mean not, inverse...
 13 use "On/Off" if you mean +/- Yes/No Enable/Disable True/False...
 14 use standard file/string regular expressions...
 ...


VI UTILS (that may be useful)
 1  working Include
 2  some conditionnal stuff <If??? ...>, <Else>???
 3  user-controlled Error/Warning
 4  macros (to help solve verbosity issues)

 and maybe (I don't claim it must be)

 5  repetition (<Foreach $i ...>) (? 0)
 6  minimum variables (Environment? useful? 0)


V ACTIONS
 1 drop hard-wired 3 files stuff
   [compatibility: add a "apache.conf" file which is used by default,
    and which contains Include etc/httpd.conf; Include etc/srm.conf; ...]
 2 update apache core features [esp. deny allow order require ...]
 3 decide what utils are needed;-)
 4 improve internals/hooks and so (not user-visible changes)

Mime
View raw message