[2.0] proposed vhost config rewrite

[Dean Gaudet <dg...@arctic.org>]

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

Re: [2.0] proposed vhost config rewrite

[Dean Gaudet <dg...@arctic.org>]

On Mon, 9 Jun 1997, Alexei Kosut wrote:
> Should be we using IP addresses at all?

I've given this lots of thought... you can read some of the reasons why ip
addresses are required for robustness and security in the dns-caveats.html
page.

Note that I mention doing a reverse dns lookup in the Appendix: Future
Directions... I'm not being daft -- I know that reverse DNS is possibly
not under the control of the admin.  But my reason for suggesting that is
that either the reverse lookup is on one of the admin's blocks, in which
case it's the admin's fault if it is wrong.  Or it's in some outside
block.  In which case it's *highly unlikely* that the server actually
responds to that address... and so it doesn't matter if it thinks a vhost
is on the bogus address.

But 1.1 Host: headers "solve" these problems.  Or do they?  Well, consider
Standard U. which has a math and a chem department, whose servers are
aptly named www.math.standard.edu and www.chem.standard.edu but are
actually hosted on the same machine using name-vhosts.  Running netscape
on my pc.math.standard.edu I access "www".  Netscape sends "Host: www". 
That's exactly correct.  What does the central webserver do?  How does it
know to serve "www.math.standard.edu" ? 

In the end I have to conclude that ip addresses are still necessary.

Dean

Re: [2.0] proposed vhost config rewrite

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Mon, 9 Jun 1997, Dean Gaudet wrote:

[...]

> <PortMatch PP ...>
>     ...
>     <IPMatch a.b.c.d ...>
> 	...
> 	<HostMatch ... ...>
> 	    ...
> 	</HostMatch>
> 	...
>     </IPMatch>
>     ...
> <PortMatch>

I like this. I assume this would apply to every directive? I think
that, like Ben said, a bit more flexibility might be in order; so you
could mix and match PortMatch and IPMatch. (HostMatch should probably
only be allowed inside the two, not outside.) And maybe defaults of 80
and *.*.*.*.

Should be we using IP addresses at all? I know that for
high-performance sites its useful, but aren't they deprecated (and I
know I've spelled that wrong) for user-level use? Although they do
make things simpler to implement and understand. I think that's the
main problem with the current approach. It's too complicated to figure
out, and violates one of the basic principles of human interface
design (no hidden mode switches).

[...]

> I haven't dealt with ServerPath.  (I'm assuming ServerAlias will merge
> into HostMatch.) 

ServerPath's not a problem. Just define it so it only works inside a
HostMatch, and it'll work peachy (assuming the code's there).

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/