On Nov 23, 2011, at 5:39 PM, Nick Kew wrote:
Appropriate Terminology Suggestion:
ObjectProtocolRemote Name
----
request_rec HTTPClient client_ip
conn_rec TCP
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
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
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
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
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
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
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
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
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
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
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
On 11/23/2011 4:39 PM, Nick Kew wrote:
Appropriate Terminology Suggestion:
Object ProtocolRemote Name
-- --
request_rec HTTPClient client_ip
conn_recTCP Peer
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
14 matches
Mail list logo
