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