Network Working Group R. Khare Request for Comments: 2817 4K Associates / UC Irvine Updates: 2616 S. Lawrence Category: Standards Track Agranat Systems, Inc. May 2000 HTTP/1.1におけるTLSへのアップグレード このメモの位置付け このドキュメントは、インターネット・コミュニティに対し、インターネット 標準化プロトコルを規定し、その改善のための議論と提案を求めるものである。 このプロトコルの標準化状態と位置付けは、"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。このメモの配布は無制限である。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要旨 このメモでは、HTTP/1.1のUpgradeメカニズムを使用することにより、すでに確立 されているTCPコネクションでTransport Layer Security(TLS)を開始するための 方法を説明する。これにより、非セキュアなHTTPとセキュアなHTTPトラフィックは、 同一の既知(well-known)ポート(この場合、443のhttpsではなく80のhttp)を共有する ことができる。またこれにより、「仮想ホスティング」が可能となるため、 HTTP + TLS サーバにおいては、一つのIPアドレスを共有する複数の仮想ホスト へのトラフィック処理に関する、あいまいさを取り除くことができる。 HTTP/1.1 [1]では、Upgradeを段階的変更(hop-by-hop)メカニズムとして定義 しているため、このメモではまた、HTTPプロキシを通る両端間のトンネルを 確立するための、HTTP CONNECTメソッドを記述する。最後に、このメモでは 一般使用目的のHTTPステータスコードのための新しいIANAの登録機関に加え、 一般使用目的または個人使用目的のためのUpgradeトークンの登録機関の 確立を行う。 このメモは、現在の'https' URIスキームの定義には影響しない。このスキーム は既に、'http'とは別の名称空間を形成している(http://example.org/ と https://example.org/ は同等ではない)。 目次 1. 動機 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. クライアントの要求によるHTTPからTLSへのアップグレード . . . . 4 3.1 オプショナルなUpgrade . . . . . . . . . . . . . . . . . . . . 4 3.2 Upgradeの必須事項 . . . . . . . . . . . . . . . . . . . . . . 4 3.3 サーバにおけるUpgradeリクエスト受信 . . . . . . . . . . . . . 4 4. サーバの要求によるHTTPからTLSへのアップグレード . . . . . . . 5 4.1 オプショナルな通知 . . . . . . . . . . . . . . . . . . . . . . 5 4.2 通知の必須事項 . . . . . . . . . . . . . . . . . . . . . . . . 5 5. プロキシを通じたUpgrade . . . . . . . . . . . . . . . . . . . 6 5.1 段階的アップグレードの意味 . . . . . . . . . . . . . . . . . . 6 5.2 CONNECTを使用したトンネルの要求 . . . . . . . . . . . . . . . 6 5.3 CONNECTを使用したトンネルの確立 . . . . . . . . . . . . . . . 7 6. 4xx（クライアントエラー）ステータスコードを使用する場合の原則 7 7. IANAの考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1 HTTP ステータスコードレジストリ . . . . . . . . . . . . . . . 8 7.2 HTTP Upgradeトークンレジストリ . . . . . . . . . . . . . . . 8 8. セキュリティに関する考察 . . . . . . . . . . . . . . . . . . 9 8.1 https: URIスキームのその他の意味 . . . . . . . . . . . . . . . 10 8.2 CONNECTのセキュリティに関する考察 . . . . . . . . . . . . . . 10 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 著者のアドレス . . . . . . . . . . . . . . . . . . . . . . . . 11 A. 謝辞　 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1. 動機 歴史的な経緯により、SSL3 [3] 上でHTTPを使用する場合には、独自のURIスキーム と独自のTCPポート番号を使用することで、HTTPを単独で使用する場合と区別され ている。スキーム'http'は、ポート80で動作する単独のHTTPプロトコルを意味 するのに対し、'https'はポート443で動作するSSL上のHTTPプロトコルを意味する。 同様に、他のアプリケーションプロトコル(例えば、snews、ftps)においても、 セキュアと非セキュアによる使用を区別するために、並列な既知(well-known)ポート 番号が必要とされ --ある場合には付与され-- ている。このアプローチでは実質的に、 利用可能な既知ポート番号の数を半分にすることになる。 1997年12月にワシントンD.C.で行われたIETF会議において、アプリケーション エリアのディレクターとIESGは、並列に「セキュアな」ポート番号を発行する 習慣は推奨されない、と再確認した。 HTTP/1.1 Upgradeメカニズムは、Transport Layer Security [6] をオープンなHTTPコネクションに適用することが出来るもの である。 それから約2年、この提案の背景にある概念は広く受け入れられているが、 一般的なWebブラウジングのための、ポート443に代わる実装には、ほとんど関心 が集められていない。事実、このメモは、https: URIの現在の解釈には何の影響も ない。しかし、HTTP上に構築される新しいプロトコル、例えばInternet Printing Protocol [7] では、IETF標準規格となるためにまさしくそのようなメカニズムが 必要とされている。 Upgradeメカニズムはまた、「仮想ホスティング」問題を解決する。複数のIP アドレスを一つのホストに割り当てるのではなく、HTTP/1.1サーバは、Host: ヘッダを解釈することにより、意図しているWebサービス処理のあいまいさを 取り除く。HTTP/1.1の使用がより一般的になるにつれ、より多くのISPが名称 ベースの仮想ホストを提供していく。これにより、IPアドレス空間の枯渇を 遅らせることができる。 TLS(そしてSSL)は、HTTP の以前のバージョンと同じ制限により苦境に立たされ ている。ハンドシェイクを開始するときには、意図しているホスト名を指定しない。 唯一、IPアドレスに依存している。平文のHTTP/1.1 Upgrade: プリアンブルをTLS ハンドシェイクに使用し、--最初の Host: ヘッダに基づいて証明書を選択する-- ことにより、ISPはまた、セキュアな名称ベースの仮想ホストを提供することが できる。 2. はじめに TLS、これはまたSSL(Secure Sockets Layer)としても知られている、では、 さまざまな暗号システムを使用して、両端間のプライベートなコネクションを 確立し、オプショナルで強力な相互認証を行う。はじめに、ハンドシェイク フェーズでは、3つのサブプロトコルを使用することにより、レコード層の設定、 相互認証、パラメータの設定、またはエラーの報告を行う。そしてレコード プロトコルにおいて、そのコネクションの他のデータの暗号化、圧縮、そして 再アセンブルを処理する。後者は完全に透過であることを意図している。例えば、 TLSのレコードマーカー、証明書とHTTP/1.1のチャンクエンコーディングまたは 認証の間には、依存関係は存在しない。 クライアントまたはサーバは、HTTP/1.1 [1] Upgradeメカニズム(第14.42節)を 使用することにより、TLSセキュアコネクションを要求、または必要であることを 示すことができる。このメモでは、"TLS/1.0" Upgradeトークンを定義し、また 新しいHTTPステータスコードである、"426 Upgrade Required" を定義する。 第3章と第4章では、直接接続されたクライアントとサーバ間での処理を記述 する。中間的なプロキシでは、これらの処理を適用する前に、両端間にトンネル を確立しなければならない。これは第5章で説明する。 2.1 用語 本ドキュメントに現れるキーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHOULD"、 "SHOULD NOT"、"MAY"は、RFC2119 [11] で示されるように解釈されなければなら ない。 3. クライアントの要求によるHTTPからTLSへのアップグレード クライアントが、Upgradeヘッダーフィールドに対して“TLS/1.0"トークンを 含めたHTTP/1.1リクエストを送信したときには、これはサーバに対し、TLS/1.0に スイッチした後に、現在のHTTP/1.1リクエストを完全に処理するように要求して いることになる。 3.1 オプショナルなUpgrade クライアントは、セキュアでないレスポンスを受理することができるときには、 すべてのセキュアでないHTTPリクエストにおいて、セキュアな処理にスイッチ しようとしてもよい(MAY)。 GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade この場合、サーバはセキュアでない通常のHTTPでレスポンスしてもよい(MAY)。 または、セキュアな処理へスイッチしてもよい(次章で詳細を述べる）。 HTTP/1.1 [1]では、「UpgradeがHTTP/1.1メッセージに存在するときは、キー ワード upgrade がConnectionヘッダフィールド(第14.10節)において提供され なければならない」と規定されていることに注意。 3.2 Upgradeの必須事項 セキュアでないレスポンスを受理できないならば、クライアントは最初に OPTIONSリクエストを送り、(スイッチが可能ならば)TLS/1.0へのスイッチを行わ なければならない(MUST)。 OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade 3.3 サーバにおけるUpgradeリクエスト受信 HTTP/1.1 [1]で規定されているように、サーバは、TLSハンドシェイクを開始 する準備がある場合には、中間的な "101 Switching Protocol" メッセージを 送信しなければならない(MUST)。そしてそのメッセージには、スイッチする プロトコルスタックのトークンを指定したUpgradeレスポンスヘッダを含めて いなければならない(MUST)。 HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade 101 Switching ProtocolレスポンスのUpgradeヘッダに示されているプロト コルトークンでは、順序付けされた「ボトムアップ」のスタックを指定する ことに注意。 HTTP/1.1 [1]、第10.1.2節で規定されているように、「サーバは、101 レスポ ンスの終了を表す空行の直後に、レスポンスのUpgradeヘッダフィールドで指定 されたプロトコルに切り換える」。 TLSハンドシェイクが成功したときには、サーバは、オリジナルリクエストに 対するレスポンスを続行しなければならない(MUST)。TLSハンドシェイクに失敗 したときは、コネクションを切断しなければならない(MUST)。これはTLSのエラー アラート規定ごとに行われる。 4. サーバの要求によるHTTPからTLSへのアップグレード Upgradeレスポンスヘッダフィールドは、サーバが受理してもよい(MAY)、プロ トコルアップグレードを通知する。"426 Upgrade Required"ステータスコードと 関連して、サーバは、リクエストを完全に処理するためにクライアントが受理 しなければならない(MUST)正確なプロトコルアップグレードを通知することが できる。 4.1 オプショナルな通知 HTTP/1.1 [1]で規定されているように、サーバは101または426以外のレスポ ンスにおいてUpgradeヘッダを含め、リストされたプロトコルのどれか(組み合 わせ)にスイッチしようとしていることを示してもよい(MAY)。 4.2 通知の必須事項 サーバは、"426 Upgrade Required"ステータスコードを使用することにより、 TLSを使用しないとクライアントリクエストを完全に処理することができないこと を示してもよい(MAY)。これには、要求されるTLSバージョンを示すトークンを 指定したUpgradeヘッダフィールドが含まれていなければならない(MUST)。 HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade サーバは、426レスポンスにおいてメッセージボディを含め、人間が読める ような形式でエラーの理由を示し、ユーザが利用可能である代替方法を記述する べきである(SHOULD)。 クライアントがTLSを使用することを望んでいる場合でも、第3章で示された 手順で処理しなければならないことに注意。 426レスポンスの直後に、TLSハンド シェイクを始めることはできない。 5. プロキシを通じたUpgrade 段階的変更を行うヘッダであるUpgradeを使用することにより、HTTP通信相手と ネゴシエーションを行う。ユーザエージェントがプロキシに対してUpgradeヘッダ を含むリクエストを送信したときには、それ自体とプロキシとの間でプロトコル の変更を要求していることを意味しており、両端間での変更を意味していない。 TLSでは特に、認証を提供しなりすまし攻撃を防ぐために、両端間でのコネク ションが要求されるため、このメモではプロキシを通過するトンネルを確立する ためのCONNECTメソッドを規定する。 トンネルが確立されると、第3章における処理を使用してTLSコネクションを確立 することができる。 5.1 段階的アップグレードの意味 オリジンサーバがプロキシからUpgradeヘッダーを受信し、"101 Switching Protocols" レスポンスを返す場合には、単にプロキシとサーバとの間のコネク ションのプロトコルを変更するだけである。同様に、プロキシがクライアントに 対して101レスポンスを返し、そのコネクションのプロトコルを変更することは、 そのプロキシがオリジンサーバに対して通信するのに使用しているプロトコルと は無関係である。 これらのシナリオはまた、426レスポンスの判断を複雑にする。Upgradeは段階 的変更を行うヘッダであるため、426を認識しないプロキシは、付随している Upgradeヘッダーを取り除き、クライアントに対し要求されたプロトコルへの スイッチを行わないようにするかもしれない。クライアントがUpgradeヘッダ なしに426ステータスを受信した場合には、第5.2節で記述される両端間のトン ネルコネクションを要求し、そしてそのリクエストを繰り返すことにより、 必要なアップグレード情報を得る必要がある。 この段階的なUpgradeの定義は、慎重な選択である。これにより、プロキシの どちら側においても、段階的なアップグレードが可能となり、またプロトコル 変更に関与しなかったパーティーに関する知識なしに、カスケード接続された プロキシ間でのプロコトルを最適化することができる。 5.2 CONNECTを使用したトンネルの要求 CONNECTメソッドはプロキシに対し、トンネルコネクションの確立を要求する。 Request-LineにおけるRequest-URIの部分には常に、URI Generic Syntax [2] で定義される 'authority' を指定する。これは、リクエストしているコネク ションの目的となるホスト名とポート番号をコロンで区切ったものである。 CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 CONNECTメソッドと共に他のHTTPメカニズムも使用することができる。使用できる のは無論、両端間でのプロトコル Upgrade リクエスト以外のメカニズムである。 なぜならば、トンネルはまず最初に確立されなければならないからである。 例えば、authorityがトンネルを生成する際には、プロキシ認証が使用されるかも しれない。 CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: basic aGVsbG86d29ybGQ= パイプラインを使用する他の HTTP/1.1リクエストと同様、トンネルされるデー タは、空白行の直後に送信される。また、通常の警告が適用される。最後の レスポンスが否定的なものであれば、データを捨ててもよい。そして1つ以上の TCPセグメントが確立していない場合には、コネクションをレスポンスなしで リセットしてもよい。 5.3 CONNECTを使用したトンネルの確立 CONNECTリクエストに対する成功(2xx)レスポンスは、プロキシがリクエスト されたホストとポートでコネクションを確立したことを示すものであり、また 現在のコネクションをサーバへのコネクションにトンネリングするようスイッチ したことを示す。 あるプロキシから、要求されたオリジンサーバに達するためには、別のプロキシ を通らなければならない場合もある。この場合、最初のプロキシでは次のプロ キシへCONNECTリクエストを送信し、authorityに対してトンネルをリクエスト するべきである(SHOULD)。プロキシは、authorityへの直接のコネクション、 またはトンネルコネクションが確立しない限り、2xxステータスコードでレス ポンスしてはならない(MUST NOT)。 CONNECTリクエストを受信したオリジンサーバは、コネクションが確立したこと を示すために2xxステータスコードでレスポンスしてもよい(MAY)。 ピアのどちらか一方からコネクションの切断をする場合には、そのピアからの 未送信データは他方に送信される。そしてその後に、もう一つのコネクションが プロキシによって切断される。そのピアへの未送信データがあった場合には、その データは捨てられる。 6. 4xx（クライアントエラー）ステータスコードを使用する場合の原則 Upgradeを使用した、信頼でき、相互運用の可能なネゴシエーションでは、あい まいさのない失敗シグナルが必要となる。"426 Upgrade Required"ステータス コードにより、サーバは、求められたリソースを提供するために必要な、正確 なプロトコル拡張子を明確に示すことができる。 このレスポンスは最初、ある種のリダイレクション(3xxコード)であると思うかも しれない。これは、https: URIへの、従来スタイルのリダイレクションに類似して いるためである。Upgrade: を理解しないユーザエージェントは、これを排除する ことになる。 "Upgrade Required" が3xxコードに割り当てられたと仮定する。これを認識でき ないユーザエージェントは、これを300として処理するであろう。そして次に、 レスポンス内で"Location"ヘッダを探し、そのヘッダフィールドに含まれるURL に対してリクエストを繰り返そうとするであろう。UpgradeによりTLS層を組み込 むことを知らないため、新しいURLでまた失敗するのがせいぜいであろう。 7. IANAの考慮事項 IANAは、BCP 26 [10]で示されるように、2つの名称空間のレジストリを作成する ものとする。 o HTTP ステータスコード o HTTP Upgrade トークン 7.1 HTTP ステータスコードレジストリ HTTPステータスコードレジストリは、HTTPレスポンスのステータス行における ステータスコードトークンの名称空間を定義する。この名称空間の初期値は、 以下で指定される。 1. HTTP/1.1 [1] のドラフトスタンダード 2. Web Distributed Authoring and Versioning [4] [420-424の定義] 3. WebDAV Advanced Collections [5] (策定中) [425の定義] 4. 第6章 [426の定義] この名称空間に追加される値は、IETFアプリケーションエリアにおける標準化 ドキュメントの形式でレビューを受けるべきである(SHOULD)。 そのようなドキュメントでは、HTTP/1.1 [1]のドラフトスタンダードの 'Obsoletes'または'Updates'のどちらかのステータスとして、トレースできる べきである(SHOULD)。 7.2 HTTP Upgradeトークンレジストリ HTTP Upgrade トークンレジストリは、Upgrade HTTPヘッダフィールドにおいて プロトコルを特定するのに使用されるproductトークンの名称空間を定義する。 登録されたそれぞれのトークンは、一つ以上の仕様書に基づくものであるべきで あり、また連絡先情報と関連づけられるべきである。 HTTP/1.1 [1] のドラフトスタンダードでは、これらのトークンは'product' に従うと規定している。 product = token ["/" product-version] product-version = token 登録は、BCP 26 [10]で示されているように、早いもの勝ちであるべきである。 これらの仕様はIETFのドキュメントとしたり、IESGのレビューを受ける必要は ないが、以下の規則に従うべきである。 1. トークンは一度登録されれば、永久に登録されたままである。 2. 登録に際しては、責任を持つパーティーを提示しなければならない(MUST)。 3. 登録に際しては、連絡先を提示しなければならない(MUST)。 4. 登録に際しては、トークンに必要なドキュメントを提示してもよい(MAY)。 5． 責任を持つパーティーでは、随時、登録を変更してもよい(MAY)。IANAは そのようなすべての変更に関する記録を行い、リクエストがあればその 記録を利用可能とする。 6. "product"トークンの責任を持つパーティーでは、最初の登録を行う 前に、"product"トークンと共に"version"トークンも後に登録すること も承認しなければならない(MUST)。 7. 必要であるならば、IESGはトークンの責任者の再割り当てを行ってもよい (MAY)。通常これは、責任を持つパーティーに連絡することができない ときにのみ使用される。 本仕様書では、TLSプロトコル [6] によって規定されるプロトコルのための 識別子として“TLS/1.0" を定義する。 upgradeトークンの仕様は、公的に利用可能である必要はないが、登録に関する 情報は公的に利用可能であるべきである(SHOULD)。 8. セキュリティに関する考察 なりすまし攻撃(Upgradeヘッダの削除)の可能性が、現在行われているhttp/https の平行利用の場合と同様に残されている。 o Upgradeヘッダを削除するのは、webページ上のhttps://リンクをhttp:// リンクに書き直すのと同じである。 o サーバが、最初の情報提供場所において、セキュア、非セキュア両方の チャンネルで情報を提供しようとしている場合にだけ、そのリスクが存在 する。 o もしクライアントが、そのサーバはTLS対応していることを知っていれば、 OPTIONSのように何の処理も行わないメソッドとともにUpgradeリクエスト を送信するだけで、TLSを使用するように主張することができる。 o 最後に、https:規定で警告しているように、「ユーザは、サーバから提供 される証明書を慎重に調べ、期待を満たすものかどうかを決定すべきで ある」。 さらに、明示的にTLSを呼び出そうとしないクライアントに対しては、サーバは、 101または426以外のレスポンスにおいてUpgradeヘッダを使用することにより、 TLS対応していることを通知することができる。TLS対応はサーバの特長であり、 サーバの持つリソースではないと考えられるため、一度だけそれを送信し、 クライアントにその事実をキャッシュさせれば十分である。 8.1 https: URIスキームのその他の意味 このメモにある事項は、'https' URIスキームの定義には何も影響しないが、HyperText コンテンツに対してこのメカニズムを広範囲に採用することにより、セキュアと非 セキュアなリソースの両方を特定するのに'http'を使用することができるであろう。 どのようなセキュリティ特性がコネクションに必要であるかに関する選択は、 クライアントとサーバに残される。これにより、どちらのパーティーにおいても、 この決定を行うに際しては、どのような情報でも利用することができる。 例えば、ユーザエージェントはユーザの好みの設定、またはネットワークのセキュ リティに関する情報、例えば「このローカルネットワーク以外でのすべてのPOST 処理においてTLSが必要である」というようなものに基づいてもよい。または、 サーバはリソースへのアクセスルール、例えば「このページのFORMの提供と提出 には、TLSを使用しなければならない」というルールを適用してもよい。 8.2 CONNECTのセキュリティに関する考察 一般的なTCPトンネルはセキュリティリスクに関して、悲惨な状態にある。 まず、 その認可はわずかな数の既知ポートに制限されるべきである。ここで定義された Upgrade: メカニズムは、ポート80での前方トンネリングを必要とするだけである。 次に、トンネルされたデータはプロキシにとって未知であるため、他の既知または 予約ポートのトンネリングにはさらなるリスクがある。例えば、HTTPクライアント を装い、ポート25へCONNECTingすることにより、SMTPを通じてのスパムをリレー することができるかもしれない。 参考文献 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [2] Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic Syntax", RFC 2396, August 1998. [3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [4] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "Web Distributed Authoring and Versioning", RFC 2518, February 1999. [5] Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections Protocol", Work In Progress. [6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999. [7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. [8] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers", Work In Progress. (Also available in: Luotonen, Ari. Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.) [9] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 著者のアドレス Rohit Khare 4K Associates / UC Irvine 3207 Palo Verde Irvine, CA 92612 US Phone: +1 626 806 7574 EMail: rohit@4K-associates.com URI: http://www.4K-associates.com/ Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place Suite 400 Maynard, MA 01754 US Phone: +1 978 461 0888 EMail: lawrence@agranat.com URI: http://www.agranat.com/ 付録 A. 謝辞 CONNECTメソッドは元々、Netscape Communications 社のAri Luotonenによる、 "Tunneling TCP based protocols through Web proxy servers" [8] と題された Work in Progressにおいて記述されたものである。これはHTTPプロキシにより 広く実装されたが、IETF 標準化ドキュメントにはならなかった。メソッド名 のCONNECTは予約されたが、[1]には定義されなかった。 ここで示された定義は、その以前のメモから直接取られたものであり、編集上の 修正と、すでに確立されている他のHTTP規定での慣例に合わせるための用法上の 修正が行われている。 さらに以下の方々にも感謝する。 o Paul Hoffman、ESMTPにおけるSTARTTLSコマンド拡張。 o Roy Fielding、 Upgradeの背景原理と、OPTIONSとの相互作用に関する 協力。 o Eric Rescorla、現在のhttps:の標準化との比較。 o Marshall Rose、xml2rfcドキュメントタイプの記述とツール[9]。 o Jim Whitehead、現在利用可能なHTTPステータスコードの抽出。 o Henrik Frystyk Nielsen、必須拡張メカニズムにおいて、段階的変更に よるUpgradeではトンネリングが必要であることを指摘。 o Harald Alvestrand、トークン登録ルールの改善。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. あとがき RFCエディタ機能の基金は現在、Internet Societyによって提供されている。 日本語訳 西原 啓輔 2001年5月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。