httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: Exposing more loggable data from the proxy
Date Fri, 25 Oct 2013 14:10:24 GMT
How about setting backend->r to r->backend (when applyable)?

For now backend->r is pooled to backend's connection, and has a different
lifetime than r but maybe it worth having it destroyed with r (setting
things related to the origin's connection to NULL, when released, to avoid
invalid accesses)...

Hence r->backend->useragent_addr/useragent_ip (useragent is the origin
here) are accessible everywhere, and so are backend->r->headers_* and
everything related to the request/response send/received to/from the
backend.

I may be missing lot of things with backend->r's lifetime, since it is now
attached to origin->pool, surely for good reasons...
Also, not all proxy modules use backend->r, but maybe these can create a
fake request too with everything NULL except sockaddr (and other relevant
things, if any).



On Fri, Oct 25, 2013 at 3:07 PM, Daniel Ruggeri <DRuggeri@primary.net>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
>
>

Mime
View raw message