On 2012-02-01 20:00, habeeb rahman wrote: > I know that apache comma separates the values for X-Forwarded-For and I > thought haproxy behaves the same.
Both types are semantically the same. So for an application, it shouldn't matter if you get these headers X-Forwarded-For: 10.10.10.10 X-Forwarded-For: 192.168.1.1 or this one X-Forwarded-For: 10.10.10.10, 192.168.1.1 Both formats have to be treated exactly the same according to the RFC. What you now observe are two different implementations which both conform to the RFC. Apache normalizes the X-Forwarded-For header to a comma-separated list, HAProxy doesn't. Both variants are perfectly valid and semantically (although not syntactically) identical. Again, for your application to conform to the RFC, you have to accept both types and have to parse them properly. Most application servers already do that for you. If your doesn't, you have to parse it yourself. > 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 :) The important part of the quote was 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. Ant hat is exactly what you see here. "field-value" in this case refers to a comma-seprated list. It must be possible to combine headers with multiple values into such a list, but it is not expected that it is always done. But if in doubt, please refer to the RFC yourself :) http://tools.ietf.org/html/rfc2616 Section 4.2 --Holger
