[5] [[HTTP]] の [DFN[[CODE(HTTP)@en[[[CONNECT]]]] [[メソッド]]]]は、 [[プロキシ]]をすり抜ける[[トンネル]]を確立することを求めるものです。 [47] この[[メソッド]]は [[HTTPS]] 通信が[[プロキシ]]を通過するために使われています。 * 仕様書 [REFS[ - [49] '''[CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) ''' - [45] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [10] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) - [12] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) - [32] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) ]REFS] * 意味 [50] [CODE(HTTP)@en[[[CONNECT]]]] [[メソッド]]は、 [[要求対象]]によって識別される[[起源鯖]]を出口とする[[トンネル]]を確立し、 成功した場合には、[[トンネル]]が閉じられるまでの間、 [[パケット]]を盲目的に[[転送]]するだけの動作をすることを[[受信者]]に対して[[要求]]するものです [SRC[>>49]]。 [FIG(sequence)[ :C:[[クライアント]] :P:[[串]] :S:[[鯖]] :C -> P:[[鯖]]への [CODE(HTTP)@en[[[CONNECT]]]] [[要求]] :P ## S:[[接続]]の確立 :P -> C:[CODE(HTTP)[[[200]]]] [[応答]] :C ## S:以後[[串]]は無変更で[[鯖]]・[[クライアント]]間を中継 :C ## S:[[串]]は一方の[[接続]]が閉じられたら、他方の[[接続]]も閉じる ]FIG] [65] [CODE(HTTP)@en[[[CONNECT]]]] は、動作としては [CODE(HTTP)@en[[[Upgrade:]]]] による[[プロトコル]]の切り替えと然程違いません。どちらも一旦切り替えられると元の [[HTTP]] とは異なる[[プロトコル]]の規定に支配される[[接続]]となり、 基本的に元の [[HTTP]] に戻ってくることはできません。それでも [CODE(HTTP)@en[[[Upgrade:]]]] は理論上は元の[[要求]]の処理を[[鯖]]が新しい[[プロトコル]]で継続することが期待されるのに対し、 [CODE(HTTP)@en[[[CONNECT]]]] は新しい[[プロトコル]]ではじめから通信が始まることが期待されています。 また [CODE(HTTP)@en[[[Upgrade:]]]] は[[受信者]]である[[鯖]]が直接処理することを期待されているのに対し、 [CODE(HTTP)@en[[[CONNECT]]]] は[[受信者]]自身ではなく中継された先にあるはずの[[鯖]]が処理することが期待されているという大きな違いがあります。 [14] [CODE(HTTP)@en[[[CONNECT]]]] [[メソッド]]は、主として [[HTTP]] [[プロキシ]]を通して [CODE(URI)@en[[[https]]]] [[資源]]にアクセスするために[[起源サーバー]]との間に [[TLSセッション]]を確立するために使います [SRC[>>12]]。 ;; [15] [[RFC 7540]] は [CODE(HTTP)@en[[[CONNECT]]]] のことを 「[RUBYB[疑似メソッド]@en[pseudo-method]]」と呼んでおり [SRC[>>12]]、 それがどういう意味かは不明ですが、通常の[[要求メソッド]]とは性質が違うことをほのめかしています。 [16] [[HTTP/2]] では [CODE(HTTP)@en[[[CONNECT]]]] [[メソッド]]は、 ([[接続]]全体ではなく) [[ストリーム]]において[[トンネル]]を確立するために使います [SRC[>>12]]。 -*-*- [48] このような動作をするものは一般的には[[プロキシ]]と呼ばれていますが、 [[RFC 7230]] の用語では[[中間器]]の一種である[[トンネル]]に分類されています。 * 文脈 [75] [CODE[CONNECT]] [[メソッド]]は、 [[HTTPS]] の通信に[[プロキシ]]を通過させたい時に使われます。 [76] [[素のHTTP]]の[[プロキシ]]は、[[プロキシ]]に[[素のHTTP]]で接続し、 [[プロキシ]]がこれを一旦解釈してから接続先の[[サーバー]]へと中継します。 しかし、これと同じ方法では [[HTTPS]] の [[TLS]] の目的である[[盗聴]]や[[改竄]]の防止が実現できません ([[プロキシ]]の挙動は[[盗聴]]と[[改竄]]そのものだからです)。 そのため、[[プロキシ]]がデータを無条件に中継し何の解釈も行わない[[トンネル]]モードへと [CODE[CONNECT]] [[メソッド]]で切り替えてから、 [[TLS]] で[[サーバー]]との間を結ぶ方法を採るのです。 [78] [[プロトコル]]の階層関係を図にすると、次のようになります。 [FIG[ [PRE[ <----------------- HTTP ----------------> <----------------- TLS -----------------> <- HTTP (CONNECT) -> <------ TCP -------> <------ TCP -------> クライアント プロキシ サーバー ]PRE] ]FIG] * 構文 [54] [[HTTP/1.1]] [[以下]]の [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]の[[要求対象]]は、 [CODE(ABNF)@en[[[authority-form]]]] でなければ[['''なりません''']] [SRC[>>49]]。 [17] [[HTTP/2]] では、[[疑似ヘッダー]]を次のようにします。 [FIG(list members)[ - [18] [CODE(HTTP)@en[[[:method]]]] は、 [CODE(HTTP)@en[[[CONNECT]]]] とします [SRC[>>12]]。 - [19] [CODE(HTTP)@en[[[:scheme]]]] は、省略しなければ[['''なりません''']] [SRC[>>12]]。 - [20] [CODE(HTTP)@en[[[:path]]]] は、省略しなければ[['''なりません''']] [SRC[>>12]]。 - [21] [CODE(HTTP)@en[[[:authority]]]] は、[[ホスト]]と[[ポート]]を指定します。 [[要求対象]]の [CODE(ABNF)@en[[[authority-form]]]] に相当します。 [SRC[>>12]] ]FIG] [62] [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]の [[payload]] の意味は定義されていません。 [SRC[>>49]] ;; [63] [[payload body]] があると実装によっては[[要求]]を拒絶するかもしれません。 [SRC[>>49]] [34] [[Chrome]] は次の[[ヘッダー]]を指定するようです。 [TIME[2015-08-04T10:02:41.00Z]] [FIG(list middle)[ - [[HTTP/1.1]] - [CODE(HTTP)@en[[[Host:]]]] - [CODE(HTTP)@en[[[Proxy-Connection:]] [[keep-alive]]]] - [CODE(HTTP)@en[[[User-Agent:]]]] ]FIG] [35] [[Firefox]] は次の[[ヘッダー]]を指定するようです。 [TIME[2015-08-04T10:02:41.00Z]] [FIG(list middle)[ - [[HTTP/1.1]] - [CODE(HTTP)@en[[[User-Agent:]]]] - [CODE(HTTP)@en[[[Proxy-Connection:]] [[keep-alive]]]] - [CODE(HTTP)@en[[[Connection:]] [[keep-alive]]]] - [CODE(HTTP)@en[[[Host:]]]] ]FIG] [36] [[IE]] は次の[[ヘッダー]]を指定するようです。 [TIME[2015-08-04T10:02:41.00Z]] [FIG(list middle)[ - [[HTTP/1.0]] - [CODE(HTTP)@en[[[User-Agent:]]]] - [CODE(HTTP)@en[[[Connection:]] [[keep-alive]]]] - [CODE(HTTP)@en[[[Content-Length:]] 0]] - [CODE(HTTP)@en[[[Host:]]]] - [CODE(HTTP)@en[[[Pragma:]] [[no-cache]]]] ]FIG] * 性質 [64] [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]に対する[[応答]]は、 [[キャッシュ可能]]ではありません [SRC[>>49]]。 * 処理 [51] [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]は[[串]]に対する[[要求]]での利用のみを想定しています [SRC[>>49]]。 [22] [[HTTP/2]] で >>17 の[[疑似ヘッダー]]の制約に違反する場合は、 [[奇形]]です [SRC[>>12]]。 [55] [[串]]は、[[要求対象]]に直接[[接続]]しても構いませんし、 他の[[串]]を使うよう設定されている場合には次の[[内向き]]の[[串]]に [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]を[[転送]]しても構いません [SRC[>>49]]。 [84] [[MITM proxy]] として動作する[[プロキシ]]は、 自身が [CODE[CONNECT]] のデータを読み書きする [[HTTPS]] [[サーバー]]として動くことになります。 [SEE[ [[MITM proxy]] ]] [23] [CODE(HTTP)@en[[[CONNECT]]]] に対応する [[HTTP/2]] [[プロキシ]]は、 [CODE(HTTP)@en[[[:authority]]]] [[疑似ヘッダー]]で識別される[[サーバー]]への [[TCP接続]]を確立します。確立に成功したら、 [[状態符号]] [CODE(HTTP)@en[[[2xx]]]] の [CODE(HTTP)@en[[[HEADERS]]]] [[フレーム]]を[[クライアント]]に送信します。 [SRC[>>12]] [52] 自身への [CODE(HTTP)@en[[[CONNECT]]]] [[要求]]を受信した[[起源鯖]]は、 [[接続]]が確立されたことを示す [CODE(HTTP)[[[2xx]]]] [[応答]]を返しても構いません [SRC[>>49]]。 ;; [57] [[持続接続]]により引き続き [[HTTP]] の[[接続]]の処理が継続されているのか、 [CODE(HTTP)@en[[[CONNECT]]]] によって[[トンネル]]として動作しているのか、 [[クライアント]]側から判別する方法はありません。 ;; [53] ただしほとんどの[[起源鯖]]は、 [CODE(HTTP)@en[[[CONNECT]]]] を実装していません [SRC[>>49]]。 [60] [[トンネル]]の確立は大きな危険を生じさせるものですから、[[串]]は、 既知の[[ポート]]や安全な[[要求対象]]の[[ホワイトリスト]]により、 [CODE(HTTP)@en[[[CONNECT]]]] の利用を制限する[['''べきです''']] [SRC[>>49]]。 [46] [CODE(HTTP)[[[CONNECT]]]] [[要求]]に対する [CODE(HTTP)[[[2xx]]]] [[応答]]は、[[メッセージ本体]]を持ちません [SRC[>>45, >>49]]。 [24] [[HTTP/1.1]] [[以下]]では、[[メッセージ本体]]の代わりに、 [[ヘッダー]]の次の [[CRLF]] の直後から、[[トンネル]]モードに切り替わります。 [SRC[>>45, >>49]] [61] [[鯖]]は、 [CODE(HTTP)@en[[[Transfer-Encoding:]]]] や [CODE(HTTP)@en[[[Content-Length:]]]] を [CODE(HTTP)[[[2xx]]]] [[応答]]に含めては[['''なりません''']] [SRC[>>49]]。 [[クライアント]]はこれらを無視しなければ[['''なりません''']] [SRC[>>49]]。 [25] [[HTTP/2]] では、 最初の [CODE(HTTP)@en[[[HEADERS]]]] [[フレーム]]の後、 以後のすべての [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]は [[TCP接続]]上のデータに対応します。 [[クライアント]]から送信された [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]は[[プロキシ]]から [[TCPサーバー]]へと送信され、 [[TCPサーバー]]から受信したデータは[[プロキシ]]から[[クライアント]]へと [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]で送信されます。 [SRC[>>12]] [26] [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]と[[ストリーム]]管理のための[[フレーム]] ([CODE(HTTP)@en[[[RST_STREAM]]]], [CODE(HTTP)@en[[[WINDOW_UPDATE]]]], [CODE(HTTP)@en[[[PRIORITY]]]]) を除き、当該[[ストリーム]]を使って送信しては[['''ならず''']]、 受信したら[[ストリームエラー]]としなければ[['''なりません''']]。 [SRC[>>12]] [56] [CODE(HTTP)[[[2xx]]]] 以外の[[応答]]は、[[トンネル]]が形成されていないことを表し、 [[トンネル]]としてではなく [[HTTP]] による解釈を継続するべきものです [SRC[>>49]]。 [58] [[HTTP/1.1]] [[以下]]の[[トンネル]]は、そのいずれかの側の[[接続]]が閉じられたと検出した時、 閉じられます。その場合、閉じられた側からの残りのデータをすべて送信し、 両方の[[接続]]を閉じ、残ったデータがあれば捨てる、という処理を試みなければ[['''なりません''']]。 [SRC[>>49]] [27] [[HTTP/2]] では [CODE(HTTP)@en[[[END_STREAM]]]] [[フラグ]]が [[TCP]] [CODE[[[FIN]]]] フラグに相当します。[[クライアント]]は、 [CODE[[[END_STREAM]]]] フラグが設定された [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]を受信したら、 [CODE(HTTP)@en[[[END_STREAM]]]] フラグが設定された [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]を送信することが期待されています。 [[プロキシ]]は、[CODE(HTTP)@en[[[END_STREAM]]]] フラグが設定された [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]を受信したら、 [CODE[[[FI]]]] ビットを設定した [[TCPセグメント]]を最後に送ります。[[プロキシ]]は [CODE[[[FIN]]]] ビットが設定された [[TCPセグメント]]を受信したら、 [CODE(HTTP)@en[[[END_STREAM]]]] フラグが設定された [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]を送信します。 [SRC[>>12]] ;; [28] 最後の [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]や [[TCPセグメント]]は、 空になることもあります。 [SRC[>>12]] [29] [[HTTP/2]] [[プロキシ]]は、 [CODE[[[RST]]]] ビットが設定された [[TCPセグメント]]をはじめとする [[TCP接続]]のエラーを検出したら、[[ストリームエラー]] [CODE[[[CONNECT_ERROR]]]] とします。 [SRC[>>12]] [30] [[HTTP/2]] [[プロキシ]]は、 [[HTTP/2]] の[[ストリーム]]や[[接続]]でエラーを検出したら、 [CODE[[[RST]]]] ビットが設定された [[TCPセグメント]]を送信しなければ[['''なりません''']] [SRC[>>12]]。 ;; [31] [[HTTP/1.1]] [[以下]]でも同じようにエラー処理が必要なのかもしれませんが、 [[RFC]] では規定されていません。 [33] [CODE(HTTP)@en[[[CONNECT]]]] は、 [[TCP接続]]を維持しなければならず、 その分の[[資源]]を消費することに注意が必要です。 [CODE(HTTP)@en[[[CONNECT]]]] が閉じられた後も [CODE[[[TIME_WAIT]]]] 状態の間、 [[TCP接続]]の情報を残す必要があることにも注意が必要です。 [[設定]] [CODE[[[SETTINGS_MAX_CONCURRENT_STREAMS]]]] とは別に [CODE(HTTP)[[[CONNECT]]]] の[[資源]]消費にも制限が必要かもしれません。 [SRC[>>32]] [6] [[トンネル]]内では [[HTTPS]] ([[HTTP]] over [[TLS]]) を用いるのが主たる用途ですが、 [[TCP]] で動作する任意の[[プロトコル]]を使うことができます。 [[トンネル]]としてはどのような[[プロトコル]]が使われているか感知しません。 [37] [[HTTPS]] [[プロキシ]]としての利用の際、 [[Firefox]] は[[応答]]を待たずに[[ヘッダー]]と空行の後直ちに [[TLS]] を開始します。 [[Chrome]] と [[IE]] は、[[応答]]を待ちます。 [[応答]]が [CODE(HTTP)[[[200]]]] 以外の場合、 [[Chrome]] と [[IE]] は[[接続]]を閉じますが、 [[Firefox]] は[[接続]]が閉じられるのを待ちます。 ただし [CODE(HTTP)[[[101]]]] なら直ちに閉じます。 [TIME[2015-08-04T10:16:18.800Z]] [83] [[curl]] は [CODE[200]] 以外の [CODE[2xx]] をエラーとして扱います。 [TIME[2018-08-30T15:29:36.00Z]] [80] 仕様上は [CODE[200]] 以外の [CODE[2xx]] を返すこともできますが、 実際には使えないということです。[[サーバー]]と[[クライアント]]で何を[[トンネル]]と解釈するかが異なると [[HTTP]] としての解釈と[[トンネル]]データの区分が両者で異なり、 [[セキュリティー]]問題を引き起こす危険性があります。 [[クライアント]]は [[Chrome]] 同様にエラーと扱うべきでしょう。 [77] 仕様上は [CODE[CONNECT]] [[要求]]に対して [CODE[200]] 以外の[[応答]]を返した場合に、 [[持続的接続]]で次の[[要求]]を送ることができます。実際には [[Webブラウザー]]は [CODE[407]] で[[HTTP認証]]情報付きで [CODE[CONNECT]] を再送信する以外で失敗した[[接続]]を再利用することはありません。 また、 [CODE[CONNECT]] 以外で使った[[HTTP接続]]に [CODE[CONNECT]] を送信することもありません (が認められてはいます)。 [79] [[応答]]を待たずに[[要求]]直後に[[トンネル]]データの送信を開始する場合、 [CODE[200]] 以外の[[応答]]が返った場合に次の[[要求]]を送れないことになります。 場合によっては、[[トンネル]]データが[[HTTP要求]]と解釈されてしまい困るかもしれません。 [68] [[Firefox]] と [[Chrome]] は [[HTTP/0.9]] [[応答]]を[[ネットワークエラー]]とします。 [TIME[2015-09-14T02:31:35.100Z]] [69] [[Firefox]] も [[Chrome]] も、 [[HTTP/1.0]] か [[HTTP/1.1]] かは動作に影響しません。 [TIME[2015-09-14T02:36:03.800Z]] [38] [[Firefox]] も [[Chrome]] も [[IE]] も、 [CODE(HTTP)[[[1xx]]]] はエラーとみなし、その後の[[応答]]を待ちません。 [TIME[2015-08-04T10:19:45.500Z]] [39] [[Firefox]] も [[Chrome]] も [[IE]] も、 [CODE(HTTP)[[[407]]]] で [CODE(HTTP)@en[[[Proxy-Authenticate:]]]] があれば、 [[モーダルダイアログ]]を表示します。 [TIME[2015-08-04T10:26:52.400Z]] [40] [[Firefox]] と [[Chrome]] は[[持続的接続]]により [CODE(HTTP)[[[407]]]] の[[接続]]を再利用しようとします。 [[IE]] は再利用しないようにみえます (が条件次第で再利用するかもしれず断言はできません)。 [TIME[2015-08-04T10:32:16.00Z]] [41] [[Chrome]] も [[IE]] も [CODE(HTTP)[[[200]]]] [[応答]]の [CODE(HTTP)@en[[[Content-Length:]]]] は無視するようです。しかし [[Chrome]] は [CODE(HTTP)@en[[[Content-Length:]]]] が不正かどうかのチェックは行っているようです。 [TIME[2015-08-04T11:33:28.00Z]] [42] [[Chrome]] も [[Firefox]] も [[IE]] も、 [CODE(HTTP)[[[200]]]] [[応答]]の [CODE(HTTP)@en[[[Connection: close]]]] や [CODE(HTTP)@en[[[Proxy-Connection:]] [[close]]]] は無視するようです。 [TIME[2015-08-04T11:44:09.700Z]] * 誤り符号 [CODE[CONNECT_ERROR]] [11] [[誤り符号]] [DFN[[CODE[[[CONNECT_ERROR]]]]]] ([CODE[[[0xa]]]]) は、 [CODE[[[CONNECT]]]] [[要求]]により確立された[[接続]]が[[再設定]]または異常に閉じられたことを表します [SRC[>>10]]。 * セキュリティー [71] [CODE(HTTP)@en[CONNECT]] は、その[[サーバー]]から接続可能な任意の [[TCP]] [[サーバー]]に、任意の[[プロトコル]]でアクセスできます。従って、 杜撰な実装や設定の[[サーバー]]は、攻撃の踏み台として使われてしまいます。 [EG[ [72] 例えば、[[イントラネット]]に接続された[[サーバー]]が外部からアクセス可能になっていて、 [CODE(HTTP)@en[CONNECT]] による接続先の制限が何もなければ、 外部から[[イントラネット]]に自由にアクセスできる[[セキュリティーホール]]でしかありません。 ]EG] [73] このため [CODE(HTTP)@en[CONNECT]] [[メソッド]]は危険だと言われることがしばしばありますが、 どちらかといえば[[プロトコル]]が危険なのではなくサーバーの開発者や管理者の責任でしょう。 * 歴史 ** draft-luotonen-web-proxy-tunneling (1998) [REFS[ - [1] [CITE@en[draft-luotonen-web-proxy-tunneling - Tunneling TCP based protocols through Web proxy servers]] ]REFS] ** RFC 2616 [FIG(quote)[ [FIGCAPTION[ [2] RFC 2616 (HTTP/1.1) 9.9 CONNECT ]FIGCAPTION] > This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]). > この仕様書は、方式名 [CODE(HTTP)[[[CONNECT]]]] を、動的に[[トンネル]]になるように切り替える[[串]] (たとえば [[SSL]] トンネル化) で使うために予約します。 ]FIG] ** RFC 2817 [4] [[RFC 2817]] が [CODE(HTTP)@en[[[CONNECT]]]] [[要求メソッド]]を初めて正式に規定する[[仕様書]]となりました。 [8] [[RFC 2817]] は >>1 に言及しつつ、既に[[串]]で広く実装されている [SRC[>>3]] と述べています。 [REFS[ - [3] [CITE@en[RFC 2817 - Upgrading to TLS Within HTTP/1.1]] ([TIME[2012-01-09 20:05:09 +09:00]] 版) ]REFS] ** RFC 723x [7] [[RFC 7230]] と [[RFC 7231]] により [[RFC 2817]] が[[更新]]され、 より正確に動作が規定されるようになりました。これにより [[RFC 2817]] の該当部分の規定は失効したものと考えられます。 [13] [[RFC 7540]] [SRC[>>12]] は [[HTTP/2]] における用法を規定しています。 * 関連 [59] [CODE(HTTP)@en[[[CONNECT]]]] [[メソッド]]に [CODE(HTTP)@en[[[Proxy-Authorization:]]]] を含めることで、[[串]]の[[認証]]を利用できます。 [201] [CITE@en[draft-maes-lemonade-http-binding-04 - IMAP and SMTP HTTP Binding]] ( ([TIME[2014-08-20 10:08:37 +09:00]] 版)) [202] [CITE@en[draft-maes-lemonade-p-imap-12 - Push Extensions to the IMAP Protocol (P-IMAP)]] ( ([TIME[2014-08-24 09:14:38 +09:00]] 版)) [9] [CITE@en[mod_proxy_connect - Apache HTTP Server Version 2.4]] ([TIME[2015-01-02 00:30:56 +09:00]] 版) [43] [CITE@en[479880 – (CVE-2009-1836) Non-200 responses to proxy CONNECT requests lead to attacks on HTTPS]] ([TIME[2015-09-12 23:59:19 +09:00]] 版) [66] [CITE@en[draft-luotonen-web-proxy-tunneling-01 - Tunneling TCP based protocols through Web proxy servers]] ([TIME[2015-07-19 22:31:59 +09:00]] 版) [67] [CITE[Issue 7338 - chromium - 30x redirects silently honored in response to CONNECT - An open-source project to help move the web forward. - Google Project Hosting]] ([TIME[2015-09-13 00:15:10 +09:00]] 版) [70] [CITE[Issue 433784 - chromium - Malformed CONNECT request to HTTP/2 proxy - An open-source project to help move the web forward. - Google Project Hosting]] ([TIME[2015-09-24 20:40:57 +09:00]] 版) [74] [CITE@en-US[A Proxy-savvy Socket in ActionScript 3]] ( ([TIME[2016-06-16 11:28:29 +09:00]])) [81] [CITE@en[draft-ietf-httpbis-h2-websockets-07 - Bootstrapping WebSockets with HTTP/2]] ([TIME[2018-06-19 17:25:37 +09:00]]) [82] [CITE@en[Bootstrapping WebSockets with HTTP/2]] ([TIME[2018-06-16 08:25:34 +09:00]])