Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A8690102B7 for ; Fri, 25 Oct 2013 14:10:57 +0000 (UTC) Received: (qmail 142 invoked by uid 500); 25 Oct 2013 14:10:54 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 135 invoked by uid 500); 25 Oct 2013 14:10:53 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 119 invoked by uid 99); 25 Oct 2013 14:10:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Oct 2013 14:10:52 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ylavic.dev@gmail.com designates 209.85.223.181 as permitted sender) Received: from [209.85.223.181] (HELO mail-ie0-f181.google.com) (209.85.223.181) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Oct 2013 14:10:46 +0000 Received: by mail-ie0-f181.google.com with SMTP id ar20so6632123iec.12 for ; Fri, 25 Oct 2013 07:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RfukKHwgGvReLAlk1OwokvHAP7M+yi+DPQI0eHWYg2o=; b=K7ZKY592V85dEDcFWQXcVOpGII5FcJsl6F9JMzvo6Eh2FTUMhxJntSF5eqIwZ43n9D TVBKdj10p6ko2ph0o5nq5tFAHzENcRNXooV2CGRko38/Y7cFLCEguR6uq208FW91Ptmx QO/A7VbLv78c+VeNRzVw+CvA0LGEgsIGsUlPKWSnw0l3XK9zipjvUe5hN7Fy6EO80KQQ 7G67OvTTFW8NPUil+GqMKB/3nYpz1XtKdSEalKxqIwaMvEvf1j4+SVxFQPXAJMW4MZoN 8nOycLIo7sOEA3GB1XRLudIQ4uNlwLl+7OgsVhaWx7V5Yxo5kT2w0/euNCGo0b89Zhx0 Dz4Q== MIME-Version: 1.0 X-Received: by 10.43.180.200 with SMTP id pf8mr1431875icc.50.1382710224491; Fri, 25 Oct 2013 07:10:24 -0700 (PDT) Received: by 10.42.28.69 with HTTP; Fri, 25 Oct 2013 07:10:24 -0700 (PDT) In-Reply-To: <526A6D2C.20603@primary.net> References: <526A6D2C.20603@primary.net> Date: Fri, 25 Oct 2013 16:10:24 +0200 Message-ID: Subject: Re: Exposing more loggable data from the proxy From: Yann Ylavic To: dev@httpd.apache.org Content-Type: multipart/alternative; boundary=001a11c3ad4cc21a3904e9914fc1 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c3ad4cc21a3904e9914fc1 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --001a11c3ad4cc21a3904e9914fc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How about setting backend->r to r->backend (when = applyable)?

For now backend->r is pooled to backend's connection, and has a diff= erent lifetime than r but maybe it worth having it destroyed with r (settin= g 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-&g= t;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 lifeti= me, 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.ne= t> 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<= br> 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:
=A0* Host header sent to backend (useful when dynamic targets are used)
=A0* Target DNS name if set
=A0* Target IP address
=A0* Target Address family
=A0* Target port
=A0* Target connection protocol
=A0* 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


--001a11c3ad4cc21a3904e9914fc1--