Forwarded:

Forwarded: ヘッダー (HTTP)

[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

[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: が仕様から削除された後 SquidX-Forwarded-For: をかわりに使うようになりました。 他のもこれを実装した他、色々な関連ヘッダーを追加していきました。

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

X-Forwarded-*: を参照。

Forwarded: ヘッダー (10年代)

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

[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>