I'm using the X-Forwarded-for header which Pound sets to the value of 
the caller's IP.
Am I right in thinking that Pound won't set this header if it's already 
present in the request?
This would make sense, as then Pounds can be cascaded....

Anyway, it looks like certain requests reaching my pound (from mobile 
phones) already have the "X-Forwarded-for" header set - googling for 
this header certainly shows that it isn't unique to Pound, is used other 
place - so that Pound won't set it. I'm wondering if there is a way to 
force Pound to always set "X-Forwarded-for" (to the souce IP), even if 
the header is already set in the request?

Alex

As far as I remember, Pound will do the right thing and actually 
append (or prepend, I don't remember) the remote user's IP to an 
existing X-Forwarded-For header (they are comma separated I believe). 
Is this not the case?

Jacques.

At 16:33 26/09/2007, Alex Hunsley wrote:[...]

Alex Hunsley wrote:[...]

I believe in this case pound modifies the X-Forwarded-For header to add 
the connecting IP.  Technically X-Forwarded-For is not the end-user's 
IP, its the list of IPs being forwarded.

So these are both valid:

X-Forwarded-For: 1.2.3.4

and

X-Forwarded-For: 1.2.3.4, 5.6.7.8

The length of that list of IPs can go on and on, in the general case.

Regards,[...]

Dave Steinberg wrote:[...][...][...]
Ah, thanks for the clarification on the nature of X-Forwarded-For.
As far as my pound setup here goes, it seems to be like Pound is just 
not touching "X-Forwarded-For" header if it already exists.
I can see this because I have a "front" pound, and behind that I have a 
"back" pound, defining sessions based on the "X-Forwarded-For" header. 
When I look at the current sessions using poundctl, I see things like this:

   5. Session 10.1.2.3 -> 0

.. rather than the expected, which is something like:

  5.  Session 10.1.2.3, 192.168.3.1 -> 0

So it looks like Pound isn't touching an existing "X-Forwarded-For" 
header. (Or it is, but session keys based on headers are truncated at 
the first ',' comma chartacter in the header value.)

As for my problem, I've made a very quick and dirty workaround: I've 
edited the binary for pound on my system, replacing the text 
"X-Forwarded-for" with "X-Pound-Fwd-For". Plus, I then changed my 'back' 
Pound to use this new header. Now it works as I want: the sesssion keys 
listed in front and back pounds match.


If I were to suggest a modification to Pound, I would say that is would 
be useful to be able to override the name of the header 
"X-Forwarded-for" that is set. As I have done in my quick hack...

Alex


[...]

Alex Hunsley wrote:[...][...]
>>> I'm using the X-Forwarded-for header which Pound sets to the value

>>> of the caller's IP.
>>> Am I right in thinking that Pound won't set this header if it's 
>>> already present in the request?
>>> This would make sense, as then Pounds can be cascaded....
>>>
>>> Anyway, it looks like certain requests reaching my pound (from 
>>> mobile phones) already have the "X-Forwarded-for" header set - 
>>> googling for this header certainly shows that it isn't unique to 
>>> Pound, is used other place - so that Pound won't set it. I'm 
>>> wondering if there is a way to force Pound to always set 
>>> "X-Forwarded-for" (to the souce IP), even if the header is already

>>> set in the request?[...][...]
Ah, no, I understand now.
If an "X-Forwarded-for" header already exists, Pound just adds another.
I have just seen the following headers in a tcpdump of traffic:

X-Forwarded-for: 10.1.2.3
X-Forwarded-for: 192.168.3.5

in other words, it adds a whole new header. There are two headers with 
the same name, different data.
Is this correct? Or should it be doing the appending thing (i.e. append 
IP to existing header)? The appending thing makes more sense...
lex

>> So these are both valid:[...][...]

My guess, out of nowhere, is the latter - that it uses the first value 
for sessions as you've configured it.  I would suggest looking at the 
headers your backend receives, via a logging module on your backend 
directly or tcpdump, and check for sure.  The best way to know is to 
look at what comes over the wire!
[...]

I think there was something in the archives about a patch to add 
X-Original-IP or something like that in addition to X-Forwarded-For. 
The semantics were what you originally expected to get from 
X-Forwarded-For.  Might be worth poking for it to see how your patch 
compares.

Regards,[...]

Alex,

You can remove the "X-Forwarded-For" header in your HTTPListener 
(HeadRemove X-Forwarded-For).  This way you'll ensure that you have only 
1 "X-Forwared-For" header when you backend receives a call (the IP 
address of the caller).

Alex Hunsley wrote:[...][...]
>>> Alex Hunsley wrote:
>>>> I'm using the X-Forwarded-for header which Pound sets to the
value 
>>>> of the caller's IP.
>>>> Am I right in thinking that Pound won't set this header if
it's 
>>>> already present in the request?
>>>> This would make sense, as then Pounds can be cascaded....
>>>>
>>>> Anyway, it looks like certain requests reaching my pound (from

>>>> mobile phones) already have the "X-Forwarded-for" header set -

>>>> googling for this header certainly shows that it isn't unique
to 
>>>> Pound, is used other place - so that Pound won't set it. I'm 
>>>> wondering if there is a way to force Pound to always set 
>>>> "X-Forwarded-for" (to the souce IP), even if the header is
already 
>>>> set in the request?
>>>
>>> I believe in this case pound modifies the X-Forwarded-For header
to 
>>> add the connecting IP.  Technically X-Forwarded-For is not the 
>>> end-user's IP, its the list of IPs being forwarded.
>>>
>>> So these are both valid:
>>>
>>> X-Forwarded-For: 1.2.3.4
>>>
>>> and
>>>
>>> X-Forwarded-For: 1.2.3.4, 5.6.7.8
>>>
>>> The length of that list of IPs can go on and on, in the general
case.[...][...]