You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Fabien COELHO <co...@cri.ensmp.fr> on 1998/12/28 10:49:14 UTC
what Apache configuration file should/could be
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)
Re: what Apache configuration file should/could be
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Mon, 28 Dec 1998, Fabien COELHO wrote:
> 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.
Out of curiosity... I recall that back in July, someone said they were
going to be looking into XML as a configuration language for Apache. Did
anything ever happen with that? It certainly seems to me that these sorts
of problems have been solved before. It seems somehow wasteful to solve
them again.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: what Apache configuration file should/could be
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> > . csq: - need loose constraints (char/lex/syntax)
> > - delagated parsing (to enable extensions such as perl sections...)
>
> Yeah this is something I've babbled about. XML gives us this, no? We can
> do arbitrary "quoting" of sections and delegate who parses them...
Hmm. We could even let modules extend the DTD. That would be cool. It
would mean we'd have to build the DTD on the fly, though. You then parse
everything in one place, but dole out the parsed stuff to the
appropriate modules. That could be very cool.
> > . 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>]
>
> I'm not particularly attached to any of the current syntax. It does
> absolutely nothing for me. It pretends to look like HTML, but last I
> looked at HTML, something like <virtualhost foo>blah</virtualhost> is
> valid, but not in apache's language. I consider the "one command per
> line" crap to be crap.
Valid in XML, of course. Agree about the crap.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: what Apache configuration file should/could be
Posted by Dean Gaudet <dg...@arctic.org>.
another old message...
On Mon, 28 Dec 1998, Fabien COELHO wrote:
> 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.
We'd never introduce a major configuration language change in a minor rev.
> 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...)
Yup.
> . csq: many settings and options, thus many keywords...
> => apache configuration WILL BE VERBOSE
What do you mean by 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?)
GUIs can talk the text config language. We're never getting rid of the
text language.
> . csq: - need loose constraints (char/lex/syntax)
> - delagated parsing (to enable extensions such as perl sections...)
Yeah this is something I've babbled about. XML gives us this, no? We can
do arbitrary "quoting" of sections and delegate who parses them...
> . 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>]
I'm not particularly attached to any of the current syntax. It does
absolutely nothing for me. It pretends to look like HTML, but last I
looked at HTML, something like <virtualhost foo>blah</virtualhost> is
valid, but not in apache's language. I consider the "one command per
line" crap to be crap.
> 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
Yes, this is the most important point.
> . 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"]
Yup, we should lose the NCSA compatibility and go for something sane.
Someone can write a perl script to translate NCSA/old-apache configs to
new configs.
> 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)
>