httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject RE: NameVirtualHost
Date Sun, 26 Oct 1997 01:13:55 GMT


On Sun, 26 Oct 1997, Rob Hartill wrote:

> The problem with the current system (and the old one too) is that it's
> just too damn confusing considering all the different ways people want
> to use it and expect it to work. How about this completely different
> approach..

Well, this is essentially the approach that I first proposed, then Roy
reinvented ... (this would have been Apr-Jun this year) and now you're
reinventing it, almost.  Which is cool, 'cause it means we all might
be close to agreement.

> If a request arrives with attributes 'a:b:c' it can be compared
> against each of the 'Service' attributes 'x:y:z'.

How do you hash ip addresses?  This is a feature that we can't get rid of
... we need hashed ip addresses, and in the future we'll need fast lookups
for name-vhosts. 
    
To do hashing in your syntax requires us to essentially recognize
constructs and compile them into a more efficient form.  For example, we
could recognize a series of Service statements that only made selections
based on IP and generate a hash table out of them.  We'd essentially
generate a parse tree, where some nodes could be hash tables and other
nodes would be single element.

To refresh, Roy and my proposals are essentially the same, and here's an
example:

    # list of ports, optional *, <PortMatch>...</PortMatch> can be omitted
    # entirely, in which case an implicit <PortMatch *> will be assumed
    <PortMatch x y z>

	# IP addresses to match, these are hashed, so order is irrelevent

	<IPAddressMatch a.b.c.d>
	    # Host: based matching
	    HostMatch regex servername
	    HostMatch regex servername2
	    ...
	    # ServerPath based matching, always occurs after Host:
	    # based matching if no match was found
	    ServerPath regex servername
	    ServerPath regex servername2
	    # default
	    DefaultMatch servername
	</IPAddressMatch>

	<IPAddressMatch n.n.n.n>
	    # non-name-vhost
	    ServerConf servername3
	</IPAddressMatch>
    </PortMatch>

    <ServerConf servername>
    ...
    </ServerConf>

    <ServerConf servername2>
    ...
    </ServerConf>

    <ServerConf servername3>
    ...
    </ServerConf>

Note we have two options within the IPAddressMatch blocks.  What I showed
above is an ideal, but not something that can be easily implemented
efficiently.  To implement it efficiently (i.e. in anything less than
linear in the number of regexs) requires you to generate a full scanner
a la lex/flex based on the regexs present.  That's not something easy
to integrate into the server (unfortunately!).  So this weaker syntax
is better for getting at cheap optimizations:

    <IPAddressMatch a.b.c.d>
	# Host: based matching
	DomainMatch servername domain.com
	DomainMatch servername2 domain2.com
	...
    </IPAddressMatch>

For DomainMatch we define the entry with the *longest matching suffix* to
be the winner (note that we only consider full words, so "foodomain.com"
does not domain-match "domain.com").  It's possible to hash this, or
generate a search tree, or whatever.  It can go fast with very little
effort.  This recognizes that many name-vhost configs look like (or
should look like, after the user gets bitten once or twice and realises
what the config error is):

    ServerName www.domain.com
    ServerAlias *.domain.com domain.com

But does not preclude having something like:

    DomainMatch servername domain.com
    DomainMatch servername chem.domain.com
    DomainMatch servername phys.domain.com

And having it work as expected.

So, while I would love to go this route, I didn't think it prudent to do
it in 1.3.  Fortunately, my rewritten http_vhost.c code almost matches
this proposal at the code level, all that's missing is configuration fluff.

Dean


Mime
View raw message