> 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.

I would prefer we just make <virtualhost *:*> or <virtualhost *:80
*:443> work a little better.
But in the hypothetical nested example, the address could be omitted,
use *:*, or use *:80 *:443.  I don't like the churn for mods with
nesting though, since they have server config merge callbacks that
might be subtly wrong.

>
> 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

Are directives valid in VH implicitly valid in MD and using server
config merging?  Or are normal directives not anticipated in that
scope?
It seems like more for users and module authors to worry about.

>
> - 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 would personally rather see no additional nesting and a replacement
or extension for <virtualhost> syntax and mapping, along with a way
forward (by convention) to make directives behave a little better in
<VH *:80 *:443>, but most of my users/users are a very low # of VH'es
so it's not really something I am focused on / tuned into.

Reply via email to