> Am 09.02.2018 um 13:28 schrieb Eric Covener <cove...@gmail.com>: > >> 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. > > I would prefer we just make <virtualhost *:*> or <virtualhost *:80 > *:443> work a little better. > But in the hypothetical nested example, the address could be omitted, > use *:*, or use *:80 *:443. I don't like the churn for mods with > nesting though, since they have server config merge callbacks that > might be subtly wrong. > >> >> 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 > > Are directives valid in VH implicitly valid in MD and using server > config merging? Or are normal directives not anticipated in that > scope? > It seems like more for users and module authors to worry about. > >> >> - 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 would personally rather see no additional nesting and a replacement > or extension for <virtualhost> syntax and mapping, along with a way > forward (by convention) to make directives behave a little better in > <VH *:80 *:443>, but most of my users/users are a very low # of VH'es > so it's not really something I am focused on / tuned into.
My experiment in trunk with a <VirtualHost *:80 *:443> SSLEngine *:443 </VirtualHost> worked. But SSLEngine might not be the only directive where you need some extra "magic" to make it apply to the desired vhost variation. For clarity, I am now more in favour of nesting vhosts/domains/whatever, since this makes it more clear when which config applies. Our server config merging between base and vhosts is well understood and this would just extend the mechanism. -Stefan
