httpd-dev mailing list archives

This is just bare-bones, but I wanted it out there so that my concerns
about performance are at least addressed. I'm not addressing
compatibility concerns here, I lean towards a complete config revamp with
a perl conversion script. My primary goal is to decrease ambiguity, and
confusion about the current vhost configuration, and to allow for easy
optimization of the matching process.
Observe that it's possible to merge server configs, so it is possible to
nest "server config" blocks.
Define a hierarchy:
<PortMatch PP ...>
...
<IPMatch a.b.c.d ...>
...
<HostMatch ... ...>
...
</HostMatch>
...
</IPMatch>
...
<PortMatch>
Each of those can be repeated an arbitrary number of times within their
nesting. All "server config" directives can appear anywhere and apply to
everything at that point or lower in the nesting.
Any wildcard * has lower precedence than an exact match.
Within an ipmatch block, hostmatches define name-based vhosts that work on
that set of ips only. HostMatch itself is optional, so that it's possible
to define an ip-based vhost using ipmatch only.
It's possible that PortMatch could be made optional, using some global
port setting if it's not present. But I want to advocate a revamp of the
Port/Listen/Bindaddr stuff. And I also want to advocate that we eliminate
the "global server" which can serve hits... I want every server to require
at least one "virtual host" (even if it's portmatch *, ipmatch *).
I haven't dealt with ServerPath. (I'm assuming ServerAlias will merge
into HostMatch.)
Why the hierarchy? Performance. It's possible to hash at each level,
it's possible to do a perfect hash at config time. It's possible to
pre-merge server_config blocks. It is possible to do some of these
optimizations without enforcing the hierarchy, however it would require
more compiler technology (or it would require people to make their config
look like the above to get all the optimizations...).
Dean