I'm getting lost. What would VirtualServer tag mean exactly?
Thanks in advance and apologies for my slowness :) 2018-02-09 13:42 GMT+01:00 Stefan Eissing <stefan.eiss...@greenbytes.de>: > > >> 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 > > -- Daniel Ferradal IT Specialist email dferradal at gmail.com linkedin es.linkedin.com/in/danielferradal
