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
