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
—
smime.p7s
Description: S/MIME cryptographic signature
