(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 > >
