httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: Exposing more loggable data from the proxy
Date Fri, 25 Oct 2013 18:34:40 GMT
On Fri, Oct 25, 2013 at 9:16 AM, Jeff Trawick <> wrote:

> On Fri, Oct 25, 2013 at 9:07 AM, Daniel Ruggeri <>wrote:
>> As I stand up a simple IPv6 test proxy that supports both AF_INET and
>> AF_INET6 addresses, I was looking for a way to log what addr family (and
>> maybe the IP address) mod_proxy settled on for each request in the
>> access_log. I'm not seeing a way to do that (but correct me if I'm
>> missing something) and was poking through the code and got to thinking
>> that there are all kinds of data bits that'd be interesting to have
>> available in the ENV.
>> I'm thinking it'd be worth adding a directive (ProxyAddEnvironment?)
>> that adds these ENV entries to each r->subprocess_env:
>>  * Host header sent to backend (useful when dynamic targets are used)
>>  * Target DNS name if set
>>  * Target IP address
>>  * Target Address family
>>  * Target port
>>  * Target connection protocol
>>  * Flag for SSL enabled
>> All of the data is readily available once a connection is acquired in
>> ap_proxy_acquire_connection sans the HTTP Host header.
>> Aside from logging, exporting these as ENV entries to the request allows
>> us to do all sorts of stuff in other modules, too....
>> Any thoughts? Is there something I should include or exclude before I
>> begin?
>> --
>> Daniel Ruggeri
> (unrefined, right out of my ...  head)
> useful to have a convention (if not API) for how this info is made
> available for logging, etc., so that other modules can play the same game
> (e.g., mod_jk, FastCGI, whatever)
> what about a plugin with optional functions that has APIs for recording
> backend state that is meaningful across variety of "gateway" modules?  for
> now maybe it is just for logging, but it could save in shared memory for
> extraction in mod_status or other reports
> maybe that solution is a bit farfetched, but I guess the theme is that
> creating a proxy-specific solution can be a wasted effort given the same
> need for any number of other "gateway" modules
> --
> Born in Roswell... married an alien...

A little more refined...  (see attached .h file)

It wouldn't take too many lines of code to provide logging (custom access
log format with various format strings).  A "few" more and it is in shared
memory for a scoreboard display so you can see where your requests are
getting stalled when talking to LDAP servers or app servers or whatever...

Having a callable API for modules will help with consistency of
representation and largely eliminate questions of what can/should be

Born in Roswell... married an alien...

View raw message