この文書は、 K. Moore: On the use of HTTP as a Substrate (RFC 3205), February 2002. を 橋本英彦 が日本語訳した物です。 この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。
Network Working Group Request for Comments: 3205 BCP: 56 Category: Best Current Practice
K. Moore
University of Tennessee
February 2002
この文書は、インターネットコミュニティにおけるインターネット標準化過程プロトコルを規定し、改良のために議論と提案を求めるものである。 このプロトコルの標準化状態と状況については、"Internet Official Protocol Standards" (STD 1) の最新版を参照していただきたい。 この文書の配布に制限は無い。
Copyright © The Internet Society (2002). All Rights Reserved.
最近、他のアプリケーション層のプロトコルのための基層{substrate} としてハイパーテキスト転送プロトコル (HTTP) を使う事に広く関心が持たれてきている。この文書では、既定のポート、URL スキーム、HTTP セキュリティメカニズムの使用を含む、HTTP の使用についての技術的事項を推奨する。
最近、他のアプリケーション層のプロトコルのための基層としてハイパーテキスト転送プロトコル (HTTP) [1] を使う事に広く関心が持たれてきている。この関心を例証する様々な理由は以下のようなものである。
よく知られていて使い易い
広く使用されているブラウザとの互換性
既存のサーバやクライアントライブラリの再利用能力
CGI スクリプトや同様の拡張メカニズムを使う旧式のタイプのサーバでの利用の容易さ
ファイアウォールを越えられる HTTP の能力
とにかくしばしば HTTP をサポートする必要があるサーバの場合
インターネットコミュニティはプロトコルの再利用について長い伝統を持っており、それは FTP [5] や SMTP [6] の基層として Telnet [4] を使用する所まで遡る。 しかし、HTTP 上に新しいプロトコルを配置する事についての最近の関心では、そのような使用が適切であるのはいつか、またそれが適切な状況において HTTP を使うための適切な方法についての疑問の数が増えてきている。特に、HTTP 上に層をなすアプリケーションについては:
そのアプリケーションは HTTP の既定ポートである 80 以外のポートを使用すべきか?
そのアプリケーションは伝統的 HTTP メソッド (GET, POST 等) を使用すべきか、あるいは新しいメソッドを定義すべきか?
そのアプリケーションは http: URL を使用すべきか、あるいは自身の先頭部{prefix} を定義すべきか?
そのアプリケーションは自身の MIME-types を定義すべきか、あるいは(MIME-directory 機構に新しいタイプを登録するように) 既存のものを使用すべきか?
この文書ではこれらの疑問への回答としてある計画的決定{designdecisions} を推奨する。
この文書は、全ての場合に頑に守られなければいけない厳格な規則としてというよりも、プロトコル設計者、ワーキンググループ、実装者、IESG のための助言や推奨として意図されたものである。 それ故に、仕様書における適合性を表すための、RFC 2119 にて定義される大文字のキーワードは、この文書中では使用されない。
その利点は上で列挙したにも関わらず、HTTP は全てにおいて使用されるべきであるかどうか、あるいは完全なる HTTP プロトコルが使われるべきかどうかという事についての疑問を尋ねる事には価値がある。
HTTP は単純なプロトコルとして始まっているが、元々の設計では予測していなかった様々な機能の追加によってすぐにより複雑なものとなった。 これらの機能とは、持続的接続、バイトレンジ、内容ネゴシエーション、キャッシュのサポート等を含む。 これらは全て伝統的 web アプリケーションには有用であるが、HTTP の層上のアプリケーションには有用でないかもしれない。 これらの機能をサポートする (あるいは妨げる) 必要性によって、HTTP上に層をなすプロトコルの設計と実装の複雑性が増す事になる。 例え HTTP が実装の負荷を最小化するために "概略を描く{profile}" 事ができる時でさえ、そのような概略を描く努力は、手元の作業により適している目的に応じて作成されたプロトコルを見つける努力に勝るかもしれない。
もし既存の HTTP クライアントやサーバのコードがしばしば再利用できたとしても、HTTP 上に層をなすものと目的に応じて作られたプロトコルを使う事による新たな複雑性は、内部実行可能性{interoperability} の問題の数を増やす事になるだろう。
更に、HTTP は "遠隔手続呼出{remote procedure call}" のための転送方法として使用される事があるが、HTTP のプロトコル上の負荷と TCP の接続確立上の負荷によって、HTTP を使うという選択を悲しいものとしてしまう事になるだろう。 予見できる未来において付加物{payload} が小さく (数百バイト以下に) なりそうな場合、UDP, あるいは UDP と TCP の変形{variants} に基づいたプロトコルの使用が考慮されるべきである。 これは、そのプロトコルが頻度激しく使用されたり、あるいは時間やコストがかかるリンクに使用されたりする場合に、特に言える事である。 一方、接続確立上の負荷は、層上のプロトコルが HTTP/1.1 の持続的接続を利用する場合や、同じクライアントとサーバが HTTP 接続が開いている間に複数の相互動作を行うような場合は、取るに足らないものとなるであろう。
HTTP は一見したところ良質なセキュリティを提供する事ができる数少ない"成熟した" インターネットプロトコルの一つに見えるが、HTTPのダイジェスト認証や TLS を十分に扱えないようなアプリケーションが多くある。
ダイジェスト認証ではクライアントとサーバの間で秘密 (例えば, パスワード) を共有する必要がある。 加えて各々のクライアントが各々のサーバとの間に使用される秘密を知ってる必要があるが、そのパーティ間でそのような秘密を転送するあらゆるセキュリティを提供しない。共有された秘密は全てが物理的に接して設置されているような小さなグループでは上手く働くであろう; しかし、巨大な、あるいはユーザが分散しているようなコミュニティでは上手く働かないであろう。 更に、サーバが妥協をすれば多数の秘密が晒される事となり、同じ秘密 (やパスワード) が複数のアプリケーションで使われていたら特に危険である。(同様の事柄はクライアントやサーバに基づくTLS にもある - もし秘密鍵が妥協されていれば攻撃者はその鍵を持つ人間のふりをする事ができる。)
TLS やその前身の SSL は元々 web サーバがクライアントを認証するために設計されたものなので、ユーザは (例えば) その人のクレジットカード番号が詐称者には送信されないという事を保証できる。 しかし、多くのアプリケーションはクライアントやサーバを認証する事や、クライアントとサーバの相互認証を提供する必要がある。 TLS は各々の方向での認証を提供する能力は持つが、そのような認証は特定のアプリケーションにとっては適切であるかどうかはわからない。
TLS や SSL をサポートする web ブラウザは一般的に、それらが持つ CA (証明書認証局{certificate authorities}) の一つによって署名された公開鍵を持つ任意のサーバの識別を証明できるようにするために "接続されている" 複数の証明書認証局の公開鍵を送出する。 これが十分に動作している間、全てのセキュアな web サーバの公開鍵はその鍵が代表のブラウザに結び付けられている CA の一つによって署名されなければいけない。 この展開モデルは (相対的に) その鍵が僅かな数の異なるブラウザの中に含まれるような僅かな数の CA によって、その識別を証明する事ができる僅かな数のサーバがある時に働き、それらの公開鍵が署名する。
このスキームは何百万もの潜在的クライアントやサーバを認証するのには上手く働かない。 それを行うにはより多くの数の CA を費やすだろうし、そのそれぞれがサーバによって広く信頼される必要があるだろう。 またそれらの CA は、(少数の) 商業的なものやセキュアな web サーバを走らせる必要がある他の企業の識別を証明するために必要な時間よりも (多数の) 普通のユーザの識別を証明するためにより多くの時間を費やすであろう。
また、TLS によって多数のクライアントを認証するような場面においては、その鍵が全てのサーバに信頼されるような CA のセットがあるような事はないであろう。 それ故にサーバとセキュアな接続を確立しようとする時には潜在的に複数のサーバに認証される必要があるクライアントはそのサーバとの間に使われる鍵に応じて構成される必要があるであろう。
上記の理由により、クライアントの認証には TLS はほとんど使われない。 一般的な技術ではサーバがクライアントを認証し秘密チャンネルを確立する場合や、クライアントが他の方法 - 例えば、HTTP 基本認証やダイジェスト認証を使うユーザ名とパスワード - を使ってサーバを認証する場合には TLS を使う事になっている。
プライバシーが要求されるアプリケーションでは、(過去のアメリカ輸出規制や他の国における暗号技術の使用や輸出の規制に順応させるための) いくつかの SSL 実装によって提供される 40-bit の暗号スイート{ciphersuites} は適切ではない。 TLS 実装に適合している必要がある 56-bit DES 暗号でさえ、リソース中の粗末な投資によっておよそ数日で破られている。 そのため TLS の使用を選択した場合は、適切なプライバシーの保証を提供するため、短い長さの鍵や弱い暗号スイートの使用をやめさせる必要があるかもしれない。 TLS がクライアントによって送られるパスワードのプライバシーを提供するために使用される場合、長い鍵をサポートする事が特に必要である。
上記の文は、ダイジェスト認証や TLS が一般に他の認証システムに比べて劣っている、あるいは HTTP 以外に他のアプリケーション中で使われるのに適していないという事という風に捉えられるべきではない。 TLS やダイジェスト認証での多くの制限はまた他の認証方法やプライバシーシステムにあてはまる。 ここでの要点は TLS もダイジェスト認証も認証やプライバシーを解決するための "魔法の妖精が振り掛ける粉{magic pixie dust}" では無いという事である。 全ての場合において、アプリケーションの設計者は認証方法やプライバシーのメカニズムを選択する前にアプリケーションのユーザが要求する認証やプライバシーに十分に注意を払って決定しなければいけない。
また TLS は他の TCP ベースのプロトコルにも使用できる事や、HTTP ダイジェスト認証に似た SASL [7] メカニズムがあるという事にも注意せよ。 そのため TLS やダイジェストのような認証方法から利益を得るために HTTP を使う必要は無い。しかし、HTTP API は既に TLS やダイジェスト認証をサポートしているであろう。
HTTP の使用についてしばしば引用された理由の一つは、プロクシやファイアウォール、あるいはネットワークアドレストランスレイタ (NAT) を通り抜ける能力である。 ファイアウォールや NAT の不運な一つの結果は、個々の新しいプロトコルに適応させるための明示的な許可 (あるいはファイアウォールや NAT のソフトウェアのアップグレードさえも) が必要とされる事により、新しいインターネットアプリケーションを展開させる事がより難しくなっているという事である。 ファイアウォールや NAT の存在は、プロトコル設計者が HTTP を含む既存のプロトコルの上に新しいアプリケーションを層にするための強い動機を作るものである。
しかし、もしサイトのファイアウォールが未知のプロトコルの使用を妨げる場合、これはおそらくファイアウォール管理者の側で決定された意識的なポリシーである。 もっともそのようなポリシーがセキュリティを増強する際に制限された値であるというのであれば、これは要点の近くにある。 つまり、well-known ポート番号は様々な目的のために真に有用であり、またポート番号への過負荷はそのユーティリティを破壊するものになる。 サイトのセキュリティポリシーの裏をかこうと試みる事はそうする事を正当とする証拠として受け入れられるものではない。
既存のファイアウォールが新しいプロトコルとの互換性をより容易にもたせられるように、"ファイアウォールにやさしい" プロトコルのためのガイドラインを確立する事は有用であろう。
負荷サイズ{payload size} や転送パターンを考えた時に、HTTP はこのプロトコルの予想される使用にとって適切な転送方法であるか?
(言い換えれば、その負荷サイズは TCP や HTTP に関連する負荷ほどに価値を持つのであろうか? あるいはそのアプリケーションは複数のリクエストによる負荷によるコストを償還するためにHTTP 持続的接続の使用させる事ができるのだろうか?
その新しいプロトコルは既存の web ブラウザを変更する事なく使用できるか?
(例: そのリクエストは内容を伴った HTML フォームであるかのように転送されるか? 返されるレスポンスは HTML のように、web ブラウザから見る事ができるか?)
既存の HTTP セキュリティメカニズムがその新しいアプリケーションに適しているか?
その HTTP ステータスコードや HTTP ステータスコードパラダイムがこのアプリケーションに適しているか? (section 8 参照)
そもそもこのアプリケーションのためのサーバが HTTP をサポートする必要があるのか?
IANA は HTTP の使用のために TCP ポート番号 80 を予約していた。 それは実質的に新しいサービスが従来から使用するポート 80 を強奪する事は、それが基層として HTTP を使用するという事でさえ、適切ではない。 以下の内いずれかが真実の場合、HTTP の新しい用途は "実質的に新しいサービス" と考えられるかもしれないし、それ故に新しいポートを要求する。
"新しいサービス" および従来の HTTP サービスは、それらが両方とも同じホスト上で作動する場合さえ、異なるデータのセットに参照を付けるであろう。
少なくともいくつかのプラットフォーム上では、同じホスト上での従来のHTTP サービスより、"新しいサービス" が別々のサーバプロセスや別々のコードによって実装されるための十分な理由がある。
例えば、ファイアウォールのアクセスコントロールやトラフィックの分析という目的のために、従来の HTTP と "新しいサービス" のトラフィックを容易なる区別を望む十分な理由がある。
上記のどれにも当てはまらない場合、HTTP の新しい用途は "新しいサービス" ではなく、従来の HTTP に対する "拡張" であると言える。従来のHTTP サービスとデータを共有するような HTTP の拡張では、恐らく個別のポートを使用するよりも、それらの拡張を表現するための新しい HTTPの方法を定義すべきである。個別のポートが使用される場合、クライアントが、それらが別々のサービスなのか、あるいは根本的には同じサービスにアクセスするための異なる方法なのかという事を知る術は無い。
様々な URL スキームが広く使用されており、その内の多くが標準化されている過程の中にある。実際、URL スキームは URL の残りの部分の解釈を管理するための "タグ" として役立つだけでなく、アクセスされているリソースあるいはサービスの種類の粗い識別をできるようにする。例えば、web ブラウザは一般的に、ユーザが "http" URL 上をマウスクリックする時と "mailto"URL 上をクリックする時で異なるレスポンスを提供する。
この決定を行う中で使用されるかもしれない基準のいくつかを以下に示す:
この URL スキームは広く使用されるものになっていくのか、それともある制限下のコミュニティや非公式な合意によってのみ使用されるのか。
新しい "既定ポート" が必要かどうか。ポート 80 の再使用が適切でない場合 (上記参照)、新しい "既定ポート" が必要である。その URL スキームが広く使用されると予想される場合は、新しい既定ポートは、合わせて新しい URL スキームが登録される必要がある。URL中の明示的なポート番号は、通常の状況で使用されるものではなく、"避難手段" と見なされる。
新しいサービスの使用が通常の HTTP サービスより、サーバーとの間に本質的に異なるセットアップをあるいはプロトコル相互作用を要求するであろうかどうか。これには、ネットワークからの異なる種類のサービスを要求したり、帯域幅を予約したり、サーバ、サーバに貯蔵された物、あるいはその他に必要なものの数々へ異なる TLS 認証証明書を提示したりする必要を含む事ができる。
(web ブラウザのような) ユーザインタフェースが、ユーザビリティの中で意味のある改良を生み出すために URL 先頭部における違い開発する事ができるであろうかかどうか。
[8] 中の規則によれば、"http:" URI は URL スキーム名における "IETFTree" の一部であり、また IETF は "IETF Tree" の管理者である。 IESG がIETF における意志決定の中心であるので、IESG はあるリソースへアクセスする HTTP の上に乗るプロトコルが http: を使うべきか、それとも他の URL先頭部{prefix} を使うべきかを決定する権限を持つ。
"TLS あるいは SSL を使用する" という事を意味するために URL スキームに("http:" に対する "https:" のように) "s" を付加するという慣習は、標準的ではなく、制限的であるという事に注意せよ。 多くのアプリケーションにおいて、単一の "TLS あるいは SSL を使用する" ビットは、たとえクライアントが適切な証明書{credentials} を持っていたとしても、それがサーバにクライアント自身を認証する必要があるという情報を伝えるのに十分ではない。 例えば、TLS を用いて十分なセキュリティの確保を保証するために、アプリケーションは特定のサーバに認証するために使用される受理可能な暗号化スイート{ciphersuites} のリスト、あるいはクライアント証明書から構成される必要があるかもしれない。 URL 中に認証あるいは他の接続セットアップ情報を指定する事が必要な時は、URL 先頭部の中にではなく、URL パラメータの中で通信されるべきである。
HTTP はその付加物{payload} にラベリングするために MIME メディアタイプシステム [9] を使用するので、HTTP の層上の多くのアプリケーションはそれが使用されるための MIME メディアタイプを定義するか、あるいは選択する必要があるだろう。 特にマルチパート構造を使用する時は、メディアタイプの選択はより注意が必要である。特に:
text/directory [10] や XML [11, 12] のように、既存の枠組みが使用されるべきか、それとも新しい content-type が最初から作られるべきなのか?まさに HTTP の場合のように、コードが再使用できるのであればそれは有用であるが、プロトコル設計者は一般的であっても複雑な枠組みを新しいプロトコルに組み入れる事を過度に行おうとすべきではない。例えば、ASN.1 で得た経験では、一般的な枠組みを使用するという利点はコストの点でメリットがないかもしれないという事を示す。
MIME マルチパートやメッセージタイプが許されるべきだろうか?これは(例えば) multipart/alternative や MIME セキュリティの枠組みを組み入れる事が望ましい場合には利点となりえる。一方で、これらの構成は特に保存-転送 {store-and-forward} 電子メールシステムでの使用のために設計されたものであり、今考えられているアプリケーションにとっては他のメカニズムの方がより適切かもしれない。
ここでの要点は、プロトコル付加物 (一般には同じ付加物が他のアプリケーションに現われるかもしれない場合が望ましい) を表すために MIMEcontent-type 名を使用するための決定がアプリケーションは MIME マルチパートやセキュリティメカニズムを含む、任意の MIME content-type を受け入れなければならないという事を暗に意味するものではないという事である。また、そのアプリケーションが MIME 文法を使用したり、あるいは既存の MIME ヘッダフィールドを認識したり、更に許容しなければならないという事を暗に意味するものでもない。
もし同じ付加物が電子メールを通じて送られて来るかもしれない場合は、その付加物の HTTP エンコーディングと電子メールエンコーディングの違いは最小限にされるべきである。理想的には、その二つの環境においては"公の形式" にて違いはないとされるべきである。text/* メディアタイプについて、MIME 電子メールではボディ部分の改行には CRLF を必要とするが、HTTP は伝統的に LF のみを使用するため、この点で問題があるかもしれない。
MIME content-type ラベルはラベリングされる物の性質を表す。これは、それが受信された時に適用される意味論{semantics} を表すものではないし、またそのために使用されるべきでもない。例えば、HTTP POST を使用して特定の content-type の物が転送されるという事を、単にそのタイプに基づく動作のリクエストとして解されるべきではない。このリクエストはcontent-type ラベルとは切り離されるべきであり、またそれは明示的であるべきである。
HTTP 上に層をなすプロトコルによって同じタイプのものへ違う動作が行える様にする必要がある時は、いくつかの異なる方法: HTTP メソッド、HTTP リクエスト-URI、HTTP リクエストヘッダ、MIME Content-Disposition ヘッダフィールド、その付加物の部分において通信されるだろう。
HTTP 上で動作する新しいサービスは、新しいポートを割り当てるよりも、一つ以上の新しい HTTP メソッドを定義すべきであるという事が提案されている。 新しいメソッドの使用は適切であるかもしれないが、全てにおいて十分であるわけではない。 新しいプロトコルでの使用のための一つ以上の新しいメソッドの定義する事自体は、新しいポートや新しい URL タイプの使用の必要性を軽減するものではない。
先に述べたように、新しいプロトコルの基層としての HTTP を使う主要な理由の一つとして、既存の HTTP クライアント, サーバ, プロクシ等のコードを再利用できるという事がある。 しかし、HTTP はそのような層状化をするために設計されてはいない。 既存の HTTP クライアントやコードは、それらに結び付けられた "http" という前提をもっているであろう。 例えば、層上のプロトコル名やそのバージョン番号とは対照的に、クライアントライブラリやプロクシは "http:" URL を期待し、またクライアントやサーバはリクエストやレスポンス中で "HTTP/1.1" を送る (またそれを期待している) であろう。
既存のクライアントライブラリは新しい URL タイプを理解できないだろう。既存のクライアントライブラリを新しい HTTP 層上のアプリケーションクライアントとして作動させるために、アプリケーションはその URL を "httpに等価な" 形式に変換する必要があるだろう。 例えば、サービス "xyz" がport ### を使用して HTTP 上に層をなす場合に、HTTP クライアントを呼び出す時、xyz クライアントはそのライブラリを呼び出すためにその URL を"xyz://host/something" 形式から "http://host:###/something" へと変換する必要があるだろう。 これは HTTP クライアントライブラリを呼び出す時にのみなされるべきである - そのような URL はプロトコルの他の部分では使用されるべきではないし、ユーザに見せるべきでもない。
クライアントが直接オリジンサーバにリクエストを送っている時は通常 URL先頭部("http:") は送られない事に注意せよ。 そのためクライアントライブラリを呼び出す時に xyz: URL を http: URL に変換しても実際には http:URL が外に向けて送られるべきではない。 しかし同じクライアントがプロクシサーバへリクエストを送っている時は、クライアントは通常それらのリクエスト中の全体の URL (http: 先頭部を含む) を送るであろう。そのリクエストがオリジンサーバへと送られる場合は、そのプロクシは http: 先頭部を取り除くだろう。
既存の HTTP クライアントライブラリやサーバはリクエストやレスポンスを"HTTP/1.1" (あるいは異なるバージョン) として転送するだろう。 そのようなライブラリやサーバの新しいプロトコルへの再利用を容易にするために、そのようなプロトコルはそれ故自身のプロトコル名やバージョン番号よりも"HTTP/1.1" を転送し、また受け入れる必要があるだろう。 HTTP 上に層をなすプロトコルの設計者はプロトコル変換時に "HTTP/1.1" を受け入れるかどうかを明示的に選択すべきである。
あるアプリケーションのためには、特定の HTTP の機能、例えばプロクシによってレスポンスのキャッシュを無効にするようなものの使用を要求したりまた制限したりする必要があるかもしれない。 それ故に HTTP 上に層をなすそれぞれのプロトコルは HTTP が使用されるであろう特定の方法、特に、クライアントやサーバがどのように HTTP プロクシと相互動作すべきかを詳説しなければならない。
HTTP の三桁のステータスコードは、従来の HTTP アプリケーション (例えば、ドキュメントの回収や、フォームに基づいた問い合わせ) を備えた使用のために設計されており、それとは異なるアプリケーションにおいて遭遇したエラーの詳細を通信するのには恐らく適していない。 HTTP ステータスコードと、アプリケーションによって必要とされるコードの間に近い一致があるように思われる時でさえ、他のプロトコルの再使用で得た経験は、使用法における微妙な変化がありそうだという事を示している。 しかも、これはオリジナルのプロトコル (この場合は HTTP) と任意の層上のアプリケーションの両方の相互運用を下げる事になるであろう。
それ故に HTTP ステータスコードは層上のアプリケーションの微妙なエラーを示すために使われるべきではない。 リクエストメッセージボディの内容に起因するエラーを示すためには、せいぜい "一般的な" HTTP コード 200 (完全なる成功) と 500 (完全なる失敗) を使うべきである。 特定の環境下においては、 エラーの性質についての付加的詳細レスポンスメッセージボディ中に含む事ができる。200 や 500 以外のステータスコードは、そのエラーがHTTP サーバやその中継物によって発見された時にのみ使用すべきである。
層上のアプリケーションは新しい HTTP ステータスコードを定義すべきではない。 使用できるステータスコードのセットは少なく、異なる層上のアプリケーション間でのコード割り当てで矛盾がおこるかもしれないし、またそれらが主流である HTTP の将来のバージョンやその拡張によって必要とされるかもしれないからである。
層上のアプリケーションが HTTP における成功あるいは失敗についての同じ概念を共有しない場合、HTTP のエラーコードの使用には問題がある。 クライアントがオリジンサーバに直接接続せず、一つ以上の HTTP キャッシュやプロクシを経由するような場合に、問題は生じる。 (HTTP が中継物を経て通信するという能力がしばしば HTTP を再使用する主要な動機であるので、そのような中継物の存在中で作動するアプリケーションの能力は非常に重要であると考えられる。) そのようなキャッシュやプロクシは HTTP のエラーコードを解釈し、それらのコードに基づいた追加的な処置を講じてもよい。 例えば、オリジンサーバ (や他の適切な条件の下) から 200 エラーコードを受信した場合、プロクシはそのレスポンスをキャッシュして、同様のリクエストへのレスポンスとしてそれを再発行する事ができる。 あるいは、プロクシは"有用な" エラーメッセージを付加するために 500 エラーコードを返すリクエストの結果を修正する事ができる。他のレスポンスコードでは他の振る舞いをするであろう。
それ故に次のような指針が与えられる:
この文書のほとんどはセキュリティについてである。 section 2.3 では HTTPのセキュリティは特定のアプリケーションについて必要なものを満たしているかどうかを、section 2.4 では新しい HTTP ベースのプロトコルとファイアウォールの間の相互動作を、section 3 ではファイアウォールから妨げられないようにするために別のポートの使用する事について、section 4 ではセキュリティレベルを特定するための URL 接頭辞の "s" 先頭部の不適切性について、それぞれ議論するものである。
Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450 EMail: moore@cs.utk.edu
Copyright © The Internet Society (2002). All Rights Reserved.
この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。
上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。
この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。
RFC Editer 機構の資金は、現在インターネット学会から提供されている。