Re: client_ip vs remote_ip
On Nov 23, 2011, at 5:39 PM, Nick Kew wrote: Appropriate Terminology Suggestion: ObjectProtocolRemote Name ---- request_rec HTTPClient client_ip conn_rec TCP Peerpeer_ip Fine with me...
Re: client_ip vs remote_ip
On 25 Nov 2011, at 4:16 PM, Jim Jagielski wrote: Appropriate Terminology Suggestion: Object ProtocolRemote Name -- -- request_rec HTTPClient client_ip conn_rec TCP Peerpeer_ip Fine with me... Done in r1206291. Assuming no problems, will backport this to v2.4 this weekend. Regards, Graham --
client_ip vs remote_ip
On 11/23/2011 2:02 AM, Nick Kew wrote: On 22 Nov 2011, at 22:35, Graham Leggett wrote: On 22 Nov 2011, at 11:45 PM, Nick Kew wrote: Huh? Surely tcp details belong to the connection, and are accessible from the request_rec as r-conn-remote_ip ? They do until a load balancer comes along and sits in the way, obscuring the remote IP address. Suddenly the IP address is different on every request, even though the connection between httpd and the load balancer is constant and lasts a long time using keepalives. Wherein lies the problem. How confusing is it to have r-remote_ip and r-conn-remote_ip *and for them to be different*? These need distinct names to distinguish them! e.g. r-client_ip vs r-conn-remote_ip - obviously keep the latter! +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. remote_ip / remote_addr is the recognized _authenticated_ address. 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). Bill
Re: client_ip vs remote_ip
On Wed, 23 Nov 2011 11:56:25 -0600 William A. Rowe Jr. wr...@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. remote_ip / remote_addr is the recognized _authenticated_ address. Indeed, that's terminology that goes right back to apache prehistory. 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! -- Nick Kew
Re: client_ip vs remote_ip
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 --
Re: client_ip vs remote_ip
On Wednesday 23 November 2011, Graham Leggett 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. Yes, +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. Agreed.
Re: client_ip vs remote_ip
On Wed, 23 Nov 2011 20:29:40 +0200 Graham Leggett minf...@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
Re: client_ip vs remote_ip
On 11/23/2011 12:22 PM, Nick Kew wrote: On Wed, 23 Nov 2011 11:56:25 -0600 William A. Rowe Jr.wr...@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 ;(
Re: client_ip vs remote_ip
On 11/23/2011 2:01 PM, Nick Kew wrote: 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. The later. We've already 'broken' thousands of CGI/etc apps throughout the world, as many customers of mine either use a remote_ip style solution or a much more trivial x-remote-ip header from their load balancer to reroute it. No reports of what grave ills this 'breakage' caused. Care to offer one, any one?
Re: client_ip vs remote_ip
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. Regards, Graham --
Re: client_ip vs remote_ip
On 23 Nov 2011, at 18:22, Nick Kew wrote: But use of remote_ip and remote_addr goes further than that. Whoops! No it doesn't: it's just REMOTE_ADDR that features in CGI. Objection-in-principle to wrowe's suggestion withdrawn! How about, we make a clear break with possible confusion by dropping remote_ip altogether? It has wrowe's desired effect of forcing anyone who uses remote_ip to make a decision over what semantics are in fact needed. Appropriate Terminology Suggestion: Object ProtocolRemote Name -- -- request_rec HTTPClient client_ip conn_recTCP Peerpeer_ip -- Nick Kew
Re: client_ip vs remote_ip
On 24 Nov 2011, at 12:39 AM, Nick Kew wrote: Whoops! No it doesn't: it's just REMOTE_ADDR that features in CGI. Objection-in-principle to wrowe's suggestion withdrawn! How about, we make a clear break with possible confusion by dropping remote_ip altogether? It has wrowe's desired effect of forcing anyone who uses remote_ip to make a decision over what semantics are in fact needed. Appropriate Terminology Suggestion: ObjectProtocolRemote Name ---- request_rec HTTPClient client_ip conn_rec TCP Peerpeer_ip Sounds sensible, +1. Regards, Graham --
Re: client_ip vs remote_ip
On 11/23/2011 4:39 PM, Nick Kew wrote: Appropriate Terminology Suggestion: Object ProtocolRemote Name -- -- request_rec HTTPClient client_ip conn_recTCP Peerpeer_ip +1
Re: client_ip vs remote_ip
Am 24.11.2011 00:27, schrieb William A. Rowe Jr.: On 11/23/2011 4:39 PM, Nick Kew wrote: Appropriate Terminology Suggestion: Object Protocol Remote Name -- -- request_rec HTTP Client client_ip conn_rec TCP Peer peer_ip +1 +1 Regards Rüdiger
