httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: client_ip vs remote_ip
Date Wed, 23 Nov 2011 20:01:45 GMT
On Wed, 23 Nov 2011 20:29:40 +0200
Graham Leggett <minfrin@sharp.fm> wrote:

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

Um, are you responding to an altogether different point to the
one I was making?

1. wrowe was suggesting changing the semantics of remote_ip in core.
2. but REMOTE_ADDR and REMOTE_IP are widely-used in CGI,
   and everything else that uses CGI variables.
3. so wrowe's suggestion implies we EITHER divorce "remote_ip" from
   REMOTE_IP (confusing!) OR change the semantics of REMOTE_IP and
   potentially break thousands of CGI/etc apps.


-- 
Nick Kew

Mime
View raw message