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" <stefan.eiss...@greenbytes.de>
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 <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
> > —
> >
>
>

Reply via email to