435.txt

[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]] 版) <https://tools.ietf.org/html/rfc7231#section-4.3.6>'''
- [45] [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-3.3>
- [10] [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-7>
- [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-8.3>
- [32] [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.5.2>
]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]]
<http://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling>
]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]] 版) <http://tools.ietf.org/html/rfc2817#section-5>
]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]] 版))
<http://tools.ietf.org/html/draft-maes-lemonade-http-binding-04#section-2.1.3>

[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]] 版))
<http://tools.ietf.org/html/draft-maes-lemonade-p-imap-12#page-47>

[9] [CITE@en[mod_proxy_connect - Apache HTTP Server Version 2.4]]
([TIME[2015-01-02 00:30:56 +09:00]] 版)
<http://httpd.apache.org/docs/current/en/mod/mod_proxy_connect.html>

[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]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880>

[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]] 版)
<https://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01>

[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]] 版)
<https://code.google.com/p/chromium/issues/detail?id=7338>

[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]] 版)
<https://code.google.com/p/chromium/issues/detail?id=433784>

[74] [CITE@en-US[A Proxy-savvy Socket in ActionScript 3]]
( ([TIME[2016-06-16 11:28:29 +09:00]]))
<http://blogs.adobe.com/cantrell/archives/2006/07/a_proxy-savvy_s.html>

[81] [CITE@en[draft-ietf-httpbis-h2-websockets-07 - Bootstrapping WebSockets with HTTP/2]]
([TIME[2018-06-19 17:25:37 +09:00]])
<https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-07>

[82] [CITE@en[Bootstrapping WebSockets with HTTP/2]]
([TIME[2018-06-16 08:25:34 +09:00]])
<https://httpwg.org/http-extensions/draft-ietf-httpbis-h2-websockets.html>