Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4ECD53A4.4080503@rowe-clan.net>
Date: Wed, 23 Nov 2011 14:12:20 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: client_ip vs remote_ip
References: <FF603D56-31E3-49B3-B2ED-1E22C3403C3D@jaguNET.com>
 <20111122150803.153fa012@baldur> <201111222217.51060.sf@sfritsch.de>
 <20111122214508.7dbf043e@baldur>
 <DA8997A2-761B-4977-A954-6AB5CADB5DDD@sharp.fm>
 <44C53D01-D6A7-4BFD-B12F-749097B0E781@webthing.com>
 <4ECD33C9.3070501@rowe-clan.net> <20111123182255.21ffaf37@baldur>
In-Reply-To: <20111123182255.21ffaf37@baldur>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 11/23/2011 12:22 PM, Nick Kew wrote:
> On Wed, 23 Nov 2011 11:56:25 -0600
> "William A. Rowe Jr."<wrowe@rowe-clan.net>  wrote:
>
>> +1 to this rename, it's much more sensible than "effective", "phys",
>> "" et al, but reverse them.
>>
>> client_ip / client_addr is the immediate client of httpd, which may
>> be a load balancer or transparent proxy or normal proxy if mod_remoteip
>> has been introduced.
>
> Not really.  The HTTP client is the end-of-line.  The intermediary is
> an HTTP proxy, not a client.

Sorry.  I mixed up 'client' with 'user agent' which are not exactly
interchangeable.  A better word here?

>> remote_ip / remote_addr is the recognized _authenticated_ address.
>
> Indeed, that's terminology that goes right back to apache prehistory.

It is the intent of all users to leverage the end user's IP for authn.
That should be reflected in CGI etc below...

>> This has the additional advantage of *breaking* existing c->remote_ip
>> references and forcing the module author to choose which they mean for
>> their purposes (most would refer to the authenticated address).
>
> An interesting take on it!
>
> But use of remote_ip and remote_addr goes further than that.
> Changing their semantics in CGI (and its imitators from PHP to
> mod_rewrite) would *silently* break apps, so a firm -1 to that.
> And divorcing conn->remote_ip from the CGI/etc gets fearsomely
> confusing!

Ok... look, mod_remoteip does this today.  Various x-remote-ip header
hacks do the same thing for load balancers.  What would break?  The
CGI values absolutely should be the end point (client's) address.

Graham asks us to restore the immediate-next agent's IP address, to
what ends I'm still not clear but apparently mainly for logging and
diagnostics (which was already supported by mod_remoteip for all
intermediary IPs).  What he wants to do with the remaining remote
intermediaries is not apparent.

But his point is correct that it is challenging to track this in the
conn rec given our request lifetime scope, and the fact that the
successive clients on a single pipeline can and will change in many
proxy/balancer scenarios.

I completely agree remote_ip/addr is better tracked at req rec.  We
would just need a variable name in the conn rec for the persistant
(default) ip address of the physical connection.  And it seemed that
you like the breakage to steer developers at the variable really
of interest to them.  client_ip wasn't it ;(