> 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.:) -Stefan
