Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Message-Id: <0F948652-0F13-4B38-8CFC-80CF5B2ECA8A@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
In-Reply-To: <20111123182255.21ffaf37@baldur>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: client_ip vs remote_ip
Date: Wed, 23 Nov 2011 20:29:40 +0200
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>

On 23 Nov 2011, at 8:22 PM, Nick Kew wrote:

>> 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).

This makes more sense to me, +1.

> 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!

There is no option to silently break any app, the only way to get this  
functionality is for the administrator to actively enable a module  
like mod_remoteip (or similar module depending on your needs). In the  
word of load balancers, this behaviour is already well understood and  
supported.

Regards,
Graham
--