On Dec 10, 2010, at 6:42 AM, Brett Delle Grazie wrote: > Hi, > > I'm using HAproxy 1.4.8 on RHEL5 (fully up-to-date). > I'm using the 'option forwardfor' > > In certain circumstances, the client has already got an X-Forwarded-For > header in the request. > > HAproxy in this instance adds a second X-Forwarded-For header rather than > extending the existing header. > > This causes a problem on our Tomcat backend because the RemoteIP valve (part > of Tomcat) that is used appears to examine only the first header. > > 1. Is there some way to get HAproxy to extend the existing X-Forwarded-For > header rather than adding a new one > > 2. Does the stunnel patch do the same thing or does it extend the existing > X-Forwarded-For header?
It sounds like this is an issue with the RemoteIP valve. (I haven't looked at its code yet.) According to the HTTP spec, headers that allow multiple values can be specified as either a comma-separated list or multiple separate headers: "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." That is, the following are semantically equivalent according to the HTTP spec: X-Forwarded-For: 192.168.100.123 X-Forwarded-For: 127.0.0.1 and X-Forwarded-For: 192.168.100.123, 127.0.0.1 In fact, proxies and caches may make these changes in-flight. If you don't need the client's existing X-Forwarded-For information and can't wait for a Tomcat fix, you can always do a `reqidel ^X-Forwarded-Proto:.*' in your haproxy config. Then the only XFF header you will get in Tomcat will be from haproxy. (This may cause issues if you're using stunnel, though.)
