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
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?
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.
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.
Reading this a third time through, the behavior KJR describes is correct by design of the implementors of the X-FF header. Closed.
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.
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
mod_log_config doc already says that %{foo}i reflects modifications by modules, so this is working as designed.
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.
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