Yeah, the "namespace" stuff makes sense, but really, when you think of it, the PROXY support is, theoretically at least, independent of RemoteIP, even though that module is the one that implements it. It makes it seem like it is "different" in some way to PROXY...
I was thinking something like ProxyProtocolEnable Incoming | Outgoing | Both | Optional | Off so that we have 1 command for all possible PROXY PROTOCOL usages. This, I think, is clearer for end-users. However, I also see the value in having it as a ProxySet parameter for outgoing, so I'm fine whichever way ;) On Dec 30, 2016, at 9:41 AM, Daniel Ruggeri <drugg...@primary.net> wrote: > > > On 12/30/2016 8:28 AM, Jim Jagielski wrote: >> Kewl beans! > Indeed - the best beans to have! > >> Any issue if we rename the directive to just ProxyProtocolEnable? >> The "RemoteIP" prefix just seems weird :) > I assume we try to keep a "namespace" for the more optional modules like > this. It does seem weird and is unnecessarily long but starting with > "Proxy" would lead me to think this directive _belongs_ to one of the > mod_proxy modules. > >> Also, just as a head's up, I'm looking on adding PROXY support >> to the proxy module itself (that is, we *send* the PROXY line >> to backends) as a configurable option. So when that >> happens, we may wish to rethink the command again. > Yes, I planned the same (not cookie licking! It's all yours if you want > it!) which kinda makes me like the RemoteIP prefix on this new directive > to further differentiate it from the client-side work of mod_proxy_*. In > the case of mod_proxy sending the header, a directive like > "ProxySendProxyProtocolHeader On" seems like a viable option (again, > long... and kinda redundant... but "clear" in my mind who's doing what). > > Pending further responses to the followup I sent a moment ago, I'll do > another commit for final cleanup and to remove the new module now ported > to remoteip and will then work on a backport for 2.4 > > -- > Daniel Ruggeri >
