[27] Forwarded: ヘッダーは、 要求を串によって転送した際の情報を表すものです。

仕様書

意味

[10] Forwarded: ヘッダーは、 要求の経路上で串が関わった際に書き換えられたり失われたりした情報を明かすものです >>8。

[16] ただしこのヘッダーを追加することは必須の要件とはされていません。 串を通過した要求でもこのヘッダーが無いかもしれませんし、 このヘッダーがあったとしてもすべての串が示されているとは限りません。

構文

[15] Forwarded: ヘッダーの値は、 1つ以上の要素のリスト (#) です >>8。 リスト内の各要素は要求を処理した順序を表しており、 最初の要素が最初に要求を処理した (Forwarded: を送信するよう設定されている) 串、最後の要素が最後に要求を処理した串です >>8。

  1. 要素
  2. *
    1. OWS
    2. ,
    3. OWS
    4. 要素

[18] 各要素は ; 区切りの0個以上の項目 (引数) のリストです >>8。

  1. ?
    1. 引数
  2. *
    1. ;
    2. ?
      1. 引数
[24] ; の前後に空白は認められていないようです。

[21] 引数は名前と値を = で連結したものまたは空文字列です。 >>8

[19] 引数の名前は字句で、大文字・小文字不区別です >>8。

[20] 引数の値は字句または引用文字列です >>8。

  1. 字句
  2. =
  3. |
    1. 字句
    2. 引用文字列
[23] = の前後に BWS は認められていないようです。

[22] ある要素中に同名の引数を複数指定してはなりません >>8。

引数

[28] 次の引数があります。

[41] 引数の IANA登録簿 >>40 もあります。

[30] 引数は IANA に登録するべきです。広く使われるであろうものは標準化するべきです。 >>29

文脈

[13] このヘッダーは通常の串でも逆串でも使えます >>8。

[11] このヘッダーは繊細なデータを伝えるものですから、 既定では無効とするべきshouldです。また各引数はそれぞれ個別に設定できるべきshouldです。 >>8

[12] このヘッダーは応答では使いません >>8。

[17] このヘッダーは複数指定できます。

処理モデル

[26] 串は、新しい Forwarded: ヘッダーをヘッダー部の末尾に付け加えることもできますし、 既存の Forwarded: ヘッダーの末尾に , と共に付け加えることもできます >>8。

[14] 串は既存の Forwarded: ヘッダーを削除することもできます >>8。

歴史

Forwarded: ヘッダー (90年代)

[2] Forwarded: は初期の HTTP 仕様案において電子メールの Received: ヘッダーに近い形で定義されていました >>7。 一時は実装されていましたが (>>3, >>1)、機能を削って Via: に置き換えられました >>6。

  • [7] draft-ietf-http-v10-spec-01 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/draft-ietf-http-v10-spec-01#section-8.14
  • [6] HTTP-wg Archive: Via Header Field (replaces Forwarded) ( 版) http://www.hpl.hp.com/personal/ange/archives/archives-96/http-wg-archive/0725.html
[3] Nonstandard HTTP Headers http://web.archive.org/web/20020610043404/http://www.dais.is.tohoku.ac.jp/~kabe/WWW/nonstdhdr.html#Forwarded

Forwarded: by proxy-URI [(product)] [for client-FQDN]

draft-ietf-http-v10-spec-01.txt および draft-ietf-http-v11-spec-01.txt までの HTTP-draft に出現。 標準化に際しては 「冗長である」 という理由から Via: に置き換わっています。 "for ..." 部分は Via: から削られたため、Squid では代わりに X-Forwarded-For ヘッダを新設しました。 (当時まじめにDraft等を追っかけていたのは Squid くらいだったような気が)

[1] Netscape Proxy が仕様書から削除された後も Forwarded: を実装していたようです。

X-Forwarded-*: ヘッダー群

[9] Forwarded: が仕様から削除された後 Squid は X-Forwarded-For: をかわりに使うようになりました。 他の串もこれを実装した他、色々な関連ヘッダーを追加していきました。

[42] Forwarded-For: を標準化する提案もありましたが、 これが Forwarded: になりました。

X-Forwarded-*: を参照。

Forwarded: ヘッダー (10年代)

  • [4] draft-petersson-forwarded-for-02 - Forwarded HTTP Extension ( ( 版)) http://tools.ietf.org/html/draft-petersson-forwarded-for-02
  • [5] RFC 7239 - Forwarded HTTP Extension ( 版) https://tools.ietf.org/html/rfc7239

[33] Via: は既に広く用いられているため、これを拡張するわけにはいかなかった >>32 とされています。

関連

[34] Via: は用途が似ており歴史的関連性もありますが、 Via: のみ追加されることや Forwarded: のみ設定されることがあるので、 両者を対応付けることはできません >>32。

[35] 串は、要求に X-Forwarded-*: が含まれている場合、 可能なら Forwarded: に変換することが推奨encourageされています >>36。

[37] しかし、例えば X-Forwarded-For: と X-Forwarded-By: がどのような順序で追加されたかはわかりませんし、 X-Forwarded-For: を削除すると転送先で互換性の問題が生じるかもしれません >>36。要求がどのような経路でその串まで到達したかわかっている場合を除き、 厳密には X-Forwarded-*: をどう変換するべきか決定できません。 X-Forwarded-*: の主たる用途である逆串では要求の到達経路を何ら過程できませんから、 実用上この変換はできないと思われます。

[38] また X-Forwarded-*: を削除して Forwarded: を追加する実装や削除しないで追加する実装、あるいは Forwarded: を追加しない旧来の実装が混在する (あるいはいずれであるか事前に決定できない) 場合、 受信者の処理は Forwarded: が追加されたせいで極めて複雑になります。

[39] 参考画像: xkcd: Standards ( 版) http://xkcd.com/927/

例

[25] 次のような例が示されています >>8。

Forwarded: for="_gazonk"
Forwarded: For="[2001:db8:cafe::17]:4711"
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
Forwarded: for=192.0.2.43, for=198.51.100.17

メモ

[31] RFC 7239 の規定は情報の漏洩を防ぐために過剰に配慮しすぎているように見えます。 但し書きを適用しない限り、ほとんど実用に耐えない気がしますが・・・。 (例えば逆串が付与する for が IPアドレスではなく難読化識別子になっていたら、 裏側のアプリケーション鯖にとっては無用の長物でしかありません。) そもそもが必須の機能ではないのに、何重にも保護する必要はどこにあるのでしょうかね。

[43] [SPR-11856] ServletUriComponentsBuilder should consider RFC-7239 Forwarded header - Spring JIRA ( ( 版)) https://jira.spring.io/browse/SPR-11856

[44] RFC 7239 - Implement Forward Header · Issue #36 · dstufft/fenrir ( ( 版)) https://github.com/dstufft/fenrir/issues/36

[45] RFC 8165 - Design Considerations for Metadata Insertion () https://tools.ietf.org/html/rfc8165#section-5