/
349.txt
84 lines (59 loc) · 5.17 KB
/
349.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
[1] [DFN[[RUBYB[[[接続序文]]]@en[connection preface]]]]は、 [[HTTP/2接続]]の最初に送信する[[バイト列]]です。
* 仕様書
[REFS[
- [15] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-3>
-- [2] '''[CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-3.5>'''
- [12] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-10.2>
- [13] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-11.6>
]REFS]
* 意味
[4] [[クライアント]]と[[サーバー]]は、使っている[[プロトコル]]の最終確認と
[[HTTP/2接続]]の初期設定の確立のため、[[接続序文]]を送信する必要があります [SRC[>>2]]。
* 構文
[5] [DFN[クライアント接続序文]]は、次の24バイトの列です [SRC[>>2]]。
[FIG[
[CODE[0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a]]
]FIG]
;; [6] これは、 [CODE[[[PRI]] [[*]] [[HTTP/2.0]]\r\n\r\nSM\r\n\r\n]] を表しています [SRC[>>2]]。
大部分の [[HTTP/1.1]] や [[HTTP/1.0]] の[[サーバー]]や[[中間器]]が以後の[[フレーム]]を処理しようとしなくなるものが選ばれました [SRC[>>2]]。
[CODE[[[PRI]]]] は本目的のためのダミーの[[要求メソッド]]です [SRC[>>13]]。
[[HTTP]] 以外のプロトコルへの [[cross-protocol attack]] を防ぐものではありません [SRC[>>12]]。
;; [14] なお [[WebSocket]] は、 [[WebSocket]] データを [[HTTPメッセージ]]と解釈する壊れた[[中間器]]への対処のため、[[クライアント]]からの[[フレーム]]を[[マスク]]することにしています。
[[HTTP/2]] はこの問題に対処していません [SRC[>>2]]。ということは [[HTTP/2]] over [[TCP]]
は利用環境によっては脆弱かもしれません。
[7] [[クライアント]]はこの直後に [CODE[[[SETTINGS]]]] [[フレーム]]を送信しなければ[['''なりません''']] [SRC[>>2]]。
この[[フレーム]]は空でも構いません [SRC[>>2]]。
;; [10] [[クライアント]]は、[[サーバー接続序文]]を待たずに次の[[フレーム]]を送り始めても構いません。
しかし[[サーバー]]の [CODE[[[SETTINGS]]]] [[フレーム]]には期待される[[クライアント]]の動作が指定されているかもしれません。その受信後は、
それに従うことが期待されます。 [SRC[>>2]]
[8] [DFN[サーバー接続序文]]は、 [CODE[SETTINGS]] [[フレーム]]です。
この[[フレーム]]は空でも構いません [SRC[>>2]]。
* 文脈
[3] [[HTTP/2接続]]の最初に[[クライアント]]と[[サーバー]]がそれぞれ送信します [SRC[>>15]]。
;; 詳しくは [[HTTP/2接続]]や [[HTTPS]] を参照。
[16] [[クライアント接続序文]]と[[サーバー接続序文]]は、互いの到着を待たずに送信できます。
* 処理
[11] 妥当でない[[接続序文]]を受信したら、[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]]
としなければ[['''なりません''']]。 [[peer]] が [[HTTP/2]]
では無いので、 [CODE[[[GOAWAY]]]] [[フレーム]]は省略しても構いません。 [SRC[>>2]]
[9] [[peer]] から[[接続序文]]の一部として送信された [CODE[[[SETTINGS]]]]
[[フレーム]]を受信したら、自身の[[接続序文]]を送信した後、 [[acknowledge]]
しなければ[['''なりません''']] [SRC[>>2]]。
[17] [[Chrome]] でも [[Firefox]] でも、[[接続序文]]の [CODE[[[SETTINGS]]]]
として受信するフレームは [CODE[[[ACK]]]] フラグが設定されていてもいなくても良いようです。
[TIME[2015-10-11T11:16:58.000Z]]
[18] [[接続序文]]についてエラーがあった時、[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]]
とするようです。 [CODE[[[GOAWAY]]]] [[フレーム]]は送られないことが多いようですが、
既知[[フレーム]]のように見えてエラーの時は送られるようです。しかしその条件は
[[Firefox]] と [[Chrome]] で一致していないようです。 [TIME[2015-10-11T11:21:06.700Z]]
[19] [[Chrome]] も [[Firefox]] も[[接続序文]]の受信を待たずに最初の[[要求]]を送信します。
[[接続序文]]の特別なタイムアウトは無いようで、 [[Firefox]] は定期的な [CODE[[[PING]]]]
の送信に返答がなければ[[接続エラー]] [CODE[[[INTERNAL_ERROR]]]] とします。
[TIME[2015-10-11T11:27:21.300Z]]
* 実装
[20] [[Firefox]] は、 [CODE[[[SETTINGS_INITIAL_WINDOW_SIZE]]]] = 131072
と [CODE[[[SETTINGS_MAX_FRAME_SIZE]]]] = 16384 = 2[SUP[14]] (= 初期値) を送信します。
[TIME[2015-10-20T08:14:56.300Z]]
[21] [[Chrome]] は、 [CODE[[[SETTINGS_MAX_CONCURRENT_STREAMS]]]] = 1000
と [CODE[[[SETTINGS_INITIAL_WINDOW_SIZE]]]] = 6291456 を送信します。
[TIME[2015-10-20T08:15:53.200Z]]