Asking me to ask myself why I did what I did 10 years ago :)

Best explanation I have is that I'd envisioned that the internal and
external trust lists would be universally accepted lists, and they are
*very* slow to parse with DNS lookups. E.g. the wikipedia X-F-F
whitelist. And a corporate firewall/proxy list. Fairly cookie-cutter.

These days, with specific services forwarded for specific front ends
and applications over specific routes, I can see the demand for
per-host lists.

The underlying issue, IIRC, was that we want to assemble the list
(global, or per-vhost) long before we augment it with specific deltas
(removal or addition) for the host or per-file (location) context.
That's why I suspect I made this exec-on-read.





On Fri, Apr 6, 2018 at 1:10 PM, Christophe Jaillet
<christophe.jail...@wanadoo.fr> wrote:
> Hi list,
>
> I'm working on PR 62220 and I don't understand what could cause the reported
> regression.
>
> Apparently the behavior of RemoteIPInternalProxyList has changed in 2.4.33.
> But RemoteIPInternalProxy (without List) still works as expected.
>
> Looking at the implementation of the 2 directives, RemoteIPInternalProxyList
> is equivalent to several RemoteIPInternalProxy directives. So why one should
> stop working and not the other?
>
> After some debugging, it appeared that removing the EXEC_ON_READ from
> RemoteIPInternalProxyList makes it work as expected again.
>
> My question are:
>   - why is RemoteIPInternalProxyList defined with EXEC_ON_READ? This makes
> nearly no cense so me.
>   - BUT if removing it is the solution, why was it working before???
>
> Any hint?
>
> CJ
>

Reply via email to