Jim, Thanks, I've raised the issue with tomcat users and they recommended to create a bugzilla entry, which I will do. I will also point them to this mailing list for the definition.
I'm using stunnel so the second suggestion won't work. The most simple and obvious solution is to use a different header that won't be used elsewhere - but that's a work-around. Thanks for your help. On 10 December 2010 13:30, Jim Riggs <[email protected]>wrote: > 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.) > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > -- Best Regards, Brett Delle Grazie
