Not at all. This is physical host vs named based vhost.
We got clever and eliminated the distinction after 2.0... which is catching up with us. Should we reintroduce a physical vhost? I don't have a simple answer, but we can at least keep repeating that the first vhost is the physical vhost and only certain directives have any effect there. On Feb 14, 2018 08:49, "Stefan Eissing" <[email protected]> wrote: > I had a patch posted here on Monday that introduces > > <HostGroup name> > ... > <VirtualHost...> > </VirtualHost> > </HostGroup> > > with a server_rec and configs between base server and a a set of > vhosts. Would that satisfy your needs for this? > > -Stefan > > > Am 14.02.2018 um 14:39 schrieb Graham Leggett <[email protected]>: > > > > On 14 Feb 2018, at 3:05 PM, Yann Ylavic <[email protected]> wrote: > > > >> It makes sense, and actually I missed some logic w.r.t. > >> enabled/disabled being a list of sockaddrs (based on servers' > >> server_addr_rec, and not a global boolean as I first thought...). This > >> is later compared to incoming connections local addr. > >> Let me grok that... but at first glance it looks quite cumbersome, why > >> not the usual server merging and a simple "enabled" boolean? > >> If we only care about the config of the base server, > >> "ap_get_module_config(c->base_server->module_config, > >> &remoteip_module)" could do it no? > >> For now it seems that all the vhost selection logic is duplicated, but > >> indeed it's not global (nor really per vhost, but yes this is thee > >> scope which comes closest). > > > > I think the problem distills down to our config lacking an explicit > configuration container for the IP address and port, something like this: > > > > # global > > <Bind …> > > # per port > > RemoteIPProxyProtocol on > > <VirtualHost …> > > # per virtual host > > </VirtualHost> > > </Bind> > > > > In the absence of a Bind directive (or equivalent) we’re left with this > undesirable config: > > > > # global, yuck > > RemoteIPProxyProtocol on > > <VirtualHost …> > > # per virtual host > > </VirtualHost> > > > > So we’ve compromised and said we’ll accept this config: > > > > <VirtualHost …> > > # per port > > RemoteIPProxyProtocol on > > # per virtual host > > </VirtualHost> > > > > To set RemoteIPProxyProtocol, we have to jump up one level to get > server_addr_rec, walk the list of matching IP addresses on virtual hosts > and setting (or not) as appropriate. > > > > Regards, > > Graham > > — > > > >
