Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: Effective IP address / real IP address
Date: Mon, 21 Nov 2011 19:04:10 +0100
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1082AC01-C7E8-493A-9FD1-FFF8BD10EE13@sharp.fm>
 <CAKUrXK5N_WE0_+K5CwAHSxwUqBVNVJedj=AHZ0GoiAzPWFPZaQ@mail.gmail.com>
 <6BCD7365-4E4F-472A-9CDE-2458477CCFAE@sharp.fm>
In-Reply-To: <6BCD7365-4E4F-472A-9CDE-2458477CCFAE@sharp.fm>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201111211904.11389.sf@sfritsch.de>

On Sunday 20 November 2011, Graham Leggett wrote:
> On 20 Nov 2011, at 1:37 AM, Jeff Trawick wrote:
> > On Sat, Nov 19, 2011 at 2:46 PM, Stefan Fritsch <sf@sfritsch.de>
> > 
> > wrote:
> >> On Saturday 19 November 2011, Graham Leggett wrote:
> >>>> The correction is simple; promote the remote_ip up to the
> >>>> request rec and log/use for authentication that r->remote_ip
> >>>> throughout httpd.  Introduce a wire client logging tag for
> >>>> c->remote_ip.
> >>> 
> >>> This is a lot simpler and cleaner I think, let me come up with
> >>> an alternative patch.
> >> 
> >> I also think this is preferable. The hook approach adds unneeded
> >> complexity and users of mod_remoteip would also need to change
> >> their log formats.
> > 
> > Yeah, only needing to add a special .conf for LB configurations
> > would be nice (i.e., not touching/reconfiguring anything else)
> 
> This is the alternative I've come up with, again needing docs and
> in- principle. A logging option has been attached to log the raw
> IP address. Separately, I've attached a patch for mod_remoteip.
> Thoughts?

Looks reasonable. Some comments:

The error log handler log_remote_address for %a needs to fall back to 
c->remote_ip if r is not specified. Otherwise one would need different 
logformats for per-conn and per-request log messages. Also, I would 
prefer %{r}a and %{c}a to force logging of r->remote_ip and c-
>remote_ip. Then we don't need a new format letter and it would be 
more consistent with the %L and %{c}L errorlog format.

We may also want a CONN_REMOTE_ADDR or PHYS_REMOTE_ADDR variable in 
ap_expr to still allow access to c->remote_addr.

Do we need special handling of the REMOTE_HOST script variable? 
Probably it does not make sense because we can't reliably do DNS 
lookups for addresses received via X-Forwarded-For.

I think there may be some confusion of addresses if mod_remoteip is 
used for CONNECT requests. But I am OK with ignoring that 
complication. It should always be possible to use the connection log 
ids to correlate the different messages.

IMHO, commit to trunk and we can fix the remaining issues there.