/
466.txt
332 lines (258 loc) · 15.5 KB
/
466.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
[16] [DFN[[CODE(HTTP)@en[[[Via:]]]]]] [[ヘッダー]]は、[[鯖]]と[[クライアント]]の間に[[中間器]]が存在することを示すものです。
[18] [CODE(HTTP)@en[[[Via:]]]] は、[[メッセージ]]の[[転送]]の追跡や、
[[要求]]のループの防止や、[[中間器]]の[[プロトコル]]能力のチェックに使うことができます
[SRC[>>17]]。
* 仕様書
[REFS[
- [17] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-5.7.1>'''
- [5] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-9.6>
- [44] [CITE@en[RFC 2326 - Real Time Streaming Protocol (RTSP)]] ([TIME[2014-04-06 08:10:59 +09:00]] 版) <http://tools.ietf.org/html/rfc2326#section-12.43>
- [40] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-06-22 04:16:34 +09:00]] 版) <http://tools.ietf.org/html/rfc3261#section-8.1.1.7>
- [41] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-06-22 04:16:34 +09:00]] 版) <http://tools.ietf.org/html/rfc3261#page-232>
]REFS]
* 文脈
[25] [[串]]は、[[メッセージ]]を[[転送]]する際に [CODE(HTTP)@en[[[Via:]]]]
[[ヘッダー]]を送信しなければ[['''なりません''']]。 [SRC[>>17]]
[26] [[HTTP]] から [[HTTP]] への[[関門]]は、[[内向き]]の[[要求メッセージ]]を[[転送]]する際に
[CODE(HTTP)@en[[[Via:]]]] [[ヘッダー]]を送信しなければ[['''なりません''']]。
また、[[外向き]]の[[応答メッセージ]]を[[転送]]する際に
[CODE(HTTP)@en[[[Via:]]]] [[ヘッダー]]を送信して構いません。 [SRC[>>17]]
[19] 複数の [CODE(HTTP)@en[[[Via:]]]] [[ヘッダー]]を指定することができます。
* 構文
[20] [[欄値]]は、1つ以上の値の[[リスト]] ([CODE[#]]) です [SRC[>>17]]。
[24] 複数の値が記述されている場合、それぞれの値が[[メッセージ]]を[[転送]]したそれぞれの[[串]]や[[関門]]を表します。
[[中間器]]は自身の情報を末尾に追記していくため、
[[転送]]が行われた順に並ぶことになります。 [SRC[>>17]]
[FIG(railroad)[
= 値
= *
== [[OWS]]
== [CODE[[[,]]]]
== [[OWS]]
== 値
]FIG]
[21] それぞれの値は、[[プロトコル]]、[[RWS]]、受信者、[[RWS]]、
[[注釈]]を並べたものです。ただし末尾の [[RWS]] と[[注釈]]は省略できます。 [SRC[>>17]]
[FIG(railroad)[
= プロトコル
= [[RWS]]
= 受信者
= ?
== [[RWS]]
== [[注釈]]
]FIG]
[22] [[プロトコル]]は、プロトコル名、[CODE[[[/]]]]、[[プロトコルの版]]を並べたものですが、
名前と [CODE[[[/]]]] は省略できます。省略された場合は [[HTTP]]
を表します。 [SRC[>>17]]
;; [43] [CODE(ABNF)@en[[[protocol]]]] 構文とは違って、[[プロトコルの版]]の側を省略することはできません。
;; [42] [[SIP]] ではどちらも省略できません [SRC[>>41]]。更に、
[CODE[[[/]]]] と[[トランスポート層プロトコル]]の名前も指定しないといけない [SRC[>>41]]
ことになっています。
[27] [[プロトコル]]は、[[メッセージ]]の[[上流]]の[[送信者]]が使ったものを示します。
[SRC[>>17]]
;; [39] [CODE(ABNF)@en[[[protocol]]]] も参照してください。
[23] 受信者は、 [CODE(HTTP)@en[[[Host:]]]] [[ヘッダー]]の[[欄値]]と同じような値か、
[RUBYB[ペンネーム]@en[pseudonym]]です。ペンネームは、[[字句]]です。
通常は転送を行う[[受信者]]の[[ホスト]]と[[ポート]]ですが、
これを晒したくない場合にはペンネームを使うことができます。
[[ポート]]が省略された場合には、指定された[[プロトコル]]の[[既定のポート番号]]と解釈して構いません。 [SRC[>>17]]
[FIG(railroad)[
= |
== =
=== ホスト
=== ?
==== [CODE(URI)[[[:]]]]
==== ポート
== ニックネーム
]FIG]
;; [30] [[ホスト]]は [[ASCII]] でなければなりません。 [[IDN]]
は [[Punycode]] 化する必要があります。
;; [31] [[ホスト]]とペンネームは、構文的に完全には区別できません。
ただ実用上は [[TLD]] が[[串]]になっていることは無いでしょう。
([[DNS]] 以外のシステムを使っているネットワークではあり得ますが...)
;; [6] この構文は [CODE(HTTP)@en[[[Warning:]]]] [[ヘッダー]]でも使われています。
しかし [CODE(HTTP)@en[[[Warning:]]]] における [CODE[-]] の用法は
[CODE(HTTP)@en[[[Via:]]]] には無いようです。
** 注釈
[28] [[注釈]]は、 [CODE(HTTP)@en[[[Server:]]]] や [CODE(HTTP)@en[[[User-Agent:]]]]
に相当するもので、[[受信者]]のソフトウェアを表します。 [SRC[>>17]]
[36] [[Guidelines for Web Content Transformation Proxies 1.0]] に従う[[串]]は、
[DFN[[CODE[[[http://www.w3.org/ns/ct]]]]]] という値の[[注釈]]を指定する[['''べきです''']]
[SRC[>>35]]。
[37] [[受信者]]は、[[注釈]]を削除してから[[転送]]して構いません [SRC[>>17]]。
;; [38] [[Guidelines for Web Content Transformation Proxies 1.0]] は、
現代の[[串]]でそのような処置は必要ないだろうと指摘し、
削除する[['''べきではない''']]としています [SRC[>>35]]。
* 処理モデル
[32] [[防火壁]]の出入口となっている[[中間器]]は、
明示的にそのように設定されている場合を除き、
[[防火壁]]内の[[ホスト]]や[[ポート]]を[[転送]]する[['''べきではありません''']]。
その場合には、[[防火壁]]内の[[ホスト]]は適当なペンネームに置き換える[['''べきです''']]。
[SRC[>>17]]
[33] [[中間器]]は、同じ[[プロトコル]]の値の列を結合しても構いません。
しかしそれは同じ組織の管理下にある場合で、既にペンネームに置き換えられている場合のみとする[['''べきです''']]。
異なる[[プロトコル]]のものを結合しては[['''なりません''']]。 [SRC[>>17]]
[EG[
[34] 例えば、
[PRE(HTTP example code)[
Via: 1.0 ricky, [MARK[1.1 ethel, 1.1 fred]], 1.0 lucy
]PRE]
... を
[PRE(HTTP example code)[
Via: 1.0 ricky, [MARK[1.1 mertz]], 1.0 lucy
]PRE]
... としても構いません [SRC[>>17]]。
]EG]
* 歴史
[FIG[
[FIGCAPTION[
[35] RFC 2068 (HTTP/1.1) 14.44; RFC 2616 (HTTP/1.1) 14.45 Via
]FIGCAPTION]
> 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 [INS[ [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] [CODE(HTTP)[Via]] 一般頭欄は、関門や串が、
[[利用者エージェント]]と要求先サーバー間の、
および源サーバーと応答の顧客間の媒介プロトコル及び受信者を示すために、
使用し'''なければなりません'''。
これは RFC 822 の [CODE(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] [CODE(HTTP)[[VAR(ABNF)[received-protocol]]]]
は要求・応答の鎖の各部分のサーバー或いはクライアントが受信したメッセージのプロトコルの版を示します。
[CODE(HTTP)[[VAR(ABNF)[received-protocol]]]]
の版は、メッセージが転送された時に
[CODE(HTTP)[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.
[CODE(HTTP)[[VAR(ABNF)[protocol-name]]]] は、
[CODE(HTTP)[[CODE(ABNF)["HTTP"]]]]
である場合に限って省略可能です。
[CODE(HTTP)[[VAR(ABNF)[received-by]]]]
欄は、通常、続けてメッセージを転送する、
受信したサーバー或いは顧客のホストと省略可能で[RUBY[港] [ポート]]番号です。
しかし、本当のホストが繊細な情報であると考えられる時は、 [CODE(HTTP)[[VAR(ABNF)[pseudonym]]]]
(偽名)に置き換えても構いません。港が無い場合、 [CODE(HTTP)[[VAR(ABNF)[received-protocol]]]]
の既定値と仮定しても'''構いません'''。
> Multiple Via field values represent[INS[s]] 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.
複数の [CODE(HTTP)[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.
受信した[[串]]や[[関門]]のソフトウェアを識別するために、
[CODE(HTTP)[[[User-Agent]]]] 頭欄や [CODE(HTTP)[[[Server]]]]
頭欄と同様に、 [CODE(HTTP)[Via]] 頭欄で[[注釈]]を使って'''構いません'''。
しかし、 [CODE(HTTP)[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]] 利用者エージェントから
[SAMP[fred]] という符号名の内部串に送られて、こいつが HTTP/1.1
を使ってその要求を [SAMP[nowhere.com]] の公開串に転送して、
こいつはそれを [SAMP[www.ucs.uci.edu]] の[[起源鯖]]に転送することで要求を完了したとします。
[SAMP[www.ucs.uci.edu]] がj苦心した要求はこの時次の [CODE(HTTP)[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.
ネットワーク防火壁をくぐる玄関口として使われる串や関門は、
既定では、防火壁領域内のホストの名前と[[ポート]]を転送する'''べきではありません'''。
この情報は、陽に有効にしたときのみつける'''べきです'''。
有効にしていなければ、防火壁内のすべての [CODE(ABNF)[received-by]] ホストは、
そのホストの適切な [CODE(ABNF)[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,
内部構造を隠す強い個人情報保護要件を持つ組織では、
串は、同一の [CODE(ABNF)[received-protocol]] 値の
[CODE(HTTP)[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.
応用は、複数の項目がすべて同じ組織の統制の元にあり、
ホストが既に [CODE(ABNF)[pseudonyms]] に置換されているのでない限り、
複数の項目を結合する'''べきではありません'''。応用は、異なる
[CODE(ABNF)[received-protocol]] 値の項目を結合しては'''なりません'''。
]FIG]
[REFS[
- [15] [CITE@en[Guidelines for Web Content Transformation Proxies 1.0]]
( ([TIME[2010-10-22 17:20:31 +09:00]] 版))
<http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/#sec-via-headers>
]REFS]
* 例
[EG[
[29] 例えば [[HTTP/1.0]] [[利用者エージェント]]が「fred」
という内部[[串]]に[[要求メッセージ]]を送信し、 fred
が [[HTTP/1.1]] により公開[[串]]「p.example.net」に[[転送]]し、
そこから更に[[起源鯖]]に[[転送]]された場合、
[[起源鯖]]が見る [CODE(HTTP)@en[[[Via:]]]] [[ヘッダー]]は、
[PRE(HTTP example code)[
Via: 1.0 fred, 1.1 p.example.net
]PRE]
... となります [SRC[>>17]]。
]EG]
[4] ''Comments on AgentGripes'' <http://web.archive.org/web/20011019120517/http://www.dais.is.tohoku.ac.jp/logs/comment.html#via>
[12]
[SAMP(HTTP)[Via: 1.1 cachesv539 (NetCache NetApp/5.5R5D3)]]
([[名無しさん]] [WEAK[2004-07-12 12:39:09 +00:00]])
[13] [CITE@en[HTTP/1.1 Via header]] ([TIME[2009-07-19 12:11:49 +09:00]] 版) <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
のようにプロトコル名が完全に省略されているもの (仕様違反) もありますね。
* Via: ヘッダー (電子メイル)
[2] [[電子メイル]]でも大昔に使われていたらしい。
** 例
[3] [SAMP(822)[Via: IBM-SJ; 25 Apr 83 19:09-PDT]]