You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2011/11/23 18:56:25 UTC
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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Posted by Graham Leggett <mi...@sharp.fm>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 23 Nov 2011 20:29:40 +0200
Graham Leggett <mi...@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
Posted by Graham Leggett <mi...@sharp.fm>.
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
Posted by Graham Leggett <mi...@sharp.fm>.
On 25 Nov 2011, at 4:16 PM, Jim Jagielski wrote:
>> Appropriate Terminology Suggestion:
>>
>> Object Protocol Remote Name
>> ------ -------- ------ ----
>> request_rec HTTP Client client_ip
>> conn_rec TCP Peer peer_ip
>
> Fine with me...
Done in r1206291. Assuming no problems, will backport this to v2.4 this weekend.
Regards,
Graham
--
Re: client_ip vs remote_ip
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 23, 2011, at 5:39 PM, Nick Kew wrote:
> Appropriate Terminology Suggestion:
>
> Object Protocol Remote Name
> ------ -------- ------ ----
> request_rec HTTP Client client_ip
> conn_rec TCP Peer peer_ip
Fine with me...
Re: client_ip vs remote_ip
Posted by Graham Leggett <mi...@sharp.fm>.
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:
>
> Object Protocol Remote Name
> ------ -------- ------ ----
> request_rec HTTP Client client_ip
> conn_rec TCP Peer peer_ip
Sounds sensible, +1.
Regards,
Graham
--
Re: client_ip vs remote_ip
Posted by Rüdiger Plüm <ru...@vodafone.com>.
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
Re: client_ip vs remote_ip
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Re: client_ip vs remote_ip
Posted by Nick Kew <ni...@webthing.com>.
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 Protocol Remote Name
------ -------- ------ ----
request_rec HTTP Client client_ip
conn_rec TCP Peer peer_ip
--
Nick Kew
Re: client_ip vs remote_ip
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by Nick Kew <ni...@webthing.com>.
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