IETF RFC 2616 Section 4.2 allows a request to contain multiple headers with the same field-name as long as chronological order of insertion is preserved and their values can be converted into single header with a comma-separated list of values.
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. F5 will not overwrite any existing X-Forwarded-For. Nor will it concatenate existing X-Forwarded-For into a single comma-separated value. Instead, it will insert an additional X-Forwarded-For at the tail end of the collection.
But what about an environment with multiple clients, proxies, CDNs, traffic-managers, servers that engage in manipulation of the
X-Forwarded-For collection ?
There would seem to be an advantage to enforcing a uniform practice. But what is the best practice ?
F5 BIG-IP default http profile insert header accumulates an additional
X-Forwarded-For at the end of a request's pre-existing collection of XFF headers, preserving order.
AWS ELB encourages consolidation of an incoming request's multiple
X-Forwarded-For into a single header containing a comma-delimited list of XFF IPs, plus the user host address, preserving order.
Other devices may employ other variations.
Does there exist an agreed-upon recommendation or de facto standard for heterogeneous environments ?
Further, is any timestamp data provided that would allow code to definitively sort
X-Forwarded-For headers in chronological order of addition for the case where previous manipulations of XFF headers are suspect.