Via:

Via: ヘッダー (HTTP)

[16] Via: ヘッダーは、クライアントの間に中間器が存在することを示すものです。

[18] Via: は、メッセージ転送の追跡や、 要求のループの防止や、中間器プロトコル能力のチェックに使うことができます >>17

仕様書

文脈

[25] は、メッセージ転送する際に Via: ヘッダーを送信しなければなりません>>17

[26] HTTP から HTTP への関門は、内向き要求メッセージ転送する際に Via: ヘッダーを送信しなければなりません。 また、外向き応答メッセージ転送する際に Via: ヘッダーを送信して構いません。 >>17

[19] 複数の Via: ヘッダーを指定することができます。

構文

[20] 欄値は、1つ以上の値のリスト (#) です >>17

[24] 複数の値が記述されている場合、それぞれの値がメッセージ転送したそれぞれの関門を表します。 中間器は自身の情報を末尾に追記していくため、 転送が行われた順に並ぶことになります。 >>17

  1. *
    1. OWS
    2. ,
    3. OWS

[21] それぞれの値は、プロトコルRWS受信者RWS注釈を並べたものです。ただし末尾の RWS注釈は省略できます。 >>17

  1. プロトコル
  2. RWS
  3. 受信者
  4. ?
    1. RWS
    2. 注釈

[22] プロトコルは、プロトコル名、/プロトコルの版を並べたものですが、 名前と / は省略できます。省略された場合は HTTP を表します。 >>17

[43] protocol 構文とは違って、プロトコルの版の側を省略することはできません。
[42] SIP ではどちらも省略できません >>41。更に、 /トランスポート層プロトコルの名前も指定しないといけない >>41 ことになっています。

[27] プロトコルは、メッセージ上流送信者が使ったものを示します。 >>17

[39] protocol (HTTP)プロトコルの版も参照してください。

注釈

[28] 注釈は、 Server:User-Agent: に相当するもので、受信者のソフトウェアを表します。 >>17

[36] Guidelines for Web Content Transformation Proxies 1.0 に従うは、 http://www.w3.org/ns/ct という値の注釈を指定するべきです >>35

[37] 受信者は、注釈を削除してから転送して構いません >>17

[38] Guidelines for Web Content Transformation Proxies 1.0 は、 現代のでそのような処置は必要ないだろうと指摘し、 削除するべきではないとしています >>35

処理モデル

[32] 防火壁の出入口となっている中間器は、 明示的にそのように設定されている場合を除き、 防火壁内のホストポート転送するべきではありません。 その場合には、防火壁内のホストは適当なペンネームに置き換えるべきです>>17

[33] 中間器は、同じプロトコルの値の列を結合しても構いません。 しかしそれは同じ組織の管理下にある場合で、既にペンネームに置き換えられている場合のみとするべきです。 異なるプロトコルのものを結合してはなりません>>17

[34] 例えば、

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
... を
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
... としても構いません >>17

歴史

Via: ヘッダー (電子メイル)

[2] 電子メイルでも大昔に使われていたらしい。

関連

[46] Received: も参照。

[3] Via: IBM-SJ; 25 Apr 83 19:09-PDT

HTTP への導入

[7] Via: は初期の HTTP で提案されていた Forwarded: のかわりとして導入されました。

[8] 当時の経緯は Forwarded: を参照。
[10] その後新たに Forwarded: が追加されています。
[35] RFC 2068 (HTTP/1.1) 14.44; RFC 2616 (HTTP/1.1) 14.45 Via

The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 [9] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.

[1] Via 一般頭欄は、関門や串が、 利用者エージェントと要求先サーバー間の、 および源サーバーと応答の顧客間の媒介プロトコル及び受信者を示すために、 使用しなければなりません。 これは RFC 822 の Received 欄に対応していて、 メッセージの転送の追跡や要求の循環の回避, 要求・応答の鎖に居る全ての送信者のプロトコル能力の特定に使うことを目的としています。

  • Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
  • received-protocol = [ protocol-name "/" ] protocol-version
  • protocol-name = token
  • protocol-version = token
  • received-by = ( host [ ":" port ] ) | pseudonym
  • pseudonym = token

The received-protocol indicates the protocol version of the message received by the server or client along each segment of the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded so that information about the protocol capabilities of upstream applications remains visible to all recipients.

[11] received-protocol は要求・応答の鎖の各部分のサーバー或いはクライアントが受信したメッセージのプロトコルの版を示します。 received-protocol の版は、メッセージが転送された時に Via 欄の値に追加されるので、 上流応用のプロトコル能力についての情報が全ての受信者に見えたままになります。

The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol.

protocol-name は、 "HTTP" である場合に限って省略可能です。 received-by 欄は、通常、続けてメッセージを転送する、 受信したサーバー或いは顧客のホストと省略可能で (ポート) 番号です。 しかし、本当のホストが繊細な情報であると考えられる時は、 pseudonym (偽名)に置き換えても構いません。港が無い場合、 received-protocol の既定値と仮定しても構いません

Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications.

複数の Via 欄値は、 メッセージを転送した各串・関門を表します。 各受信者はその情報を後置して、結果として転送した応用の順に並ぶように しなければなりません

Comments MAY be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional and MAY be removed by any recipient prior to forwarding the message.

受信した関門のソフトウェアを識別するために、 User-Agent 頭欄や Server 頭欄と同様に、 Via 頭欄で注釈を使って構いません。 しかし、 Via 欄内のすべての注釈は省略可能であり、 どの受信者もメッセージの転送の前に削除して構いません

For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:

例えば、要求メッセージが HTTP/1.0 利用者エージェントから fred という符号名の内部串に送られて、こいつが HTTP/1.1 を使ってその要求を nowhere.com の公開串に転送して、 こいつはそれを www.ucs.uci.edu起源鯖に転送することで要求を完了したとします。 www.ucs.uci.edu がj苦心した要求はこの時次の Via 頭欄を持ちます:

  • Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Proxies and gateways used as a portal through a network firewall SHOULD NOT, by default, forward the names and ports of hosts within the firewall region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall SHOULD be replaced by an appropriate pseudonym for that host.

ネットワーク防火壁をくぐる玄関口として使われる串や関門は、 既定では、防火壁領域内のホストの名前とポートを転送するべきではありません。 この情報は、陽に有効にしたときのみつけるべきです。 有効にしていなければ、防火壁内のすべての received-by ホストは、 そのホストの適切な pseudonym で置換するべきです

For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example,

内部構造を隠す強い個人情報保護要件を持つ組織では、 串は、同一の received-protocol 値の Via 頭欄項目の順序付き並びを一つの項目に結合して構いません。 例えば、

  • Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

could be collapsed to

  • Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

とまとめることができます。

Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values.

応用は、複数の項目がすべて同じ組織の統制の元にあり、 ホストが既に pseudonyms に置換されているのでない限り、 複数の項目を結合するべきではありません。応用は、異なる received-protocol 値の項目を結合してはなりません

[48] X-Connfrom:持続的接続その他の HTTP 追加機能にが対応しているか明示させるために新たなヘッダーを導入し、 ホスト名や機能を列挙させるという提案でした。

[49] Via: ヘッダーと似ていますが、なぜか言及はありません。

関連

[45] X-Forwarded-*:Forwarded: も参照。

[29] 例えば HTTP/1.0 利用者エージェントが「fred」 という内部要求メッセージを送信し、 fred が HTTP/1.1 により公開「p.example.net」に転送し、 そこから更に起源鯖転送された場合、 起源鯖が見る Via: ヘッダーは、

Via: 1.0 fred, 1.1 p.example.net
... となります >>17

[4] Comments on AgentGripes http://web.archive.org/web/20011019120517/http://www.dais.is.tohoku.ac.jp/logs/comment.html#via

[12] Via: 1.1 cachesv539 (NetCache NetApp/5.5R5D3) (名無しさん 2004-07-12 12:39:09 +00:00)

[13] HTTP/1.1 Via header ( 版) http://www.http-stats.com/Via

[14] >>13 ほとんどは protocol-name を省略していますが、

  • Via: HTTP/1.1 10.86.124.17 (IBM-PROXY-WTE)
  • Via: HTTP/1.1 ootemachi2-ci2 (Traffic-Server/5.2.1a-fj [c s f ])

のように省略していないものや

  • Via: CN-5000, CN-5000

のようにプロトコル名が完全に省略されているもの (仕様違反) もありますね。

[47] [MS-SIPRE]: Via Header Field Extensions ( ( 版)) http://msdn.microsoft.com/en-us/library/dd906564(v=office.12).aspx

[50] Session Initiation Protocol (SIP) Parameters ( ( 版)) http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12

[51] RFC 8055 - Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm () https://tools.ietf.org/html/rfc8055

[6]

Server: deno/gcp-asia-northeast2
Via: http/2 edgeproxy