"Dave Steinberg" <[email protected]> wrote in message news:[email protected]... > Saumil Shah wrote: >> Greetings, >> >> The expected format for all XFF headers is that there's only ONE XFF >> header. Every proxy server appends the client IP to the end of the >> XFF IP list. > > Not so! RFC 2616, section 4.2 says: > > 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. > > So pound's implementation is in accordance with the standard. Most > webservers do the munge-to-one-field operation before log parsers or > applications see it, so I don't think there's any issue.
Sorry for reopening an old thread, but I was just looking into this and noticed the same thing that the original poster found; that instead of appending the source's IP to the XFF header, it creates a new one. While Dave's interpretation of the standard may seem correct, there is a significant problem with Pound's implementation. Given that there is no official XFF standard, we need to look at the de facto standard for XFF. All other proxy's and LBs seem to append the last source IP to the XFF in a comma-delimited string. By Pound not doing the same thing, and instead creating a new XFF header, I see 2 problems. 1) There is no way to know the exact sequence of the headers. 2) Any downstream proxy / LB may not append the source IP to the correct XFF header. Consequently, given two XFF headers, there is no way to accurately reconstruct the sequence of proxy/lb IPs. For example: XFF: 198.20.123.123, 10.1.1.1, 192.168.1.17, 169.123.1.1 In this instance, we know that the client IP was 198.20.123.123 and can see the order of the LB/Proxys: (ie: first was 10.1.1.1, then 192.168.1.7, then 169.123.1.1). If we look at an example using pound, you might get XFF: 198.20.123.123, 192.168.1.17 XFF: 10.1.1.1 XFF: 169.123.1.1 Can you still accurately reconstruct the sequence of Proxy/LB's? I would strongly vote for updating Pound's use of the XFF to be more compliant with the defacto standard that most other LB/Proxy's seem to follow. Is there an area where one can post bug requests / fixes / etc? Thanks, Eric -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
