> Am 09.02.2018 um 13:25 schrieb Yann Ylavic <ylavic....@gmail.com>:
> 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
> domain).
> 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
> else).
> So I find root <VirtualHost> more generic as a container, we could
> want another name too (Service, Container, ...).

Now, there is a nice naming debate in the makings... ;-)

I appreciate that you like the concept. I agree that groupings that do
not have a common DNS make sense too and should be possible (first thing
comes to mind is a grouping by customers).

Since we are in "VirtualHost" land anyway, I can agree to 

<VirtualServer "name">

(I like admin supplied unique names - they are useful.:)


Reply via email to