x-forwarded-forヘッダーをチェーンするための標準はありますか？
IETF RFC 2616セクション4.2では、挿入の時系列順が保持され、値のコンマ区切りリストを使用してそれらの値を単一のヘッダーに変換できる限り、同じフィールド名を持つ複数のヘッダーを要求に含めることができます。
http://tools.ietf.org/html/rfc2616#section-4.2
同じフィールド名のメッセージヘッダーフィールドは、そのヘッダーフィールドのフィールド値全体がコンマ区切りのリストとして定義されている場合にのみメッセージに存在する場合があります[つまり、＃（values）]。メッセージのセマンティクスを変更せずに、後続の各フィールド値を最初のフィールド値にコンマで区切って追加することにより、複数のヘッダーフィールドを1つの「フィールド名：フィールド値」ペアに結合できる必要があります。したがって、同じフィールド名を持つヘッダーフィールドが受信される順序は、結合されたフィールド値の解釈にとって重要であり、したがって、プロキシは、メッセージが転送されるときにこれらのフィールド値の順序を変更してはなりません。 F5は既存のX-Forwarded-Forを上書きしません。また、既存のX-Forwarded-Forを単一のコンマ区切り値に連結することもしません。代わりに、コレクションの末尾に追加のX-Forwarded-Forを挿入します。
しかし、X-Forwarded-Forコレクションの操作に従事する複数のクライアント、プロキシ、CDN、トラフィックマネージャー、サーバーがある環境はどうでしょうか。
統一された慣行を実施することには利点があるように思われます。しかし、ベストプラクティスは何ですか？
F5 BIG-IPのデフォルトのhttpプロファイル挿入ヘッダーは、リクエストの既存のXFFヘッダーのコレクションの最後に追加のX-Forwarded-Forを蓄積し、順序を維持します。
AWS ELBは、着信リクエストの複数のX-Forwarded-Forを、XFF IPのコンマ区切りリストとユーザーホストアドレスを含む単一のヘッダーに統合し、順序を維持することを推奨します。
他のデバイスは他のバリエーションを採用する場合があります。
異機種混在環境に関する合意済みの推奨事項または事実上の標準はありますか？
さらに、XFFヘッダーの以前の操作が疑われる場合に、コードがX-Forwarded-Forヘッダーを追加の時系列順に確実にソートできるようにするタイムスタンプデータが提供されていますか。
はい、標準があります。X-Forwarded-Forを使用しないでください。
RFC 7239 は、X-Forwarded-Forとは異なるセマンティクスを持つForwardedヘッダーを定義し、新しい実装ではそれを使用する必要があります。残念ながら、X-Forwarded-For hereで特定したのと同じ問題が発生します。リクエストで2回定義されているか、カンマ区切りの値のリストが含まれている可能性があります。プロキシはそれを完全に削除することもできます。
そして、はい、ベストプラクティスがあります。内部で別のヘッダー名を使用します。
X-Forwarded-Forとその置換Forwardedにはuntrusted inputが含まれていることに注意してください。クライアントがそのようなヘッダーに好きなものを入れるのは簡単です。サーバーに接続されているもののパブリックIPアドレスを本当に知る必要がある場合は、別のヘッダーに貼り付けてください。たとえば、CloudFlareはこの目的でCF-Connecting-IPを使用します。また、nginx（必要なものを定義できる）で使用されるClient-IPとX-Real-IPを見てきました。どの名前を使用する場合でも、ロードバランサーは、X-Forwarded-ForまたはForwarded以外のsomeヘッダーでリクエスターのIPアドレスを送信する必要があります。