> Am 09.02.2018 um 13:28 schrieb Eric Covener <cove...@gmail.com>:
>> 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.

My experiment in trunk with a

<VirtualHost *:80 *:443>
  SSLEngine *:443

worked. But SSLEngine might not be the  only directive where you 
need some extra "magic" to make it apply to the desired vhost variation.

For clarity, I am now more in favour of nesting vhosts/domains/whatever,
since this makes it more clear when which config applies. Our server
config merging between base and vhosts is well understood and this
would just extend the mechanism.


Reply via email to