(Thanks Holger for quick response)
I know that apache comma separates the values for X-Forwarded-For and I
thought haproxy behaves the same.
We do not want to delete X-Forwarded-Forand then add
X-Forwarded-For because the developers want to look at the proxy chain.
Having said that I am still not be able to understand the scenario
mentioned in the clause below to what we are seeing.
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for
that header field is defined as a comma-separated list [i.e.,
#(values)]
Our scenario is client app adds say X-Forwarded-For:10.10.10.10 and then
haproxy also adds another header X-Forwarded-For:192.168.1.1
so at the backend we can see
X-Forwarded-For:10.10.10.10
X-Forwarded-For:192.168.1.1
Does this match the clause mentioned?
Just trying to make sure I understood it right :)
-Habeeb
On Wed, Feb 1, 2012 at 10:22 PM, Holger Just hapr...@meine-er.de wrote:
Hey,
On 2012-02-01 17:41, habeeb rahman wrote:
When there is X-Forwarded-For added by the client(I used chrome rest
client) I can see haproxy is sending two X-Forwarded-For to the backend
instead of appending the values.
One is client sent and the other one is the one haproxy created newly.To
make sure I took capture and I see the duplicate one.
Is this is bug or am I missing something?
You are missing something :) To cite from RFC 2616 (HTTP/1.1):
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for
that header field is defined as a comma-separated list [i.e.,
#(values)]. It MUST be possible to combine the multiple header
fields into one field-name: field-value pair, without changing
the semantics of the message, by appending each subsequent
field-value to the first, each separated by a comma. The order in
which header fields with the same field-name are received is
therefore significant to the interpretation of the combined field
value, and thus a proxy MUST NOT change the order of these field
values when a message is forwarded.
As both forms (comma separated and exploded into multiple headers) are
thus equivalent, HAProxy chooses the simplest implementation and just
appends a new header at the bottom of the headers list. Implementations
are expected to handle this the same as if it were a single header with
comma separated values.
Generally, it is a good idea to only trust those headers that you know
are trustworthy (e.g. set byHAProxy itself). Thus, a common
configuration is to delete all existing X-Forwarded-For headers on
arrival and just setting the single new header using something like
reqidel ^X-Forwarded-For:.*
option forwardfor
If you need the client-supplied list, you would have to merge the list
at your final HTTP server nevertheless.
--Holger