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 <minf...@sharp.fm>: > > On 14 Feb 2018, at 3:05 PM, Yann Ylavic <ylavic....@gmail.com> 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 > — >
