On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing
<stefan.eiss...@greenbytes.de> wrote:
>> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>> Forgive the top-post, Gmail app sucks.
>> Thanks for taking the time for tl;dr - it sums up the current situation 
>> really well.
>> I pointed out some months ago that the matching foo in vhosts is weak, since 
>> we have a 1:1 ip:port relationship. We determined that can change in the 
>> next iteration to compare a list we already keep. It seems also evident that 
>> a vhost could have more than one ServerName as long as we track the 
>> canonical name that the request presented.
>> Considering your cases, I'm wondering if the simplest thing is to promote 
>> <VirtualHost > to a preprocessed, but fully nestable context on trunk?
> That is one possible way to address this. However, since VirtualHost requires 
> at least one address, this would be confusing:
> <VirtualHost *:NNN>
>    ServerName example.org
>    <VirtualHost *:80>
>    </VirtualHost>
>    <VirtualHost *:443>
>    </VirtualHost>
> </VirtualHost>
> What would NNN be or what would it mean? Would it also be inherited by the 
> nested vhosts? This is confusing.

The <VirualHost> directive could be relaxed to also take no arg.
Since at least one is required by now, it wouldn't break anything.

> From usability point of view, it is superior to introduce a new "section" 
> that can keep common locations and other settings for sharing. The 
> implementation is more painful, though. Unsurprisingly, I think of something 
> like this:
> <ManagedDomain example.org>
>    <VirtualHost *:80>
>    </VirtualHost>
>    <VirtualHost *:443>
>    </VirtualHost>
> </ManagedDomain>
> Implementation-wise:
>  * an MD is basically a server_rec plus additional props
>  * server_rec gets 2 new members "server_rec *child, *sibling" to keep 
> contained vhosts
>  * server_rec->next contains only leaf server_recs -> base_server->next 
> contains all VirtualHosts as before
>  * leaf server_rec->child is NULL
>  * no nesting of MDs foreseen, disabled, no nesting of VirtualHost
> - VirtualHosts server_rec* can be walked as before and all vhost functions 
> see no change.
> - Modules should see no change either
> - The MD and VirtualHost hierarchy can be traversed by new code starting from 
> base server.
> What do you think?

I like these semantics.

But I'd prefer <VirtualHost> as root, <ManagedDomain ...> is too
"domain" centric IMHO (all the inner vhosts are necessarily bound to a
With <VirtualHost "some.domain"> or <VirtualHost> + ServerName +
WhatEverMakesSenseForAllInners we could achieve the same and more
(including a common <ManagedDomain> why not), while individual inner
vhosts can have their own domain (if grouping is based on something
So I find root <VirtualHost> more generic as a container, we could
want another name too (Service, Container, ...).

Reply via email to