On Wed, 23 Nov 2011 20:29:40 +0200 Graham Leggett <[email protected]> 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
