On Fri, Feb 9, 2018 at 7:25 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > 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, ...).
There is infrequently used special handling today for e.g. <virtualhost example.com> that trumps some of the typical NVH handling if memory serves. Maybe that could be shored up or even preferred if it helps. That still leaves having inner directives that might want to be port-specific, I just don't know how common enough that is to not handle it one at a time with logic (SSL) or expressions/if. I have colleagues that work on a CERN-based legacy server that allows many directives to take a Host header argument, but it has no config sections at all. Perhaps we could provide a simplified <if> that took list of hosts instead of nesting VH'es or similar sections? But it still has the problem of per-dir directives only. -- Eric Covener cove...@gmail.com
