On 23 Nov 2011, at 10:01 PM, Nick Kew wrote: > Um, are you responding to an altogether different point to the > one I was making?
Very possibly... > 1. wrowe was suggesting changing the semantics of remote_ip in core. I interpreted wrowe's suggestion as simply making a name change on the variable to make a clearer distinction between c->remote_ip (IP address of httpd and upstream device, maybe a load balancer), and r->remote_ip (by default the exact same IP, unless mod_remoteip or mod_zeus / etc is configured, in which case it's now the IP of the client as seen by the load balancer, which wants to stay invisible). The semantics of the remote_ip is exactly the same in both cases - it contains the remote IP address of the client. When you add a load balancer in front of a set of httpds, the load balancer obscures the client's IP address, as it is now a "man-in-the-middle". An administrator is now no longer able to use the standard httpd aaa stuff for authz, and loses the IP address in logging. For years load balancers have solved this problem using some means of revealing the client IP to the origin httpd (usually in a header), with a corresponding module like mod_remoteip or mod_zeus to override the IP address, but httpd has never had a clean way to allow this override to take place, as the IP address inside httpd is intimately wired into the connection, not the request. This fixes that, acknowledging that load balancers exist and properly allowing for them, without suffering hacks or leaks in our code. Regards, Graham --
