Bug 37194 - Logging *input* header values (was re: X-Forwarded-For)
Summary: Logging *input* header values (was re: X-Forwarded-For)
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Documentation (show other bugs)
Version: 2.2-HEAD
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: HTTP Server Documentation List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-21 10:49 UTC by Klaus Johannes Rusch
Modified: 2012-03-30 13:14 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Johannes Rusch 2005-10-21 10:49:51 UTC
The X-Forwarded-For input header is modified for proxied requests, for example
when using

LogFormat "%{x-forwarded-for}i %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\" \"%{Cookie}i\"" forward-log

the server logs record the request X-Forwarded-For header plus the remote address:

        /* Add X-Forwarded-For: so that the upstream has a chance to
         * determine, where the original request came from.
         */
        apr_table_mergen(r->headers_in, "X-Forwarded-For",
                       r->connection->remote_ip);

(the same is true for the other X-Forwarded-* headers).

Input headers should be logged unmodified.


manageNow
Comment 1 Nick Kew 2007-09-08 15:28:17 UTC
RFC2616 has different rules for different classes of header, but is silent on
X-Forwarded-For.  Is there an RFC that tells us what to do?
Comment 2 Klaus Johannes Rusch 2007-09-08 17:23:06 UTC
X-Forwarded-For is a de-facto standard, not a formally specified header.

The problem is not with how the header is used though, but with how it is
logged. When logging an INPUT header, any processing done by the Webserver
should not be reflected in the logged value.
Comment 3 William A. Rowe Jr. 2009-09-24 22:35:19 UTC
RFC2616 calls out that all headers can be merged and split as tokens.  Cookie
headers pre-RFC are a special exception.

KJR is wrong with respect to the intermediaries, they may register their
presence as all intermediary proxies can.  Just do so in the right order.
But it would be nice to be able to stow the client address in another field
other than X-FF, such as X-Client-IP as most firewalls are capable of.
Comment 4 William A. Rowe Jr. 2009-09-24 22:37:40 UTC
Reading this a third time through, the behavior KJR describes is correct
by design of the implementors of the X-FF header.  Closed.
Comment 5 Klaus Johannes Rusch 2009-09-25 00:40:30 UTC
Will, I agree that Apache may (and should) add the remote address to the X-Forwarded-For header when proxying the request to another server, that behavior is working as designed.

What's incorrect though is logging the MODIFIED X-Forwarded-For header for %{x-forwarded-for}i since the input header did not contain the remote address of the current request.
Comment 6 Peter 2011-04-15 08:15:13 UTC
I agree that the modifed x-forwarded-for shouldn't be added to the log file. Any news around this bug? We have the same bug in apache 2.2.17.

/Peter
Comment 7 Eric Covener 2011-04-15 08:20:17 UTC
mod_log_config doc already says that %{foo}i reflects modifications by modules, so this is working as designed.
Comment 8 William A. Rowe Jr. 2011-04-15 12:35:52 UTC
I'm going to reclass this as a documentation bug, since we should illustrate
capturing and logging an input header with mod_headers/env or similar and
provide a pointer to this workaround in the %{foo}i documentation.
Comment 9 Eric Covener 2012-03-30 13:14:26 UTC
I added a pointer to using setenvif to save an "early" but not necessarily initial value of an input header into mod_log_config back through 2.2