On Fri, Nov 18, 2011 at 8:24 AM, Graham Leggett <[email protected]> wrote: > Hi all, > > Right now, we only keep track of the real IP address of the incoming > connection within conn_rec, and with a simple webserver that's fine. > > In a world containing load balancers, we now have the real IP address (the > load balancer) and the effective IP address (the IP that connected to the > load balancer) for the request. And in restful service architectures, you > might have requests that have passed through a few load balancers on their > way, making the "effective IP address" even more murky. > > Right now, modules that handle this attempt to overwrite the contents of > conn_rec, which is really ugly - requests shouldn't be fiddling with the > parent connection. > > Ideally, what I'd like is a way for httpd to keep track of both the real IP > address (the one in conn_rec) and an optional effective IP address, and use > each appropriately. It will then be up to module authors to write modules to > set the effective IP address as their needs dictate. > > Most specifically, what I have in mind is this: > > - Add a hook ap_get_effective_ip() (or similar). > - With a default APR_HOOK_LAST implementation that just returns the IP from > conn_rec. > - Update the authz modules to use this hook to get the IP instead of reading > conn_rec directly. > - Add the ability to log the effective IP address in additional to the > existing real IP address to the logging code. > > This should in theory be really simple to implement, and opens the door for > future people to choose an effective IP as they see fit. > > Sensible?
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 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?
