Forwarded HTTP Extension Insertion (RFC 7239)

This irule appears to violate RFC 7239. According to section 4 of RFC 7239, "The first element in this list holds information added by the first proxy that implements and uses this header field, and each subsequent element holds information added by each subsequent proxy." Also see section 7.5 of the RFC 7239 for an example of multiple proxy usage.

At the time this rule fires, the F5 is the last proxy in the chain, and therefore all of the information the F5 adds should be placed at the end of the Forwarded list. However, as written this rule splits the information, incorrectly placing the "for" element at the start of the list while correctly placing the "proto", "host", and "by" elements at the end.

To fix this bug, line 33 (lappend FFOR_HEADER_LIST "for=$CLIENT_ADDR") should be moved to just before line 56 (set FFOR_HEADER [join $FFOR_HEADER_LIST ","]). That way the $KEEP_FORWARDED_FOR and $CONVERT_XFF_TO_FORWARDED_FOR blocks include the information added by the earlier proxies before the F5's "for" information is appended.

Note that if you don't enable the KEEP_FORWARDED_FOR or CONVERT_XFF_TO_FORWARDED_FOR options or you enable them but your incoming requests don't have Forwarded or X-Forwarded-For headers to keep, you won't see the bug, because there will be nothing to go between the misplaced "for" element and the correctly placed "proto", "host", and "by" elements.

Also note that if you opt to enable both the KEEP_FORWARDED_FOR and CONVERT_XFF_TO_FORWARDED_FOR options, the resultant Forwarded header may have out of order entries. This, however, isn't a fault of this rule. It is an unavoidable byproduct of mixing two different headers that work independently of each other.