Bug 53099

Summary: Allow multiple values in RemoteIPHeader
Product: Apache httpd-2 Reporter: Brett <brett.maxfield>
Component: mod_remoteipAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: NEW ---    
Severity: enhancement CC: mail
Priority: P2    
Version: 2.4-HEAD   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description Brett 2012-04-18 11:48:28 UTC
It would be nice if in mod_remoteip, you could specify a list of
headers and not just one.

suggestion is to allow multiple parameters to RemoteIPHeader, eg:

RemoteIPHeader X-Forwarded-For, X-Forward
RemoteIPTrustedProxy gateway.localdomain

Headers would preferably to be checked for in the provided order. 

Use case example is :

1. If there is X-Forwarded-For header use it (as the traffic is
through a forward proxy, such as squid)

2. Otherwise if there is X-Forward header use it (traffic is direct,
but via a SNAT-ing content switch)

3. Otherwise use the connection's REMOTE_ADDR as usual (traffic is direct - and
not via a SNAT-ing content switch OR a forward proxy)

In the current mod_remoteip, you can only pick one header - the
different headers in our case are created by different devices. The content switch makes X-Forward with a single ip address and the forward proxy adds X-Forwarded-For in the usual manner.

Both headers rewrite fine using the existing code, except i must choose to rewrite either the content switch header OR the forward proxy header, but not both.
Comment 1 msporleder 2013-08-02 18:48:51 UTC
I could use this too
Comment 2 William A. Rowe Jr. 2016-02-11 16:38:28 UTC
Mike, this statement confuses me...

/* If no RemoteIPInternalProxy, RemoteIPInternalProxyList, RemoteIPTrustedProxy
   or RemoteIPTrustedProxyList directive is configured,
   all proxies will be considered as external trusted proxies.

mod_remoteip should not be translating any addresses from an unrecognized proxy.  These untrusted addresses continue to live in the header they were presented in (e.g. X-Forwarded-For) for modules to inspect, but must not enter the authnz scheme of httpd.

Is this an issue with the module's logic (original, or as-patched), or just a mis-statement?
Comment 3 William A. Rowe Jr. 2016-02-11 16:46:48 UTC
Ignore the earlier comment #2, I meant to direct that to #55962
Comment 4 William A. Rowe Jr. 2016-02-11 17:11:49 UTC
This is a good suggestion, but I think we should take this one step further...

RemoteIPInternalHeader X-RemoteIP
RemoteIPHeader X-Forwarded-For, X-Forward

In the absence of an RemoteIPInternalHeader list, the RemoteIPHeader list would be used instead to unwind the forwarded addresses for RemoteIPInternalProxy members. When the RemoteIPInternalHeader list is exhausted, the RemoteIPInternalProxy list would continue to be honored, but treated as trusted external proxies, for purposes of dis-honoring private IP addresses. This should ensure maximum compatibility with existing configurations and offer the fewest unintended consequences of a misconfiguration.

It's unclear to me if https://tools.ietf.org/html/rfc7239 will see widespread adoption and how it would interact with older conventions.

The header "Forwarded" could be treated as a special-case, supporting the new RFC, but deciphered in the order it appears.  (I imagine it would typically be first where the immediate proxies which are trusted have adopted the convention).

Sadly, https://tools.ietf.org/html/rfc7239#section-7.4 is less than helpful on this subject :)
Comment 5 Tom Sommer 2017-05-30 15:07:47 UTC

This would be extremely useful, as modern proxies have moved away from X-Forwarded-From, to their own header for each (Cloudflare, Securi, etc.)
Comment 6 Jason 2017-09-07 23:58:33 UTC
I too would like to see multiple Headers supported here for the very reason that Tom mentions in Comment #5:

This would be extremely useful, as modern proxies have moved away from X-Forwarded-From, to their own header for each (Cloudflare, Securi, etc.)

I find myself wrestling with Load Balancer's which use one Header and CloudFlare which uses another. Installing both mod_cloudflare and mod_remoteip will cause Apache to crash if both modules attempt to set different IPs. 

I'd like to keep control of the headers in one place as well. It's simple enough to emulate mod_cloudflare with mod_remoteip but in doing so we cannot convert our LB IPs because mod_remoteip only accepts one header.
Comment 7 Artem Russakovskii 2019-10-14 21:12:44 UTC
It's been 7 years and the bug is still open - is it really still not possible to use multiple headers?
Comment 8 Christophe JAILLET 2019-10-15 17:45:43 UTC
RemoteIPHeader still accepts only one parameter, so no, it is still not possible.
(read: patches welcome :) )