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 <[email protected]> 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 >
