httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Effective IP address / real IP address
Date Fri, 18 Nov 2011 14:23:18 GMT
On 18 Nov 2011, at 4:05 PM, Jeff Trawick wrote:

> A. modules keep using conn_rec, core keeps track of TCP peer for
> logging, post-read-request or some other per-request hook used to set
> effective client in conn_rec
> ugly updates to conn_rec by some module; client is really per-request
> in some configurations
> B. modules switch to using new ap_get_client() API, something
> different is used to log the client
> inconsistencies among get-client mechanism used by different unbundled
> modules could be confusing, log format would change
> --/--
> either way, a module that thinks it knows the client across different
> requests is hosed

The lines I was thinking along was that effective_ip was in addition  
to the remote_ip, rather than instead of. The log format wouldn't  
change, there would be a new value that would represent the effective  
IP, in addition to the existing value that represented the real IP.

Existing modules can continue using conn_rec->remote_ip and it will  
still work the same as before.

The advantage of the hook approach is that people whose servers don't  
use authz won't ever see the hook being called, so the functionality  
is no-cost for those who don't need it.

> besides the ugliness of updating conn_rec, are there known functional
> drawbacks of the existing mechanism, assuming that the module which
> sets the client also sets a note to allow logging of the TCP peer if
> desired?

Looking deeper into mod_remoteip, most specifically  
remoteip_modify_connection(), what I see is that we seem to be leaking  
memory from c->pool on each request, which on a server serving  
millions of requests an hour will start to add up.

In addition, it looks like we assign memory allocated from r->pool  
into the structure attached to c->pool without having registered any  
cleanups to reverse this when r->pool is destroyed.

I think we need to look closer at this.


View raw message