15 セキュリティについての考察 この章はアプリケーション開発者、情報提供者、そしてユーザにこの文書で 記述されているような HTTP/1.1 のセキュリティ限界を知らせるという意図 を持つ。このディスカッションでは明示される問題の決定的な解決方法を含 んでいないが、セキュリティリスクを減らすためのいくつかの提案を行って いる。 15.1 個人情報 HTTP クライアントはしばしば多くの量の個人情報 (例えばユーザの名前、場 所、メールアドレス、パスワード、暗号キー、等々) を管理しているので、 この情報を HTTP プロトコル経由で他のリソースへと知らないうちに漏洩し ていないように特に気をつける *べきである*。我々は、ユーザがそのような 情報の公開についてを制御するための便利なインタフェースが提供される事 と、設計者や実装者はこの部分を特に注意する事を特に強く推奨する。歴史 的に、この部分のエラーがしばしば深刻なセキュリティやプライバシー問題 を引き起こし、その結果実装者の会社に対して不利な評判を高めている。 15.1.1 サーバログ情報の乱用 サーバは、読み込みの傾向や興味の対象で識別されるであろうユーザのリク エストについての個人情報を保存する立場にある。この情報は本質的に明ら かに秘密であり、その扱いは国によっては法によって統制されているであろ う。データを供給するために HTTP プロトコルを使用している人々は、その ようなデータは発行された結果、身元がわかってしまうその個人の許可無し には配布されないという事を保証しなければならない。 15.1.2 機密性の高い情報の転送 一般的なデータ転送プロトコルと同様に、HTTP は転送されるデータの内容を 規制する事はできないし、与えられるリクエストの状況の中でその情報の特 定の部分の機密性を決定するためのどんな優先的方法もない。それ故に、ア プリケーションはこの情報の供給者にできるだけ多くこの情報の制御機能を 供給す *べきである*。この状況において特に言及の価値がある四つのヘッダ フィールドが Server, Via, Referer, From である。 サーバの具体的なソフトウェアのバージョンを示す事によって、サーバマシ ンはあるセキュリティホールが知られているソフトウェアに対するアタック を受けやすくなるかもしれない。実装者は、Server ヘッダフィールドを設定 可能なオプションとす *べきである*。 ネットワークファイアウォールの入口の役割を果たすプロクシは、ファイア ウォールの内側にあるホストを識別するヘッダ情報の転送について特に用心 す *べきである*。特に、ファイアウォールの内側で生成されたすべての Via フィールドは削除するか安全なものに置き換える *べきである*。 Referer ヘッダは、読み込み傾向を調査したりやリンクの逆引きをできるよ うにさせる。これはとても有用であるが、もしユーザの詳細が Referer に含 まれる情報から分けられていなければ、その力は悪用されうる。さらに個人 情報が既に削除されていても、Referer ヘッダは公表が不適当であろうプラ イベート文書の URI を示すかもしれない。 From フィールドで送られる情報はユーザのプライバシー観念やサイトのセキ ュリティポリシーに反するかもしれないので、ユーザがそのフィールドの値 を無効、有効、変更ができないのであれば転送される *べきではない*。ユー ザは、ユーザ設定やアプリケーションの初期設定においてこのフィールドの 内容をセットでき *なければならない*。 必ずというわけではないが、我々はユーザが From と Referer 情報の送信を 有効、無効にできるようにする便利なトグルインターフェースを提案する。 User-Agent (section 14.43) や Server (section 14.38) ヘッダフィールド は、時々そのクライアントやサーバが搾取{exploit} 可能な特定のセキュリ ティホールを持っているという事を判別するために使われる。不幸な事に、 この同じ情報は現在の HTTP ではそれ以上の仕組みを持たない他の貴重な目 的にもしばしば使われる。 15.1.3 URI での機密性の高い情報のエンコード リンクのソースがプライベートな情報、あるいは他のプライベートな情報の ソースを明らかにしてしまうかもしれないので、ユーザが Referer フィール ドを送信するかどうかを選択できるようにする事を強く推奨する。例えば、 ブラウザクライアントは公然に／匿名にブラウジングするためのトグルスイ ッチを持ち、Referer や From の各情報の送信をそれぞれ有効／無効とでき る。 クライアントは、参照されるページがセキュアプロトコルで転送された場合 は、(セキュアで無い) HTTP リクエストにReferer ヘッダフィールドを含む *べきではない*。 HTTP プロトコルを使うサービスの作者は、その Request-URI にエンコード されたデータが現れるので、機密性の高いデータの提出に GET を使ったフォ ームを使う *べきではない*。多くの現存のサーバやプロクシ、ユーザエージ ェントは、第三者が見るかもしれない場所にその Request-URI を記録するで あろう。サーバは、代わりに POST を使ったフォームを使うべきである。 15.1.4 Accept ヘッダに関連するプライバシーの問題 Accept リクエストヘッダは、アクセスされたすべてのサーバにユーザに関す る情報を表す事ができる。特に Accept-Language ヘッダは、特定の言語を理 解するという事がしばしば特定の民族グループの一員である事と強く関連付 けられているため、個人的な性質であるとみなすであろう情報を表す。リク エスト毎に送られる Accept-Language ヘッダの内容を設定するためのオプシ ョンを提供するユーザエージェントは、設定のプロセス中にそれがユーザの プライバシーの損失になるという事に気づかせるようなメッセージを含むよ うにする事が強く推奨される。 プライバシーの損失をより制限するためには、ユーザエージェントがデフォ ルトでは Accept-Language ヘッダを送信しないようにし、サーバによって生 成された Vary レスポンスヘッダフィールドを見つけ、その送信によってサ ービスの品質を向上できるとわかった場合に、サーバに Accept-Language ヘ ッダを送る事を開始するどうかをユーザに尋ねるようにする。 ユーザによって設定された詳細な Accept ヘッダフィールドがリクエストご とに送られ、特にそれらが品質値を含んでいたら、比較的信頼でき長い間住 んでいる{long-lived} ユーザを識別するものとしてサーバによって使われう る。そのようなユーザを識別するものは、内容供給者がクリックの追跡 {click-trail tracking} をできるようにし、共同で作業する内容供給者が個 々のユーザのサーバ越しのクリックの追跡{cross-server click-trail} やフ ォーム提出と一致できるようにする。プロクシの内側でない多くのユーザに とって、ユーザエージェントが実行されているホストのネットワークアドレ スも長く住んでいる{long-lived} ユーザを識別するものとして役に立つとい う事に注意せよ。プロクシがプライバシーを高めるために使用されている環 境においては、ユーザエージェントはエンドユーザに accept ヘッダコンフ ィギュレーションオプションを提供する事には保守的であるべきである。極 端なプライバシー手段として、プロクシは中継されたリクエストにおける accept ヘッダをフィルタできる。高いヘッダ設定機能を供給する一般的な目 的のユーザエージェントは、伴う可能性のあるプライバシーの損失に関して ユーザに警告す *べきである*。 15.2 ファイル名やパス名に基づく攻撃 HTTP オリジンサーバの実装は、HTTP リクエストによって返される文書はサ ーバ管理者によって意図されたものだけに制限するように注意す *べきであ る*。HTTP サーバがファイルシステムコールを含む HTTP URI を直接解釈す る場合、サーバは HTTP クライアントへの配信を意図しないファイルを送信 しないように特に注意を払わ *なければならない*。例えば、UNIX や Microsoft Windows や他のオペレーティングシステムはカレントディレクト リの上の階層のディレクトリを表すパス要素として ".." を使う。そのよう なシステムにおいては、HTTP サーバ経由でアクセス可能である事が意図され ている外部リソースへのアクセスが別の方法で許されている場合、HTTP サー バは Request-URI 中にそのような構造のものを許し *てはならない*。同様 に、サーバ内部でのみでの参照が意図されたファイル (アクセス制御ファイ ル、設定ファイル、スクリプトコード等) は、機密性の高い情報を含んでい るので、不適当な検索から保護され *なければならない*。経験的に、そのよ うな HTTP サーバインプリメンテーションの小さなバグがセキュリティリス クになっている。 15.3 DNS スプーフィング HTTP を使用しているクライアントは Domain Name Service に非常に頼って おり、従って一般的に IP アドレスと DNS 名の故意なる間違った組み合わせ をベースとしたセキュリティアタックが行われる傾向にある。クライアント は、IP アドレス/DNS 名の組み合わせの正当性の連続についての仮定にて注 意深くある必要がある。 特に、HTTP クライアントは前回のホスト名 lookup の結果のキャッシュより も、IP アドレス/DNS 名組み合わせの確認についてはそのネームリゾルバを 頼る *べきである*。多くのプラットフォームは適切な時期に既にローカルに ホスト名 lookup をキャッシュできるので、そうするように設定す *べきで ある*。しかし、これらの lookup はネームサーバによって報告された TTL (Time To Live) 情報がキャッシュされた情報がおそらく有効であるであろう とした時にのみキャッシュされるのが適切である。 もし HTTP クライアントがパフォーマンスを改善させるためにホスト名 lookup の結果をキャッシュするなら、DNS によって報告される TTL 情報を 監視し *なければならない*。 もし HTTP クライアントがこのルールを守らないと、それらは直前にアクセ スしたサーバの IP アドレスが変更された時にだまされる。ネットワークの 数値再割り当てがますます一般的になってくる事が予想されるため [24]、こ の形式のアタックの可能性は高くなる。従って、この要求を監視する事によ ってこの潜在的なセキュリティの弱さを減らす。 また、この要求は同じ DNS 名を使用している複製されたサーバに対してクラ イアントのロードバランシング{load-balancing} 動作を改善し、この作戦を 使うサイトをアクセスした場合にユーザが直面する失敗の可能性を減らす。 15.4 Location ヘッダとスプーフィング もし単一のサーバがお互いを信頼していない複数の組織をサポートするなら ば、権限を持っていないところでリソースを無効にしないようにと気をつけ るため、示された組織の制御の元で生成されたレスポンスの Location ヘッ ダと Content-Location ヘッダの値をチェックし *なければならない*。 15.5 Content-Disposition 問題 RFC 1806 [35] は、HTTP ではしばしば実装されている Content-Disposition ヘッダについてのものだが、これはいくつかの深刻なセキュリティ上の問題 を抱えている。Content-Disposition は HTTP 標準では無いが、広く実装さ れているので、我々は実装者にその使用法とリスクについて記述している。 詳細については (RFC 1806 を更新した) RFC 2183 [49] を参照。 15.6 認証用証明書と無配慮なクライアント 現存の HTTP クライアントやユーザエージェントは、典型的に認証情報を無 期限に保持している。HTTP/1.1 では、サーバがクライアントこれらのキャッ シュされた証明書を破棄させるようにするための方法は提供していない。こ れは、HTTP の将来の拡張で要求される重大な欠点である。そのような証明書 がキャッシュされた状況ではアプリケーションのセキュリティモデルに従っ て干渉する事ができるが、以下については制限がない。 - サーバがクライアントにユーザの証明書の再提出を望んだ後に延長され た期間アイドル状態であるクライアント - サーバサイドのアプリケーションがクライアントがこれ以上証明書を保 持する理由がないと `知った' 後にセッションの終了を示すもの (例え ばページの下にある `logout' や `commit' ボタン) を受けたアプリケ ーション これは現在切り離され研究されている。この問題に一部にまつわるものがい くつかあるが、我々はスクリーンセーバへのパスワードプロテクト、アイド ル時のタイムアウト、その他この問題が本来持っているセキュリティ問題を 軽減するための方法を使用する事を推奨する。特に、証明書をキャッシュす るユーザエージェントにはユーザが簡単にキャッシュされた証明書を破棄を 指示できるようなメカニズムを提供する事を推奨する。 15.7 プロクシとキャッシング その性質から必然的に、HTTP プロクシは人と人の間に入り{men-in-the- middle}、中継人による攻撃{man-in-the-middle attacks} の機会が与えられ る。プロクシが運転されているシステムの妥協{compromise} が深刻なセキュ リティとプライバシーの問題を引き起こす。プロクシはセキュリティに関係 した情報、ユーザ個人やその団体についての個別の情報、ユーザやそのプロ バイダが所有する所有者情報にアクセスする。妥協したプロクシや、セキュ リティやプライバシーの問題に無関心に実装、形成されたプロクシは、様々 な可能性を持つ攻撃に使われる。 プロクシのオペレータは、機密性の高い情報を含み、また転送するシステム を守るように、プロクシが運転しているシステムを守るべきである。特に、 プロクシによって集められたログ情報はしばしば特に機密性の高い個人情報 や組織情報を含んでいる。ログ情報は注意深く監視すべきであり、改善や更 新のための使用にも適切なガイドラインを設けるべきである。(section 15.1.1) キャッシングプロクシは、キャッシュの内容が悪意ある利用には魅力的なタ ーゲットを表しているので、潜在的な弱点が付け加えられる。キャッシュの 内容が HTTP リクエストが完了した後もずっと残っているので、キャッシュ へのアタックでユーザがその情報はネットワークからは既に削除されたと信 じているずっと後にその情報を見る事ができる。それ故に、キャッシュの内 容は機密性の高い情報として守られるべきである。 プロクシの実装者は、その設計やコーディングの決定、そしてプロクシオペ レータへ提供する設定オプション (特にデフォルトの設定) がプライバシー やセキュリティに関わるという事を考慮すべきである。 プロクシのユーザは、プロクシを運転する人間しか信頼する価値のある人は いないという事を知っておく必要がある。HTTP 自身はこの問題を解決できな い。 暗号を適切な時に適切に使う事は、広い範囲のセキュリティや個人への攻撃 に対しての防御に十分なものとなろう。このような暗号については HTTP/1.1 の仕様書の範囲を超える。 15.7.1 プロクシを使ったサービス拒否攻撃 この攻撃は存在する。この攻撃を防御する事は難しい。調査を続けよ。用心 せよ。 16 謝辞 この仕様書では、RFC 822 [9] で David H. Crocker によって定義された拡 張 BNF と共通概念を多数使用している。同様に、MIME [7] で Nathaniel Borenstein と Ned Freed によって提供された多くの定義を再利用してい る。我々は、この仕様書内に含まれる事柄が過去に HTTP とインターネット メールメッセージフォーマットとの間にあった混乱を減らす助けとなって欲 しいと願っている。 HTTP プロトコルは、1年でかなり発展した。これは、大きな、そして活発な www-talk メーリングリストに参加している多くの人々から成る開発者コミュ ニティのおかげであり、そしてそコミュニティは一般に HTTP や World-Wide Web を成功させるために最も責任のあるコミュニティである。Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, Marc VanHeyningen 各氏は、このプロトコルの初期の概観を定義したという 努力に対して特に評価されるに値する。 この文書は、おおいに HTTP-WG に参加するすべての人のコメントのおかげで ある。既に述べた人達の他に、以下の方々がこの仕様書に貢献してくれた。 9 付録 19.1 インターネットメディアタイプ message/http と application/http HTTP/1.1 プロトコルの定義に追加して、この文書ではインターネットメディ アタイプ "message/http" と "application/http" についての仕様を示す。 message/http タイプは単一の HTTP リクエストやレスポンスメッセージを含 むために使う事ができ、行長さやエンコーディングに関するすべての "message" タイプが受ける MIME 制限 に従う。application/http タイプは 一つ以上の HTTP リクエストやレスポンスメッセージ（混合されてはいない もの）のパイプラインを含むために使う事ができる。以下のものが IANA に て登録されている。 メディアタイプ名: message メディアサブタイプ名: http 必要なパラメータ: 無し 省略可能なパラメータ: version, msgtype version: メッセージに同封された HTTP-Version 番号 (例えば "1.1" 等) 。もしが与えられていなければ、ボディの最初の行から 決定する事ができる。 msgtype: メッセージタイプ、すなわち "request" か "response"。も し与えられていなければ、ボディの最初の行で決定する事が できる。 Encoding についての考察: "7bit", "8bit", "バイナリ" のみが許され る。 Security についての考察: 無し メディアタイプ名: application メディアサブタイプ名: http 必要なパラメータ: 無し 省略可能なパラメータ: version, msgtype version: メッセージに同封された HTTP-Version 番号 (例えば "1.1" 等) 。もしが与えられていなければ、ボディの最初の行から 決定する事ができる。 msgtype: メッセージタイプ、すなわち "request" か "response"。も し与えられていなければ、ボディの最初の行で決定する事が できる。 Encoding についての考察:このタイプに含まれる HTTP メッセージは "バイナリ" フォーマットである。すなわち、転送が E-mail 経由で行われる時には、適切な Content-Transfer-Encoding が使われる必要となる。 Security についての考察: 無し 19.2 インターネットメディアタイプ multipart/byteranges HTTP 206 (Partial Content) レスポンスメッセージが複数の範囲の内容 (複 数の重ならない範囲のリクエストへのレスポンス) を含む時、これらはマル チパートメッセージボディとして転送される。この目的のためのメディアタ イプは "multipart/byteranges" と呼ばれる。 multipart/byteranges メディアタイプは二つ以上の部分を含み、それぞれに 自身の Content-Type と Content-Range フィールドを持つ。要求される境界 パラメータはそれぞれのボディ部分を分けるために使われる境界文字列を指 定する。 メディアタイプ名: multipart メディアサブタイプ名: byteranges 必要なパラメータ: boundary 省略可能なパラメータ: 無し Encoding についての考察: "7bit", "8bit", "バイナリ" のみが許され る。 Security についての考察: 無し 例を見よ。 HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 500-999/8000 ...最初の範囲... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000 ...次の範囲 --THIS_STRING_SEPARATES-- 注意 1) エンティティの最初の境界文字列の前に追加の CRLF を置く事ができ る。 2) RFC 2046 [40] ではクォートされた境界文字列を認めているが、既存 のインプリメンテーションの中にはクォートされた文字列を不適切に 扱うものがある。 3) いくつかのブラウザやサーバは multipart/x-byteranges というメデ ィアタイプを使用するバイト範囲の仕様の初期ドラフトに基づいてコ ーディングされているが、それは HTTP/1.1 にて記述されるバージョ ンとは、ほぼ互換性はあるものの、完全互換ではない。 19.3 寛容なアプリケーション この文書は HTTP/1.1 メッセージの生成についての要求を表しているもので あるが、すべてのアプリケーションが正しくそれらを実装しているわけでは 無いであろう。故に、我々は作業アプリケーションはもし実装から逸脱する 部分があってもそれが明確に中間処理できる時は、逸脱に対して寛容である 事を推奨する。 クライアントはステータスラインの解析において、またサーバはリクエスト ラインの解析時においてそれぞれ寛容である *べきである*。特に、例えそこ には単一の SP のみが必要だったとしても、フィールド間のいかなる量の SP や HT 各文字列を受け入れる *べきである*。 message-header フィールドについての行末は CRLF シーケンスである。しか し我々は、アプリケーションがそのようなヘッダを解析する時には、単一の LF を行末として認識しその前の CR を無視する事を推奨する。 エンティティボディの文字セットは、US-ASCII や ISO-8859-1 ラベルをもっ てエンティティをラベル付けされるという事以上に好まれるラベル付けは無 いという例外を除けば、そのボディで使用されている文字コードの共通点が 最も低い特徴としてラベル付けされる *べきである*。section 3.7.1 や 3.4.1 参照。 日付の解析やエンコーディング上の要求や日付エンコーディングに伴うその 他の潜在的な問題に対する追加的規則には以下が含まれる。 - HTTP/1.1 クライアントやキャッシュは、将来において 50 年を越えて 現れると思われる RFC-850 日付は実際過去のものであると仮定す *べ きである* (これは "2000年" 問題を解決する助けとなる)。 - HTTP/1.1 インプリメンテーションは解析された Expires 日付を適切な 値よりも早いように内部的に表す事が *できる* が、解析された Expires を適切な値よりも遅いように内部的に表し *てはならない*。 - 有効期限に関連するすべての計算は、GMT で行われ *なければならな い*。ローカルタイムゾーンは経過時間や有効期限の計算や比較に影響 を及ぼし *てはならない*。 - HTTP ヘッダが誤って GMT 以外のタイムゾーンの日付値を転送してしま った場合、最も可能な限り保守的な変換を使って GMT へと変換され *なければならない*。 19.4 HTTP のエンティティ と RFC2045 のエンティティとの違い HTTP/1.1 は、エンティティが公開されている様々な表現や拡張可能なメカニ ズムによって転送できるようにするためにインターネットメール (RFC 822 [9]) や Multipurpose Internet Mail Extensions (MIME [7]) のために定義 されている多くの構造を使用する。しかし、RFC 2045 ではメールについて議 論し、HTTP は RFC 2045 中に表されているものとは違ういくつかの特徴を持 っている。これらの違いはバイナリ接続以上にパフォーマンスを最適化する ために、新しいメディアタイプをより自由に使用できるために、日付の比較 を容易にするために、そしていくつかの初期の HTTP サーバやクライアント の実行を認めるために注意深く選ばれた。 この付録では HTTP が RFC 2045 と異なる具体的な部分を表す。厳密な MIME 環境へのプロクシやゲートウェイはこの違いを知る *べきであり* 必要な部 分での適切な変換を提供す *べきである*。また MIME 環境から HTTP へのプ ロクシやゲートウェイもいくつか変換が必要であるのでこの違いを知る必要 がある。 19.4.1 MIME-Version HTTP は MIME 準拠のプロトコルではない。しかし、HTTP/1.1 メッセージは そのメッセージを構成するためにどんな MIME プロトコルのバージョンが使 用されたかを示すために単一の MIME-Version 一般ヘッダフィールドを含む 事が *できる*。MIME-Version ヘッダフィールドの使用は (RFC 2045[7] に て定義されるように) そのメッセージが MIME プロトコルの完全に追従して いる事を示す。プロクシ／ゲートウェイは HTTP メッセージを厳密な MIME 環境にエクスポートする時に (それが可能であれば) 完全に追従している事 を保証する責任を持つ。 MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT MIME バージョン "1.0" は HTTP/1.1 で使うデフォルトである。しかしなが ら、HTTP/1.1 メッセージの解析やセマンティクスはこの文書によって定義さ れ MIME の仕様ではない。 19.4.2 公式形式への変換 RFC 2045 [7] は、RFC 2049 [48] の section 4 にて記述される様に、イン ターネットメールエンティティが転送される前に公式形式に変換される事を 要求する。この文書の section 3.7.1 では HTTP 上を転送される時の "text" メディアタイプのサブタイプについて認められる形式を記述してい る。RFC 2046 は、"text" タイプを伴う内容は CRLF をもって行末を表し、 行末シーケンス以外の CR や LF の使用を禁止する事を要求する。HTTP では メッセージが HTTP 上を転送される時にはテキスト内容の行末を示すために CRLF、単独の CR、単独の LF を認めている。 可能であれば、HTTP から厳密な MIME 環境へのプロクシやゲートウェイはこ の文書の section 3.7.1 にて記述されたテキストメディアタイプに含まれる すべての行末を RFC 2049 の公式形式である CRLF に変換す *べきである*。 しかし、HTTP がいくつかのマルチバイト文字セットのための場合として、 Content-Encoding がある事や、CR と LF を表すためにオクテットの 13 と 10 を使わないいくつかの文字セットの使用を認めているという事実によって これが複雑になっているかもしれない事に注意せよ。 実装者は、もし元の内容が既に公式形式であるので無ければ、変換は元の内 容に適用されている暗号チェックサムを壊してしまうであろう事に注意せ よ。故に、公式形式は HTTP 中にてチェックサムを使うあらゆる内容に対し て推奨される。 19.4.3 日付フォーマットの変換 HTTP/1.1 は日付比較の処理を簡単にするために制限された日付フォーマット (section 3.3.1) のセットを使用する。他のプロトコルからのプロクシやゲ ートウェイは、確実にメッセージ中に与えられるあらゆる Date ヘッダも HTTP/1.1 フォーマットの一つに従い必要であれば日付を書き換える *べきで ある*。 19.4.4 内容コーディングの導入 RFC 2045 は HTTP/1.1 の Content-Encoding ヘッダフィールドに相当するど んな概念も含んでいない。これはメディアタイプを修正子のように動作する ので、HTTP から MIME 準拠のプロトコルへのプロクシやゲートウェイは Content-Type ヘッダフィールドの値を変更するか、あるいはメッセージを転 送する前にエンティティボディをデコードするかし *なければならない*。 (インターネットメールについての Content-Type のいくつかの実験的なアプ リケーションは既に Content-Encoding と等価な機能を行う ";conversions=" のメディアタイプパラメータを使用して いる。しかし、このパラメータは RFC 2045 の一部ではない。) 19.4.5 No Content-Transfer-Encoding HTTP は RFC 2045 の Content-Transfer-Encoding (CTE) フィールドを使用 していない。MIME 準拠のプロトコルから HTTP へのプロクシやゲートウェイ は HTTP クライアントへとレスポンスメッセージを配信する前にあらゆる identify で無い CTE ("quoted-printable" や "base64") エンコーディング を取り除か *なければならない*。 HTTP から MIME 準拠のプロトコルへのプロクシやゲートウェイはメッセージ がそのプロトコル上で安全に転送されるための正しいフォーマットとエンコ ーディングがなされる事を保証する責任を持つが、ここでの "安全な転送" とは使用されているプロトコルの制限によって定義される。そのようなプロ クシやゲートウェイは、もしそうする事が目的のプロトコル上での安全な転 送の可能性を高めるのであれば、適切な Content-Transfer-Encoding を持っ たデータをラベル付けす *べきである*。 19.4.6 転送エンコーディングの導入 HTTP/1.1 は Transfer-Encoding ヘッダフィールド (section 14.41) を導入 する。プロクシ／ゲートウェイは MIME 準拠のプロトコル経由でメッセージ を転送する前にあらゆる転送コーディングを削除し *なければならない*。 "chunked" 転送コーディング (section 3.6) をデコードするための処理は以 下の疑似コードによって表される: length := 0 read chunk-size, chunk-extension (if any) and CRLF while (chunk-size > 0) { read chunk-data and CRLF append chunk-data to entity-body length := length + chunk-size read chunk-size and CRLF } read entity-header while (entity-header not empty) { append entity-header to existing header fields read entity-header } Content-Length := length Remove "chunked" from Transfer-Encoding 19.4.7 MHTML と行末制限 MHTML [45] インプリメンテーションに伴うコードを共有する HTTP インプリ メンテーションは、MIME 行末制限に気をつける必要がある。HTTP にはその ような制限は無いので、HTTP は長い行を折り返さない。HTTP によって転送 されている MHTML メッセージは、HTTP はすべてのメッセージボディを付加 物{payload} として転送し、その中に含まれるであろう内容や MIME ヘッダ ラインを解釈しないので、行末制限、折り返し、公式化などを含んだ、すべ ての MHTML の慣習に従う。 19.5 追加機能 RFC 1945 や RFC 2068 ではいくつかの既存の HTTP インプリメンテーション によって使われているプロトコル要素について記述したが、これらは多くの HTTP/1.1 アプリケーションを通じて一貫していなく、また正確ではない。実 装者はこれらの機能を知っておいたほうがよいが、他の HTTP/1.1 アプリケ ーションにおいてそれらの存在や通信協力{interoperability} を当てにはで きない。これらの内のいくつかは実験的な機能として提案されるものを示 し、またいくつかは基本の HTTP/1.1 仕様書中に現在表された欠如を実験的 な配置が見つける機能を記述する。 Content-Disposition や Title のような、SMTP や MIME からのいくつかの 他のヘッダもまたしばしば実装される (RFC 2076 [37] 参照)。 19.5.1 Content-Disposition Content-Disposition レスポンスヘッダフィールドは、ユーザがその内容を ファイルに保存したい場合にオリジンサーバがデフォルトのファイル名を提 案する事を意味するように勧告されている。この使用法は RFC 1806 [35] 中 の Content-Disposition の定義に由来する。 content-disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-parm ) disposition-type = "attachment" | disp-extension-token disposition-parm = filename-parm | disp-extension-parm filename-parm = "filename" "=" quoted-string disp-extension-token = token disp-extension-parm = token "=" ( token | quoted-string ) 例を見よ。 Content-Disposition: attachment; filename="fname.ext" 受信するユーザエージェントは filename-parm パラメータ中に表されている ディレクトリパス情報を尊重す *べきではない*。その時 HTTP インプリメン テーションに適用されるために信じられる唯一の情報だからである。ファイ ル名は端末構成部品としてのみ扱われる *べきである*。 もしこのヘッダが application/octet-stream コンテントタイプを伴ったレ スポンス中で使われるのであれば、ユーザエージェントはレスポンスを表示 すべきではなく、直接「レスポンスを名前を付けて保存」ダイアログを記入 する事が暗黙的に提案される。 Content-Disposition のセキュリティ上の問題については section 15.5 参 照。 19.6 前バージョンとの互換性 前のバージョンに従うように指示する事はプロトコル仕様書としての範疇を 超える。HTTP/1.1 は慎重に設計されたものではあるが、前のバージョンをサ ポートする事は簡単である。この仕様書を作った時 (1996) に、我々が HTTP/1.1 サーバに以下を期待していたであろう事に注目する価値はある。 - HTTP/0.9, 1.0, 1.1 それぞれのリクエストラインのフォーマットを認 識する - HTTP/0.9, 1.0, 1.1 それぞれのフォーマットのあらゆる有効なリクエ ストを理解する - クライアントが使ったものと同じメジャーバージョンのメッセージを伴 い適切に応答する また、我々は HTTP/1.1 クライアントには以下を期待していたであろう事に 注目する価値はある。 - HTTP/0.9, 1.0, 1.1 それぞれのステータスラインのフォーマットを認 識する - HTTP/0.9, 1.0, 1.1 それぞれのフォーマットのあらゆる有効なレスポ ンスを理解する 多くの HTTP/1.0 インプリメンテーションでは、それぞれの接続はリクエス トの前にクライアントによって確立され、レスポンスを送った後にサーバに よって切断される。インプリメンテーションの中には RFC 2068 [33] の section 19.7.1 中に記される Keep-Alive バージョンの持続的接続を実装し ているものがある。 19.6.1 HTTP/1.0 からの変更点 この章では HTTP/1.0 と HTTP/1.1 との間での主な違いを簡単に述べる。 19.6.1.1 複数割当{Multi-homed} Web サーバを簡単化し IP アドレスを保護す るための変更 クライアントとサーバは Host リクエストヘッダをサポートし、HTTP/1.1 リ クエストに Host リクエストヘッダ (section 14.23) が欠落していた場合は エラーを知らせ、絶対 URI (section 5.1.2) を受け入れる、という必要条件 はこの仕様書にて定義されている最も重要な変更の一つである。 古い HTTP/1.0 クライアントは IP アドレスとサーバの一対一の関係を仮定 していたので、そのリクエストが向けられた IP アドレスとは他にリクエス トの意図されたサーバを区別するための別の確立されたメカニズムが存在し なかった。上に概説された変更によって、インターネットは、かつての古い HTTP クライアントはもはや一般的では無い、単一の IP アドレスで複数の Web サイトをサポートできるようになり、単一のホストへの多くの IP アド レスの割り当てが深刻な問題を引き起こしているような、大きな作業上の Web サーバをより簡略化する事ができる。また、インターネットもルートレ ベルの HTTP URL 中で使われる特別な目的のドメイン名の唯一の目的に割り 当てられていた IP アドレスを取り返す事ができる。Web の成長率と既に設 置されたサーバの数を考慮に入れると、すべての HTTP インプリメンテーシ ョン (既存の HTTP/1.0 アプリケーションをアップデートしたものを含む) がこれらの要求を正しく実装する事は非常に重要である。 - HTTP/1.1 リクエストを送るクライアントは Host ヘッダを送ら *なけ ればならない*。 - クライアントとサーバ共に、Host リクエストヘッダをサポートし *な ければならない*。 - サーバは、HTTP/1.1 リクエストが Host リクエストヘッダを含んでい なければエラー 400 (Bad Request) を知らせ *なければならない*。 - サーバは 絶対 URI を受け入れ *なければならない*。 19.6.2 HTTP/1.0 持続的接続との互換性 クライアントやサーバの中には HTTP/1.0 のクライアントやサーバ中におけ る持続的接続についてある以前のインプリメンテーションと互換性を持たせ たいと思うかもしれない。HTTP/1.0 における持続的接続はそれらがデフォル トの振る舞いでは無いとして明確にネゴシエートされる。HTTP/1.0 の持続的 接続の実験的な実装には欠点があり、HTTP/1.1 における新しい機能はこれら の問題を改善するために設計されている。問題はある既存の 1.0 クライアン トが Connection を理解できないプロクシサーバへ Keep-Alive が送ってい るかもしれず、さらにインバウンドサーバに誤ってそれを転送するかもしれ ず、そうなると Keep-Alive 接続が確立され、その結果レスポンスでの切断 を待っている HTTP/1.0 プロクシのハングアップを引き起こす事になるであ ろう。これは HTTP/1.0 クライアントがプロクシと通信する時に Keep-Alive を使用する事を防がなければならないという事である。 しかし、プロクシとの通信は持続的接続の最も重要な使い方であり、その禁 止は明らかに受け入れる事はできない。故に、我々は Connection を無視す る古いプロクシと通信する時に使用しても安全な、持続的接続が望まれてい る事を示すための他のメカニズムを必要とする。持続的接続は HTTP/1.1 メ ッセージのデフォルトであり、我々は非持続性を宣言するための新しいキー ワード (Connection: close) を導入する。section 14.10 参照。 持続的接続の元の HTTP/1.0 の形式 (Connection:Keep-Alive や Keep-Alive ヘッダ) は RFC 2068 [33] 中に記述されている。 19.6.3 RFC 2068 からの変更点 この仕様書はキーワードの仕様について正しくまた曖昧で無い様に慎重に検 査された。RFC 2068 は RFC 2119 [34] 中に置かれた約定について多くの問 題を抱えていた。 インバウンドサーバの失敗のために使われるべきエラーコードは明らかにさ れる (例. DNS の失敗)。(Section 10.5.5) CREATE はリソースが最初に生成された時に送られる ETag を要求する種類を 持つ。(Section 10.2.2) Content-Base は仕様書から削除された。これは広くは実装されてはおらず、 また、逞しい{robust} 拡張メカニズム無しにこれを導入する事は単純なもの でも安全なものでも無い。加えて、これは MHTML [45] 中では似たようなも のが使われているが、同一のやり方ではない。 (自己分割できない転送コーディングを考慮に入れるために) チャンクエンコ ーディングが使用される場合、Transfer-coding とメッセージ長は全て正確 なる固定が要求される方法において相互動作する; どのようにメッセージ長 が計算されるかを正確に決定しておく事は重要であった。(Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) キャッシング中に発見される問題を解決するために、内容コーディングに "identity" が導入された。(Section 3.5) 0 という品質値は、クライアントが表現を拒否できるように "それを望まな い" という事を示すべきである。(Section 3.9) HTTP のバージョン番号の使用とその説明については RFC 2145 にて明示され た。プロクシは HTTP/1.0 インプリメンテーションに見られる問題を扱う事 をサポートするために最も高いプロトコルバージョンにアップグレードする 必要がある。(Section 3.1) Accept ヘッダ中の文字セット名の急激な増加を避けるために文字セットの ワイルドカード{Charset wildcarding} が導入された。(Section 14.2) ある事例が HTTP/1.1 の Cache-Control モデル中に入れ損なわれていた。よ って、s-maxage がこの抜けた事例を加えるために導入された。(Sections 13.4, 14.8, 14.9, 14.9.3) レスポンスの場合の Cache-Control: max-age 指示子が適切に定義されてい なかった。(Section 14.9.3) サーバ（特にプロクシ）がレスポンスの全長は知らないが、バイト範囲リク エストをする能力はあるという場合がある。故に、我々はメッセージの全長 を示さない content-range を伴ったバイト範囲を許すメカニズムを必要とす る。(Section 14.16) レンジリクエストは、既に全ての外部データが返されていた場合には、ひど く冗長になるであろう。しかし、サーバが 206 レスポンス中に必要なヘッダ のみを送る事ができるようにする事によって、この問題は解決できる。 (Section 10.2.7, 13.5.3, 14.27) 満足できないレンジリクエストに修正について。これには二つの場合があっ て、シンタックス上の問題と、その範囲が文書に存在しない場合とがある。 416 ステータスコードは、文書の実際の内容以外の点について失敗したバイ ト範囲リクエストのエラーを示すために、その曖昧さを解決するために必要 である。(Section 10.4.17, 14.16) ここにあるエラーの結果はインターネットに重要な影響を及ぼしうるので、 実装者が状況をこれ以上悪くする事を、また実装者が以下の問題を扱う事を 避けるためのメッセージ転送の必要条件の書き直し: 1. その部分が将来の HTTP/1.x バージョンの実装の振る舞いにおける必 要条件を不正確に示している文脈において、"HTTP/1.1 以降" を "HTTP/1.1" に変える 2. ユーザエージェントはリクエストを繰り返すべきであるが、一般に "クライアント" はそうすべきではない、という事を明らかにさせる。 3. クライアントは予期しない 100 (Continue) レスポンスを無視せよ、 またプロクシは 100 レスポンスを転送せよ、という必要条件を 1xx レスポンスに対する一般的な必要条件に変える。 4. いくつかの TCP に特定した言語を修正し、HTTP のためには TCP では ない転送でも可能であるという事をより明らかにする。 5. オリジンサーバは自身が要求された 100 (Continue) レスポンスを送 る前には、リクエストボディを待っ *てはならない* という事を必要 とする。 6. サーバはリクエストボディの一部を既に取得している場合は 100 (Continue) レスポンスを省略する事を、必要とするよりもむしろ、そ れを見込んでいる。 7. サーバはサービス不能攻撃や故障したクライアントから身を守る事が できる。 この変更により Expect ヘッダと 417 ステータスコードが付け加えられた。 メッセージ転送の必要条件は sections 8.2, 10.4.18, 8.1.2.2, 13.11, 14.20 の各セクションにて修正される。 プロクシは適切な時点で Content-Length を付け加える事ができるべきであ る。(Section 13.5.2) 403 と 404 の各レスポンスの区別を明らかにせよ。(Section 10.4.4, 10.4.5, 10.4.11) Warning が不正確にキャッシュされたリ、適切に更新されなかったりした。 (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, 14.46) また Warning は一般ヘッダである必要があり、よって PUT や他のメソッドではリクエスト 中にそれが必要となるであろう。 転送コーディングは、特にチャンク形式エンコーディングで相互作用する時 に、重要な問題を持っていた。これは転送コーディングが内容コーディング のように完全なものとなる事で解決する。これには転送コーディング (内容 コーディングとは別に) や新しいヘッダフィールド (TE) が IANA レジスト リに登録され、将来的に trailer ヘッダが使用可能になる事が必要となる。 転送エンコーディングはパフォーマンス上に大きな利益があるので、修正す る価値はある [39]。TE はその他の、チャンク形式にエンコーディングされ た認証用のもの{authentication trailers} と HTTP/1.0 クライアントとの 間の相互作用によって起こったはっきりしない下方の相互運用上の問題を解 決する。(Section 3.6, 3.6.1, 14.39) この仕様書の前のバージョンでは PATCH, LINK, UNLINK 各メソッドが定義さ れていたが、これは一般には実装されていない。 RFC 2068 [33] 参照。 この仕様書の前のバージョンでは Alternates, Content-Version, Derived- From, Link, URI, Public, Content-Base 各ヘッダフィールドが定義されて いたが、これは一般には実装されていない。 RFC 2068 [33] 参照。 20 索引 索引についてはこの RFC の PostScript 版を見ていただきたい。 21. 完全なる著作権宣言 Copyright (C) The Internet Society (1999). All Rights Reserved. この文章とその翻訳は、複製し他人に配布する事ができ、またその実装につ いてのコメント、その他の方法を用いた説明、その補助となるような派生的 作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て 又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事 ができる。しかしながら、インターネット標準化プロセスにて定義されてい る著作権のための手続きに従わなければならないような場合の中でインター ネット標準を開発するという目的に必要である、あるいは英語以外の言語に 翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示 や、インターネット学会あるいは他のインターネット団体への参照を削除す るような、いかなる変更もできない。 上で認めた制限された許諾は永続的なものであり、インターネット学会及び その継承者や譲渡者によって取り消される事は無い。 この文章とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供 され、*インターネット学会、及び IETF は、この中の情報の使用が、商用利 用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していな いという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄す る*。 謝辞 RFC Editer 機構の資金は、現在インターネット学会から提供されている。