httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: client_ip vs remote_ip
Date Wed, 23 Nov 2011 22:07:13 GMT
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.


View raw message