httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Effective IP address / real IP address
Date Fri, 18 Nov 2011 14:05:22 GMT
On Fri, Nov 18, 2011 at 8:24 AM, Graham Leggett <minfrin@sharp.fm> 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?

Mime
View raw message