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.
Regards,
Graham
--
