FYI, Bug raised for Tomcat: 50453 https://issues.apache.org/bugzilla/show_bug.cgi?id=50453
Regards, Brett On 10 December 2010 14:15, Brett Delle Grazie <[email protected]>wrote: > 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 > > -- Best Regards, Brett Delle Grazie
