| 見出し |
概要 |
| 1 導入 |
|
| 1.1 目的 |
ハイパーテキスト転送プロトコル (HTTP) は、分散・共同体ハイパーメディア情報システムのアプリケーションレベルプロトコルである。 |
| 1.2 必要条件 |
この文書中における "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" という各キーワードは、RFC 2119 [34] にて記述されるように解釈される。 |
| 1.3 専門用語 |
この仕様書では、HTTP 通信に参加する人間、あるいは物を参照するための専門用語をいくつか使用する。 |
| 1.4 全体の動作 |
HTTP プロトコルはリクエスト／レスポンスプロトコルである。 |
| 2 表記の慣習と一般文法 |
|
| 2.1 拡張 BNF |
この文書において詳述されるメカニズムのすべては、単調 Backus-Naur Form(BNF) と、RFC 822 [9] で使用されているものに似た拡張 BNF との両方で記述されている。 |
| 2.2 基本ルール |
以下のルールは、基本的な構造概念を記述するためにこの仕様書全体に渡って使用される。 |
| 3 プロトコルパラメータ |
|
| 3.1 HTTP のバージョン |
HTTP では、プロトコルのバージョンを示すために "<メジャーバージョン>.<マイナーバージョン>" と番号づける。 |
| 3.2 Uniform Resource Identifiers |
URI とは、既に多くの名前で、例えば WWW address, Universal DocumentIdentifier, Universal Resource Identifier [3], そして、最終的にUniversal Resource Locator (URL) [4] と Name (URN) [20] という名で知られている。 |
| 3.2.1 一般構文 |
HTTP における URI は、絶対形式か、それが使われている状況に依存する、ある既知の基底 URI [11] からの相対形式で表される。 |
| 3.2.2 http URL |
"http" スキームは HTTP プロトコル経由でネットワークリソースの位置を指すために使われる。 |
| 3.2.3 URI の比較 |
二つの URI が一致しているかどうかを決めるために比較する時、クライアントは URI 全体で大文字・小文字を区別したオクテット同士の比較をす *べきである* が、以下は例外とする。 |
| 3.3 日付/時刻フォーマット |
|
| 3.3.1 完全な日付 |
HTTP アプリケーションは、歴史的に日付／時刻スタンプの表現のために三つの異なるフォーマットが許されている。 |
| 3.3.2 秒差 |
ある HTTP ヘッダフィールドでは、メッセージが受信されてからの時間を、10 進数で表される整数の秒数値で、表す事ができる。 |
| 3.4 文字セット |
HTTP では、"文字セット" という用語を MIME で表現される場合と同じ定義で使用する。 |
| 3.4.1 Charset の誤り |
いくつかの HTTP/1.0 ソフトウェアは、"受領者が推測すべき"という意図で、文字セットの無い Content-Type ヘッダを不正確に解釈している。 |
| 3.5 内容コーディング |
内容コーディング値は、エンティティに適用されている、もしくは適用できるエンコーディング変換を示す。 |
| 3.6 転送コーディング |
転送コーディング値は、ネットワークを通して "安全な転送" を保証するために、エンティティボディに適用されている、する事のできる、する必要のあるエンコーディング変換を示すために使われる。 |
| 3.6.1 チャンク形式転送エンコーディング |
チャンク形式エンコーディングは、それぞれが自身のサイズ指標を持つ、一連のチャンクと、エンティティヘッダフィールドを含む *オプショナルな*trailer を付加して転送するためにメッセージのボディを書き換える。 |
| 3.7 メディアタイプ |
HTTP は、Content-Type (section 14.17) と Accept (section 14.1) ヘッダフィールドにおいて、開放・拡張データタイプの決定やタイプネゴシエーションを供給するために Internet Media Type [17] を使用する。 |
| 3.7.1 公式化とテキストデフォルト |
インターネットメディアタイプは、公式の形式で登録される。 |
| 3.7.2 マルチパートタイプ |
MIME は、一つのメッセージボディの中に複数のエンティティをカプセル化する "multipart" タイプをいくつか供給する。 |
| 3.8 製品トークン |
製品トークンは、ソフトウェアの名前とバージョンによってその製品である事を識別するアプリケーションと通信する事ができるようにするために使われる。 |
| 3.9 品質値 |
HTTP 内容ネゴシエーション (section 12) は、さまざまなネゴシエート可能なパラメータの相対な重要性 ("ウェイト") を示すために短い "浮動小数点"数を使う。 |
| 3.10 言語タグ |
言語タグは、他の人間との情報のコミュニケーションのため、人間によって話され、書かれ、あるいは別の方法で伝えられる自然言語を識別する。 |
| 3.11 エンティティタグ |
エンティティタグは、同一の要求リソースからの二つ以上のエンティティを比較するために使用される。 |
| 3.12 レンジ単位 |
HTTP/1.1 では、クライアントはレスポンス内に含まれるレスポンスエンティティの (範囲の) 一部だけを要求できる。 |
| 4 HTTP メッセージ |
|
| 4.1 メッセージタイプ |
HTTPメッセージは、クライアントからサーバへのリクエストと、サーバからクライアントへのレスポンスから成る。 |
| 4.2 メッセージヘッダ |
一般ヘッダ (section 4.5)、リクエストヘッダ (section 5.3)、レスポンスヘッダ (section 6.2)、エンティティヘッダ (section 7.1) 各フィールドを含む HTTP ヘッダフィールドは、RFC 822 [9] の Section 3.1 で与えられているものと同じである共通のフォーマットに従う。 |
| 4.3 メッセージボディ |
HTTPメッセージにメッセージボディがあったとしたら、それはリクエストやレスポンスに関連するエンティティボディを運ぶために使われる。 |
| 4.4 メッセージの長さ |
メッセージの転送長さ{transfer-length} は、それがメッセージの中に現れた時、つまりある転送コーディングが適用された後のメッセージボディの長さである。 |
| 4.5 一般ヘッダフィールド |
リクエストとレスポンスの両メッセージで、一般的な適用性を持つが、転送されたエンティティには適用されないヘッダがいくつかある。 |
| 5 リクエスト |
クライアントからサーバへのリクエストメッセージには、リソースに適用されるメソッド、リソースの識別子、使用するプロトコルのバージョンが最初の行に含まれる。 |
| 5.1 リクエストライン |
リクエストラインは、メソッドトークンに始まり、 Request-URI とプロトコルバージョンが後に続き、CRLF で終了する。 |
| 5.1.1 メソッド |
メソッドトークンは、 Request-URI により識別されるリソースに働きかけるためのメソッドを示す。 |
| 5.1.2 Request-URI |
Request-URI は、Uniform Resource Identifier (section 3.2) であり、リクエストを適用するリソースを識別する。 |
| 5.2 リクエストによって識別されるリソース |
インターネットリクエストにより識別された正確なリソースは、Request-URIと Host ヘッダフィールドの両方で調べる事で決定される。 |
| 5.3 リクエストヘッダフィールド |
リクエストヘッダフィールドを用いて、クライアントはサーバにリクエストやクライアント自身に関する追加的な情報を渡す事ができる。 |
| 6 レスポンス |
リクエストメッセージを受信・解釈した後、サーバは HTTP レスポンスメッセージを返す。 |
| 6.1 ステータスライン |
レスポンスメッセージの最初の行は、プロトコルのバージョン、ステータスコード番号、それに関連したテキストフレーズからなるステータスラインで、それぞれの要素は、SP によって分けられる。 |
| 6.1.1 ステータスコードと説明句 |
ステータスコード要素とは、リクエストを理解し満足するための試行についての三桁の数字による結果コードである。 |
| 6.2 レスポンスヘッダフィールド |
レスポンスヘッダフィールドを用いて、サーバはステータスラインに置けないレスポンスに関する追加的な情報を渡す事ができる。 |
| 7 エンティティ |
リクエストやレスポンスでのメッセージは、リクエストメソッドやレスポンスステータスコードによって規制されていなければ、エンティティを転送する事が *できる*。 |
| 7.1 エンティティヘッダフィールド |
エンティティヘッダフィールドは、エンティティボディや、もしボディが無ければリクエストによって識別されたリソースについての外部情報を定義する。 |
| 7.2 エンティティボディ |
もし、HTTP リクエストやレスポンスと共にエンティティボディが送られてきたら、それはエンティティヘッダフィールドによって定義されるフォーマットをもってエンコーディングされている。 |
| 7.2.1 タイプ |
エンティティボディがメッセージに含まれる時、このボディのデータタイプは Content-Type と Content-Encoding 各ヘッダフィールドによって決定される。 |
| 7.2.2 エンティティ長 |
メッセージのエンティティボディ長は、あらゆる転送エンコーディングが適用される前のメッセージボディの長さである。 |
| 8 接続 |
|
| 8.1 持続的接続 |
|
| 8.1.1 目的 |
持続的接続が無い時代には、別々の URL からリソースを取得するために、それぞれで TCP 接続を確立していたため、サーバのロードを増加させ、インターネットの混雑を引き起こす原因になっていた。 |
| 8.1.2 全体の動作 |
HTTP/1.1 と HTTP のそれ以前のバージョンとの重要な違いは、すべてのHTTP 接続において持続的な接続がデフォルトの動作であるかどうかという事である。 |
| 8.1.2.1 ネゴシエーション |
HTTP/1.1 サーバは、HTTP/1.1 クライアントがリクエスト中に "close" という connection-token を含んでいる Connection ヘッダを送られなければ、持続的接続を維持するつもりである事を想定しても *よい*。 |
| 8.1.2.2 パイプライン化 |
持続的接続をサポートするクライアントは、そのリクエストを "パイプライン" する事が *できる* (例えば、複数のレスポンスを待つ事無く、複数のリクエストを送る)。 |
| 8.1.3 プロクシサーバ |
プロクシが section 14.10 で指定されるように Connection ヘッダの機能を正確に実装する事は特に重要である。 |
| 8.1.4 現実的な考察 |
多くのサーバは、もはや接続を維持しないとするタイムアウト値を持っているであろう。 |
| 8.2 メッセージ転送の必要条件 |
|
| 8.2.1 持続的接続とフローコントロール |
HTTP/1.1 サーバは、一時的な過負荷を解消するためには、持続的接続を維持し、TCP フローコントロールメカニズムを使う *べきであり*、クライアントが再試行するであろうという期待を持って接続を終了させるよりもよい。 |
| 8.2.2 エラーステータスメッセージのための接続のモニタリング |
メッセージボディを送る HTTP/1.1 (あるいはそれ以降) のクライアントは、リクエストを送っている間、エラーステータスのためにネットワークの接続をモニタリングす *べきである*。 |
| 8.2.3 100 (Continue) ステータスの使用 |
100 (Continue) ステータス (section 10.1.1 参照) は、オリジンサーバがクライアントがリクエストボディを送る前に (リクエストヘッダに基づいた)リクエストを受け入れようとする場合に、リクエストボディを伴ったリクエストメッセージを送る事をクライアントに決めさせるという目的を持つ。 |
| 8.2.4 サーバが早まって接続を閉じた場合のクライアントの振る舞い |
もし、HTTP/1.1 クライアントがリクエストボディを持つが、"100-continue"という expectation を持つ Expect リクエストヘッダフィールドを含んでいないリクエストメッセージを送り、しかもクライアントは HTTP/1.1 オリジンサーバには直接接続はしておらず、そこでクライアントがサーバからのどんなステータスをも受け取る前に接続の切断を知った場合は、クライアントはリクエストを再試行す *べきである*。 |
| 9 メソッド定義 |
HTTP/1.1 のための一般的なメソッドのセットは以下に定義される。 |
| 9.1 安全なメソッドと等冪{idempotent} なメソッド |
|
| 9.1.1 安全なメソッド |
実装者は、インターネット上における相互動作においてはソフトウェアがユーザを表しているという事を認識すべきであり、ユーザがそれら自身や他のものに対して予測しない意図を持つようなあらゆる動作に気がつく事ができるように注意すべきである。 |
| 9.1.2 等冪{idempotent} なメソッド |
メソッドは、(エラーや期限切れ発行とは別に) 同一のリクエストの N > 0の副作用が単一のリクエストにおけるものと同じであるような際には"等冪{idempotence}" の性質を持つ事もできる。 |
| 9.2 OPTIONS |
OPTIONS メソッドは、Request-URI によって識別されるリクエスト／レスポンス連鎖上で利用可能な通信オプションについての情報のためのリクエストを表す。 |
| 9.3 GET |
GET メソッドは、Request-URI で識別される (エンティティ形式の) 情報ならなんでも回収する事を意味する。 |
| 9.4 HEAD |
HEAD メソッドは、サーバがレスポンスにおいてメッセージボディを返し *てはならない* 事を除けば GET と同一である。 |
| 9.5 POST |
POST メソッドは、サーバがリクエストライン内の Request-URI により識別されるリソースへの新しい従属{subordinate} として、リクエストに同封されるエンティティを受け入れる事を要求するために使用される。 |
| 9.6 PUT |
PUT メソッドは、同封されたエンティティを供給される Request-URI の元に保存するように要求する。 |
| 9.7 DELETE |
DELETE メソッドは、オリジンサーバが Request-URI により識別されるリソースを削除する事を要求する。 |
| 9.8 TRACE |
TRACE メソッドは、リクエストメッセージのアプリケーション層のループバックを遠隔的に発動するために使用される。 |
| 9.9 CONNECT |
この仕様書では、(例えば SSLトンネリング [44] 等の) トンネルとなるように動的に切り換える事ができるプロクシが使用する時のために CONNECT というメソッド名を予約する。 |
| 10 ステータスコード定義 |
各々のステータスコードについて、レスポンス時に後に従える事のできるメソッドと必要とされるすべての外部情報の記述と共に、以下に記述する。 |
| 10.1 Informational 1xx |
このステータスコードのクラスは一時的なレスポンスを示し、ステータスラインとオプション的なヘッダからのみなり、空行で終了する。 |
| 10.1.1 100 Continue |
クライアントは、そのリクエストを続ける *べきである*。 |
| 10.1.2 101 Switching Protocols |
サーバは理解し、Upgrade メッセージヘッダフィールド (section 14.42) を使って、この接続で使用されているアプリケーションプロトコルを変更する事でクライアントのリクエストに従おうとしている。 |
| 10.2 Successful 2xx |
このステータスコードのクラスは、クライアントのリクエストがうまく受信され、理解され、そして受け入れられた事を示す。 |
| 10.2.1 200 OK |
リクエストは成功した。 |
| 10.2.2 201 Created |
リクエストは果たされ、結果として新しいリソースが作成された。 |
| 10.2.3 202 Accepted |
リクエストは処理のために受け入れられたが、処理は完了されていない。 |
| 10.2.4 203 Non-Authoritative Information |
エンティティヘッダにおいて返された外部情報は、オリジンサーバから利用できるような決定的なセットではなく、ローカルもしくはサードパーティコピーから集められたものである。 |
| 10.2.5 204 No Content |
サーバはリクエストを受け入れたが、エンティティボディを送り返す必要は無く、更新された外部情報を返す事を望むだろう。 |
| 10.2.6 205 Reset Content |
サーバはリクエストを受け入れたので、ユーザエージェントは送信されたリクエストをもたらした現在の画面をリセットす *べきである*。 |
| 10.2.7 206 Partial Content |
サーバはリソースに対する部分的 GET リクエストを受け入れた。 |
| 10.3 Redirection 3xx |
このステータスコードのクラスは、リクエストを果たすためにはユーザエージェントによって更なる動作が行われる必要がある事を示す。 |
| 10.3.1 300 Multiple Choices |
リクエストされたリソースは、表現セットの一つに対応し、各々が特有の場所にあり、エージェント駆動型ネゴシエーション情報 (section 12) が、ユーザ (あるいはユーザエージェント) が望む表現を選択でき、その位置にリクエストをリダイレクトできるように供給されている。 |
| 10.3.2 301 Moved Permanently |
リクエストされたリソースは新しい恒久的な URI に割り当てられたので、以降そのリソースへの参照は返された URI の一つを使用す *べきである*。 |
| 10.3.3 302 Found |
リクエストされたリソースは、一時的に別の URI に属している。 |
| 10.3.4 303 See Other |
リクエストに対するレスポンスは別の URI の元から発見でき、このリソースを GET メソッドを使用して回収す *べきである*。 |
| 10.3.5 304 Not Modified |
クライアントが条件付き GET リクエストを実行し、アクセスは許可されたがその文書は更新されていなかった場合、サーバはこのステータスコードもって応答す *べきである*。 |
| 10.3.6 305 Use Proxy |
リクエストされたリソースは Location フィールドによって与えられるプロクシを通してアクセスされ *なければならない*。 |
| 10.3.7 306 (Unused) |
306 ステータスコードは前のバージョンの仕様書では使われていたが、もはや使われておらず、将来のために予約されている。 |
| 10.3.8 307 Temporary Redirect |
リクエストされたリソースは、一時的に別の URI に属している。 |
| 10.4 Client Error 4xx |
ステータスコードの 4xx クラスは、クライアントが間違えているような場合を示す。 |
| 10.4.1 400 Bad Request |
リクエストは、不正なシンタックスのためサーバに理解されなかった。 |
| 10.4.2 401 Unauthorized |
リクエストはユーザ認証を必要とする。 |
| 10.4.3 402 Payment Required |
このコードは、将来の使用のため予約されている。 |
| 10.4.4 403 Forbidden |
サーバはリクエストを理解したが、それを実行する事を拒否した。 |
| 10.4.5 404 Not Found |
サーバが、Request-URI に一致するものを見つけられなかった。 |
| 10.4.6 405 Method Not Allowed |
リクエストラインに記述されたメソッドは、Request-URI によって識別されるリソースに許可されていない。 |
| 10.4.7 406 Not Acceptable |
リクエストによって識別されるリソースは、リクエスト中に送られた Acceptヘッダによれば、受け入れられない内容特性を持つレスポンスエンティティを生成する事ができるのみである。 |
| 10.4.8 407 Proxy Authentication Required |
このコードは、401 (Unauthorized) と似ているが、クライアントが最初にプロクシに認証されなければならない事を示す。 |
| 10.4.9 408 Request Timeout |
クライアントは、サーバの待ち時間内にリクエストを発行しなかった。 |
| 10.4.10 409 Conflict |
リクエストは、リソースの現在の状態との矛盾のため完了できなかった。 |
| 10.4.11 410 Gone |
リクエストされたリソースは、もはやそのサーバでは利用できないし、転送先のアドレスも分からない。 |
| 10.4.12 411 Length Required |
サーバは、定義された Content-Length の無いリクエストを受け入れる事を拒否した。 |
| 10.4.13 412 Precondition Failed |
一つ以上のリクエストヘッダフィールドで与えられた前提条件は、それがサーバでテストされたときに偽であると評価された。 |
| 10.4.14 413 Request Entity Too Large |
リクエストエンティティがサーバが想定、あるいは処理可能なものより大きいため、サーバはリクエストの処理を拒否している。 |
| 10.4.15 414 Request-URI Too Long |
サーバが中間処理をするために想定している Request-URI より長いため、サーバはリクエストのサービスを拒否している。 |
| 10.4.16 415 Unsupported Media Type |
リクエストのエンティティは、リクエストされたメソッドに対してリクエストされたリソースがサポートしていないフォーマットであるため、サーバはリクエストのサービスを拒否している。 |
| 10.4.17 416 Requested Range Not Satisfiable |
リクエストが Range ヘッダフィールド (section 14.35) を含み、このフィールドの範囲指定値が選ばれたリソースの現在の範囲に重なっていなくて、リクエストに If-Range リクエストヘッダフィールドを含んでいなかったら、サーバはこのステータスコードを含むレスポンスを返す *べきである*。 |
| 10.4.18 417 Expectation Failed |
Expect リクエストヘッダフィールド (section 14.20 参照) によって与えられるこの拡張は、このサーバでは受け入れる事はできないし、あるいはサーバがプロクシであったなら、次に到達するサーバがそのリクエストを受け入れる事ができないという明白な証拠を持っている。 |
| 10.5 Server Error 5xx |
数字 "5" で始まるレスポンスステータスコードは、サーバがエラー状態にあるか、リクエストを実行する能力が無いと気づいた場合を表す。 |
| 10.5.1 500 Internal Server Error |
サーバは、リクエストの実行を妨げる予測しない状態に遭遇した。 |
| 10.5.2 501 Not Implemented |
サーバは、リクエストを実行するのに必要な機能をサポートしていない。 |
| 10.5.3 502 Bad Gateway |
ゲートウェイやプロクシとして動作しているようなサーバが、リクエストを実行しようと呼び出しているアップストリームサーバから不正なレスポンスを受け取った。 |
| 10.5.4 503 Service Unavailable |
サーバは、一時的な過負荷かあるいはサーバのメンテナンスのため、現在リクエストを扱う事ができない。 |
| 10.5.5 504 Gateway Timeout |
ゲートウェイやプロクシとして動作するサーバは、URI によって特定されるアップストリームサーバ (例えば HTTP, FTP, LDAP) や、リクエストを完了させようとするためにアクセスに必要な他の補助のサーバ (例えば DNS) から適時のレスポンスを受信しなかった。 |
| 10.5.6 505 HTTP Version Not Supported |
サーバは、リクエストメッセージで使用された HTTP プロトコルバージョンをサポートしていない、あるいはサポートを拒否している。 |
| 11 アクセス認証 |
HTTP は、サーバがクライアントにリクエストを誰何{challenge} するため、あるいはクライアントが認証情報を提供するために使用する事ができる、いくつかの *オプショナル* な誰何-応答{challenge-response} 認証メカニズムを提供する。 |
| 12 コンテントネゴシエーション |
多くの HTTP レスポンスは、人間ユーザによって解釈される情報から成るエンティティを含む。 |
| 12.1 サーバ駆動型ネゴシエーション |
レスポンスとしての最適な表現の選択がサーバに設けられたアルゴリズムによって行われた場合、これはサーバ駆動型ネゴシエーションと呼ばれる。 |
| 12.2 エージェント駆動型ネゴシエーション |
エージェント駆動型ネゴシエーションの場合、レスポンスとしての最適な表現の選択は、オリジンサーバからの最初のレスポンスを受けとった後にユーザエージェントによって実行される。 |
| 12.3 透過的ネゴシエーション |
透過的ネゴシエーションは、サーバ駆動型ネゴシエーションとエージェント駆動型ネゴシエーションの両方の組み合わせである。 |
| 13 HTTP におけるキャッシング |
HTTP は基本的に情報配布システムとして使われるが、そのパフォーマンスはレスポンスキャッシュの使用によって改善する事ができる。 |
| 13.1.1 キャッシュの正当性 |
正当なキャッシュは、以下の状況の一つに合うリクエスト (section 13.2.5,13.2.6, 13.12 参照) に適した、キャッシュが持っている最新のレスポンスをもってリクエストに答え *なければならない*。 |
| 13.1.2 Warnings |
キャッシュがファーストハンドでも無く、 (section 13.1.1 での二つの状態の意味において) "十分に新鮮" でも無いレスポンスを返す時は、常にWarning 一般レスポンスヘッダを使って、その結果に警告を付加し *なければならない*。 |
| 13.1.3 キャッシュコントロールメカニズム |
HTTP/1.1 における基本的なキャッシュメカニズム (サーバに指定された期限時刻とバリディタ) はキャッシュにとっての暗黙的命令である。 |
| 13.1.4 明示的なユーザエージェントの警告 |
多くのユーザエージェントでは、ユーザが基本的なキャッシングメカニズムとは別の物を使えるようにさせている。 |
| 13.1.5 規則と警告の例外 |
いくつかの場合、キャッシュのオペレータはクライアントによって要求されない時に古くなったレスポンスを返すような設定を選ぶ事が *できる*。 |
| 13.1.6 クライアントにコントロールされた振る舞い |
オリジンサーバ (とレスポンスの経過時間へ寄与するより小さな範囲の中間キャッシュ) が期限切れについての情報のプライマリリソースである間、いくつかの場合クライアントはキャッシュされたレスポンスを再検証する事無く返すかどうかについてのキャッシュの決定を制御する必要があるかもしれない。 |
| 13.2 期限{Expiration} モデル |
|
| 13.2.1 サーバが指定した期限 |
HTTP キャッシングは、キャッシュがオリジンサーバにリクエストを送るという事を完全に避ける事ができる時に最善に動作する。 |
| 13.2.2 帰納的有効期限 |
オリジンサーバは明示的有効期限を常に提供するわけではないので、HTTP キャッシュは典型的に、本当の有効期限を見積もるために (Last-Modified の時間のような) 別のヘッダ値を使うようなアルゴリズムを使って、帰納的有効期限を割り当てる。 |
| 13.2.3 経過時間の計算 |
キャッシュエントリが新鮮かどうかを知るために、キャッシュは経過時間がその有効期間を超えているかどうかを知る必要がある。 |
| 13.2.4 期限の計算 |
レスポンスが新鮮かどうかを決定するために、その有効期間と経過時間とを比較する必要がある。 |
| 13.2.5 期限値を曖昧にしない事 |
期限値が楽天的に割り当てられるために、二つのキャッシュが同じリソースに対して異なる新鮮度値を含む事が可能である。 |
| 13.2.6 複数のレスポンスを曖昧にしない事 |
クライアントは複数の経路からレスポンスを受け取る事ができるので、あるレスポンスがあるキャッシュのセットを通って流れ、別のレスポンスが別のキャッシュのセットを通って流れる場合、クライアントはオリジンサーバがレスポンスを送った時とは違う順番でレスポンスを受け取るかもしれない。 |
| 13.3 検証{Validation} モデル |
キャッシュがクライアントのリクエストへのレスポンスとして使いたいような新鮮で無いエントリを持っている時、そのキャッシュされたエントリがまだ使用可能かどうかを確かめるために最初にオリジンサーバ (かあるいは新鮮なレスポンスを持っている中間キャッシュ) へチェックしなければならない。 |
| 13.3.1 Last-modified の日付 |
Last-Modified エンティティヘッダフィールド値はしばしばキャッシュバリディタとして使われる。 |
| 13.3.2 エンティティタグのキャッシュバリディタ |
ETag レスポンスヘッダフィールド値、すなわちエンティティタグは、"曖昧なわかりにくい{opaque}" キャッシュバリディタを提供する。 |
| 13.3.3 弱いバリディタと強いバリディタ |
オリジンサーバやキャッシュの両方でそれが同じエンティティを表すかどうかを決定するために二つのバリディタを比較するため、通常はエンティティ(エンティティボディかエンティティヘッダ) が何らかの理由で変わっていたら、それに関するバリディタも同様に変更しているだろうという事を期待できる。 |
| 13.3.4 エンティティタグや Last-Modified の日付を使う場合のルール |
我々は様々なバリディタタイプがいつ、何の目的で使用されるべきかに関するオリジンサーバ、クライアント、キャッシュのためのルールと推薦のセットを採用する。 |
| 13.3.5 非検証条件 |
エンティティタグの背景にある原理は、サービスの著者のみが適切なキャッシュバリディタメカニズムを選択するのに十分なリソースのセマンティクスを知る事で、バイト等価性よりも複雑なあらゆるバリディタ比較機能についての仕様書は虫の缶{can of worms} を開ける事になるだろう。 |
| 13.4 レスポンスのキャッシュ可能性 |
Cache-Control (section 14.9) 指示子によって特に強制されていなければ、キャッシングシステムはキャッシュエントリとして成功したレスポンス(section 13.8 参照) を常に保存 *でき*、それが新鮮であれば検証無しにそれを返す事が *でき*、検証の後にそれを返す事も *できる*。 |
| 13.5 キャッシュからの構築したレスポンス |
HTTP キャッシュの目的は、将来のリクエストへの応答での使用するためにリクエストへのレスポンスで受信した情報を保存する事である。 |
| 13.5.1 エンドトゥエンドヘッダとホップバイホップヘッダ |
キャッシュや非キャッシュプロクシの振る舞いを定義する目的のために、我々は HTTP ヘッダを二つのカテゴリに分ける。 |
| 13.5.2 修正できないヘッダ |
ダイジェスト認証のような、HTTP/1.1 プロトコルのいくつかの機能では、特定のエンドトゥエンドヘッダの値に依存する。 |
| 13.5.3 ヘッダの連結 |
キャッシュがサーバに検証リクエストを送り、サーバが 304 (Not Modified)か 206 (Partial Content) レスポンスを返した場合、キャッシュはリクエストしたクライアントに返すレスポンスを構築する。 |
| 13.5.4 バイトレンジの連結 |
リクエストが一つ以上の Range 詳述を含んでいたり、接続が早まって切断されたりするので、レスポンスはエンティティボディのバイトのサブレンジのみを転送できる。 |
| 13.6 ネゴシエートされたレスポンスのキャッシング |
レスポンス中の Vary ヘッダフィールドの存在によって示されるような、サーバ駆動型コンテントネゴシエーション (section 12.1) を使う事は、キャッシュが以降のリクエストのためにそのレスポンスを使う事ができる事によってその条件と手続きを変更する。 |
| 13.7 共有キャッシュと非共有キャッシュ |
セキュリティやプライバシー上の理由により、"共有{shared}" キャッシュと"非共有{non-shared}" キャッシュとの間に区別を付ける必要がある。 |
| 13.8 エラーや不完全なレスポンスのキャッシュの振る舞い |
不完全なレスポンス (例えば、Content-Length ヘッダで記述されたものより少ないデータのバイトを伴うもの) を受信するキャッシュはレスポンスを保存する事が *できる*。 |
| 13.9 GET や HEAD の副作用 |
オリジンサーバがそれらのレスポンスのキャッシングを明示的に禁止していない場合に、あらゆるリソースへ GET や HEAD メソッドを適用する事によってそれらのレスポンスがキャッシュから取り出されたならば、誤った動作を導くような副作用を抱える *べきではない*。 |
| 13.10 更新や削除後の無効化 |
オリジンサーバ上のリソースに行われるあるメソッドの影響によって一つ以上の既存のキャッシュエントリが非透過で無効なものになってしまうかもしれない。 |
| 13.11 Write-Through の強制 |
オリジンサーバのリソースに修正をさせる事が期待されるすべてのメソッドは、オリジンサーバへと通されて書かれる{write through} もので *なければならない*。 |
| 13.12 キャッシュの代替 |
もしあるリソースについてのレスポンスが既にキャッシュされている時に、同じリソースから新しくキャッシュ可能な (section 14.9.2, 13.2.5,13.2.6, 13.8 参照) レスポンスが受信された場合、キャッシュは現在のリクエストへの応答には新しいレスポンスを使用す *べきである*。 |
| 13.13 履歴表 |
ユーザエージェントはしばしば、"戻る" ボタンと履歴リストのような履歴メカニズムを持っていて、セッションにおいて以前に回収したエンティティを再表示するために使う事ができる。 |
| 14 ヘッダフィールド定義 |
この章では、すべての標準 HTTP/1.1 ヘッダフィールドのシンタックスとセマンティクスを定義する。 |
| 14.1 Accept |
Accept リクエストヘッダフィールドは、レスポンスで受け入れ可能なメディアタイプを指定するために使われる。 |
| 14.2 Accept-Charset |
Accept-Charset リクエストヘッダフィールドは、レスポンスで受け入れ可能な文字セットを示すのに使われる。 |
| 14.3 Accept-Encoding |
Accept-Encoding リクエストヘッダフィールドは、Accept ヘッダに似ているが、レスポンスで受け入れ可能な内容コーディング (section 3.5) を制限する。 |
| 14.4 Accept-Language |
Accept-Language リクエストヘッダフィールドは、Accept に似ているが、リクエストへのレスポンスとして望む自然言語のセットを限定する。 |
| 14.5 Accept-Ranges |
Accept-Ranges レスポンスヘッダフィールドは、サーバにリソースへの範囲リクエストの受け入れを示させる。 |
| 14.6 Age |
Age レスポンスヘッダは、オリジンサーバがレスポンスを生成した (あるいは再検証した) 時点からの送信者の推定経過時間を示す。 |
| 14.7 Allow |
Allow エンティティヘッダフィールドは、Request-URI によって識別されるリソースがサポートするメソッドの一覧を示す。 |
| 14.8 Authorization |
サーバに認証を受けようとするユーザエージェントは、必ずというわけではないが、通常は 401 レスポンスの後、リクエストに Authorization リクエストヘッダフィールドを含める。 |
| 14.9 Cache-Control |
Cache-Control 一般ヘッダフィールドは、リクエスト／レスポンス連鎖上のすべてのキャッシングメカニズムが従わ *なければならない* 指示を記述するために使用される。 |
| 14.9.1 キャッシュ可能とは何か |
リクエストメソッド、リクエストヘッダフィールド、レスポンスステータスがキャッシュ可能である事を要求している場合、デフォルトではレスポンスはキャッシュ可能である。 |
| 14.9.2 キャッシュによって保存できるものは何か |
no-storeno-store 指示子の目的は、取り扱いが慎重な (例えばバックアップテープ上の) 情報の不注意な漏洩や保留を防ぐ事である。 |
| 14.9.3 基本的な期限のメカニズムの修正 |
エンティティの有効期限は、Expires ヘッダ (section 14.21 参照) を使ってオリジンサーバにより記述する事が *できる*。 |
| 14.9.4 キャッシュの再検証とリロードコントロール |
時々ユーザエージェントは、キャッシュがオリジンサーバ (オリジンサーバへの経路上の次のキャッシュではなく) にキャッシュエントリの再検証を行う事を要求したり、オリジンサーバからそのキャッシュエントリをリロードする事を望みあるいは必要とするかもしれない。 |
| 14.9.5 no-transform 指示子 |
no-transform中間キャッシュ (プロクシ) の実装者は、あるエンティティボディのメディアタイプを変換する事が有用である事を知っている。 |
| 14.9.6 キャッシュコントロールの拡張 |
Cache-Control ヘッダフィールドは、それぞれにオプション的に割り当てられる値を伴う、一つ以上の cache-extension トークンを使う事によって拡張可能である。 |
| 14.10 Connection |
Connection 一般ヘッダフィールドは、送信者が特定の接続のために望むオプションを指定する事を可能にするが、介在するプロクシとの接続を超えて伝達し *てはならない*。 |
| 14.11 Content-Encoding |
Content-Encoding エンティティヘッダフィールドは、メディアタイプの修飾子として使われる。 |
| 14.12 Content-Language |
Content-Language エンティティヘッダフィールドは、それと共に送られるエンティティの読者の自然言語を表す。 |
| 14.13 Content-Length |
Content-Length エンティティヘッダフィールドは、受信者に送られるエンティティボディのサイズを、HEAD メソッドの場合は GET リクエストがなされた場合に送られるエンティティボディのサイズを、10 進数のオクテットで表す。 |
| 14.14 Content-Location |
Content-Location エンティティヘッダフィールドは、エンティティがリクエストされたリソースの URI とは別の場所から取得可能である時に、そのメッセージに含まれるエンティティに対するリソースの場所を与える時に使う事が *できる*。 |
| 14.15 Content-MD5 |
Content-MD5 エンティティヘッダフィールドは、RFC 1864 [23] にて定義されるように、エンティティボディのメッセージ状態チェック{messageintegrity check} (MIC) をエンティトゥエンドで提供するという目的を持つエンティティボディの MD5 ダイジェストである。 |
| 14.16 Content-Range |
Content-Range エンティティヘッダフィールドは、共に送られるエンティティボディの一部が、エンティティボディ全体のうちどこに当たるものかを示すために送られる。 |
| 14.17 Content-Type |
Content-Type エンティティヘッダフィールドは、受信者に送られるエンティティボディのメディアタイプを示し、HEAD メソッドの場合は、GET リクエストがなされた場合に送られるエンティティボディのメディアタイプを示す。 |
| 14.18 Date |
Date 一般ヘッダフィールドは、メッセージが生成された日付・時刻を表し、RFC 822 の orig-date と同じセマンティクスを持つ。 |
| 14.18.1 時計の無いサーバの動作 |
オリジンサーバインプリメンテーションの中には、利用可能な時計を持っていないものがあるかもしれない。 |
| 14.19 ETag |
ETag レスポンスヘッダフィールドは、リクエストされたバリアントのエンティティタグの現在の値を示す。 |
| 14.20 Expect |
Expect リクエストヘッダフィールドは、特定のサーバの振る舞いがクライアントによって要求されている事を示すために使われる。 |
| 14.21 Expires |
Expires エンティティヘッダフィールドは、レスポンスが新鮮で無くなる{stale} と考えられる時点の日付／時刻を表す。 |
| 14.22 From |
もし From リクエストヘッダフィールドが与えられていれば、そこにはリクエストしているユーザエージェントを操っている人間のインターネットe-mail アドレスが含められている *べきである*。 |
| 14.23 Host |
Host リクエストヘッダフィールドは、リクエストされたリソースのインターネットホストとポート番号を、ユーザや参照されるリソースによって与えられるオリジナル URI (一般には section 3.2.2 にて表されるような HTTPURL) から得るために、指定する。 |
| 14.24 If-Match |
If-Match リクエストヘッダフィールドは、メソッドを条件付きにするために使われる。 |
| 14.25 If-Modified-Since |
If-Modified-Since リクエストヘッダフィールドは、メソッドを条件付きにするために使われる。 |
| 14.26 If-None-Match |
If-None-Match リクエストヘッダフィールドは、メソッドを条件付きにする場合に使われる。 |
| 14.27 If-Range |
もしクライアントがキャッシュとしてあるエンティティのコピーの一部を保持していて、そのエンティティ全体の最新のコピーが欲しい場合、 (If-Unmodified-Since か If-Match、あるいは両方を使った) 条件付き GET として Range リクエストヘッダを使う事ができる。 |
| 14.28 If-Unmodified-Since |
If-Unmodified-Since リクエストヘッダフィールドは、メソッドを条件付きにするために使われる。 |
| 14.29 Last-Modified |
Last-Modified エンティティヘッダフィールドは、オリジンサーバがバリアントが最後に更新されたと考える日付を表す。 |
| 14.30 Location |
Location レスポンスヘッダフィールドは、リクエストを完了するため、あるいは新しいリソースを識別するため、受信者を Request-URI 以外の場所にリダイレクトするのに使われる。 |
| 14.31 Max-Forwards |
Max-Forwards リクエストヘッダフィールドは、TRACE (section 9.8) やOPTIONS (section 9.2) の各メソッドに、次のインバウンドサーバにリクエストを転送できるプロクシやゲートウェイの数を制限するというメカニズムを提供する。 |
| 14.32 Pragma |
Pragma 一般ヘッダフィールドは、リクエスト／レスポンス連鎖中のあらゆる受信者にも適用されるであろうインプリメンテーションの特別な指示を示すために使われる。 |
| 14.33 Proxy-Authenticate |
Proxy-Authenticate レスポンスヘッダフィールドは、407 (ProxyAuthentication Required) レスポンスの一部として含め *なければならない*。 |
| 14.34 Proxy-Authorization |
Proxy-Authorization リクエストヘッダフィールドを使って、クライアントは認証を要求するプロクシに自身 (やそのユーザ) を識別させる。 |
| 14.35 Range |
|
| 14.35.1 バイトレンジ |
HTTP メッセージ中では、すべての HTTP エンティティがバイトシーケンスで表せるので、バイトレンジの概念はあらゆる HTTP エンティティにとって意義のあるものである。 |
| 14.35.2 レンジ更新リクエスト |
条件付き、あるいは条件の付かない GET メソッドを使った HTTP 検索リクエストは Range リクエストヘッダを使って、エンティティ全体の代わりに、エンティティの一つ以上の sub-range を要求 *でき*、リクエストの結果として返されるエンティティに当たる。 |
| 14.36 Referer |
Referer[原文ママ] リクエストヘッダフィールド ("referrer" であるはずなのに綴りは間違っているが) は、サーバの利益のために、Request-URI が得られたリソースのアドレス (URI) をクライアントに示させる。 |
| 14.37 Retry-After |
Retry-After レスポンスヘッダフィールドは、リクエストしているクライアントにそのサービスがどのくらいの時間利用不可能なのかを示すために、503(Service Unavailable) レスポンスと共に使われる。 |
| 14.38 Server |
Server レスポンスヘッダフィールドは、リクエストを処理するオリジンサーバが使っているソフトウェアについての情報を含んでいる。 |
| 14.39 TE |
TE リクエストヘッダフィールドは、レスポンスとしてどんな拡張転送コーディングを受け入れられるか、またチャンク形式転送コーディング内のtrailer フィールドを受け入れられるかどうかを示す。 |
| 14.40 Trailer |
Trailer 一般フィールドの値は、その中で与えられたヘッダフィールドのセットがチャンク形式転送コーディングにてエンコードされたメッセージの後につけられるもの{trailer} の中に含まれている事を表す。 |
| 14.41 Transfer-Encoding |
Tranfer-Encoding 一般ヘッダフィールドは、 (もし変形がなされていれば)送信者と受信者の間でメッセージボディを安全に転送するために、適用されている変形の形を示す。 |
| 14.42 Upgrade |
Upgrade 一般ヘッダは、クライアントが他にどんな通信プロトコルをサポートするかを表し、サーバがプロトコルを切り換えた方がいいと判断した場合に使わせたいものを指定させる。 |
| 14.43 User-Agent |
User-Agent リクエストヘッダフィールドは、リクエストを生成したユーザエージェントについての情報を含む。 |
| 14.44 Vary |
Vary フィールド値は、そのレスポンスが新鮮である{fresh} 間、キャッシュが再検証無しにそれに続くリクエストに対するレスポンスとして使ってよいかどうかを、完全に決定するためのリクエストヘッダフィールドのセットを示す。 |
| 14.45 Via |
Via 一般ヘッダフィールドは、リクエスト時におけるユーザエージェントからサーバ間の、またレスポンス時におけるオリジンサーバからユーザエージェント間の、中間のプロトコルと受信者を示すためにゲートウェイやプロクシによって使われ *なければならない*。 |
| 14.46 Warning |
Warning 一般ヘッダフィールドは、そのメッセージ中には反映されないであろうステータスやメッセージの変化についての付加的情報を伝えるために使われる。 |
| 14.47 WWW-Authenticate |
WWW-Authenticate レスポンスヘッダフィールドは、401 (Unauthorized) レスポンスメッセージ中に含まれてい *なければならない*。 |
| 15 セキュリティについての考察 |
この章はアプリケーション開発者、情報提供者、そしてユーザにこの文書で記述されているような HTTP/1.1 のセキュリティ限界を知らせるという意図を持つ。 |
| 15.1 個人情報 |
HTTP クライアントはしばしば多くの量の個人情報 (例えばユーザの名前、場所、メールアドレス、パスワード、暗号キー、等々) を管理しているので、この情報を HTTP プロトコル経由で他のリソースへと知らないうちに漏洩していないように特に気をつける *べきである*。 |
| 15.1.1 サーバログ情報の乱用 |
サーバは、読み込みの傾向や興味の対象で識別されるであろうユーザのリクエストについての個人情報を保存する立場にある。 |
| 15.1.2 機密性の高い情報の転送 |
一般的なデータ転送プロトコルと同様に、HTTP は転送されるデータの内容を規制する事はできないし、与えられるリクエストの状況の中でその情報の特定の部分の機密性を決定するためのどんな優先的方法もない。 |
| 15.1.3 URI での機密性の高い情報のエンコード |
リンクのソースがプライベートな情報、あるいは他のプライベートな情報のソースを明らかにしてしまうかもしれないので、ユーザが Referer フィールドを送信するかどうかを選択できるようにする事を強く推奨する。 |
| 15.1.4 Accept ヘッダに関連するプライバシーの問題 |
Accept リクエストヘッダは、アクセスされたすべてのサーバにユーザに関する情報を表す事ができる。 |
| 15.2 ファイル名やパス名に基づく攻撃 |
HTTP オリジンサーバの実装は、HTTP リクエストによって返される文書はサーバ管理者によって意図されたものだけに制限するように注意す *べきである*。 |
| 15.3 DNS スプーフィング |
HTTP を使用しているクライアントは Domain Name Service に非常に頼っており、従って一般的に IP アドレスと DNS 名の故意なる間違った組み合わせをベースとしたセキュリティアタックが行われる傾向にある。 |
| 15.4 Location ヘッダとスプーフィング |
もし単一のサーバがお互いを信頼していない複数の組織をサポートするならば、権限を持っていないところでリソースを無効にしないようにと気をつけるため、示された組織の制御の元で生成されたレスポンスの Location ヘッダと Content-Location ヘッダの値をチェックし *なければならない*。 |
| 15.5 Content-Disposition 問題 |
RFC 1806 [35] は、HTTP ではしばしば実装されている Content-Dispositionヘッダについてのものだが、これはいくつかの深刻なセキュリティ上の問題を抱えている。 |
| 15.6 認証用証明書と無配慮なクライアント |
現存の HTTP クライアントやユーザエージェントは、典型的に認証情報を無期限に保持している。 |
| 15.7 プロクシとキャッシング |
その性質から必然的に、HTTP プロクシは人と人の間に入り{men-in-the-middle}、中継人による攻撃{man-in-the-middle attacks} の機会が与えられる。 |
| 15.7.1 プロクシを使ったサービス拒否攻撃 |
この攻撃は存在する。 |
| 16 謝辞 |
この仕様書では、RFC 822 [9] で David H. Crocker によって定義された拡張 BNF と共通概念を多数使用している。 |
| 17 参考文献 |
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC1766, March 1995.[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,D. and B. Alberti, "The Internet Gopher Protocol (a distributeddocument search and retrieval protocol)", RFC 1436, March 1993.[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC1630, June 1994.[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform ResourceLocators (URL)", RFC 1738, December 1994.[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -2.0", RFC 1866, November 1995.[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext TransferProtocol -- HTTP/1.0", RFC 1945, May 1996.[7] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part One: Format of Internet Message Bodies",RFC 2045, November 1996.[8] Braden, R., "Requirements for Internet Hosts -- CommunicationLayers", STD 3, RFC 1123, October 1989.[9] Crocker, D., "Standard for The Format of ARPA Internet TextMessages", STD 11, RFC 822, August 1982.[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,Sui, J., and M. Grinbaum, "WAIS Interface Protocol PrototypeFunctional Specification," (v1.5), Thinking MachinesCorporation, April 1990.[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,June 1995.[12] Horton, M. and R. Adams, "Standard for Interchange of USENETMessages", RFC 1036, December 1987.[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC977, February 1986.[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) PartThree: Message Header Extensions for Non-ASCII Text", RFC 2047,November 1996.[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC1867, November 1995.[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,August 1982.[17] Postel, J., "Media Type Registration Procedure", RFC 1590,November 1996.[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC959, October 1985.[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,October 1994.[20] Sollins, K. and L. Masinter, "Functional Requirements forUniform Resource Names", RFC 1737, December 1994.[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code forInformation Interchange. Standard ANSI X3.4-1986, ANSI, 1986.[22] ISO-8859. International Standard -- Information Processing --8-bit Single-Byte Coded Graphic Character Sets --Part 1: Latin alphabet No. 1, ISO-8859-1:1987.Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC1864, October 1995.[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC1900, February 1996.[25] Deutsch, P., "GZIP file format specification version 4.3", RFC1952, May 1996.[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTPLatency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,Dec. 1995. Slightly revised version of paper in Proc. 2ndInternational WWW Conference '94: Mosaic and the Web, Oct. 1994,which is available athttp://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html.[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTPPerformance", ,ISI Research Report ISI/RR-98-463, (original report dated Aug.1996), USC/Information Sciences Institute, August 1998.[28] Mills, D., "Network Time Protocol (Version 3) Specification,Implementation and Analysis", RFC 1305, March 1992.[29] Deutsch, P., "DEFLATE Compressed Data Format Specificationversion 1.3", RFC 1951, May 1996.[30] S. Spero, "Analysis of HTTP Performance Problems,"http://sunsite.unc.edu/mdma-release/http-prob.html.[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data FormatSpecification version 3.3", RFC 1950, May 1996.[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:Digest Access Authentication", RFC 2069, January 1997.[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2068, January 1997.[34] Bradner, S., "Key words for use in RFCs to Indicate RequirementLevels", BCP 14, RFC 2119, March 1997.[35] Troost, R. and Dorner, S., "Communicating PresentationInformation in Internet Messages: The Content-DispositionHeader", RFC 1806, June 1995.[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use andInterpretation of HTTP Version Numbers", RFC 2145, May 1997.[jg639][37] Palme, J., "Common Internet Message Headers", RFC 2076, February1997. [jg640][38] Yergeau, F., "UTF-8, a transformation format of Unicode andISO-10646", RFC 2279, January 1998. [jg641][39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,Lie, H., and C. Lilley. "Network Performance Effects ofHTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, CannesFrance, September 1997.[jg642][40] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part Two: Media Types", RFC 2046, November1996. [jg643][41] Alvestrand, H., "IETF Policy on Character Sets and Languages",BCP 18, RFC 2277, January 1998. [jg644][42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform ResourceIdentifiers (URI): Generic Syntax and Semantics", RFC 2396,August 1998. [jg645][43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTPAuthentication: Basic and Digest Access Authentication", RFC2617, June 1999. [jg646][44] Luotonen, A., "Tunneling TCP based protocols through Web proxyservers," Work in Progress. [jg647][45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation ofAggregate Documents, such as HTML (MHTML)", RFC 2110, March1997.[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, RFC 2026, October 1996.[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol(HTCPCP/1.0)", RFC 2324, 1 April 1998.[48] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part Five: Conformance Criteria and Examples",RFC 2049, November 1996.[49] Troost, R., Dorner, S. and K. Moore, "Communicating PresentationInformation in Internet Messages: The Content-Disposition HeaderField", RFC 2183, August 1997. |
| 18 筆者のアドレス |
Roy T. FieldingInformation and Computer ScienceUniversity of California, IrvineIrvine, CA 92697-3425, USAFax: +1 (949) 824-1715EMail: fielding@ics.uci.eduJames GettysWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridge, MA 02139, USAFax: +1 (617) 258 8682EMail: jg@w3.orgJeffrey C. MogulWestern Research LaboratoryCompaq Computer Corporation250 University AvenuePalo Alto, California, 94305, USAEMail: mogul@wrl.dec.comHenrik Frystyk NielsenWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridge, MA 02139, USAFax: +1 (617) 258 8682EMail: frystyk@w3.orgLarry MasinterXerox Corporation3333 Coyote Hill RoadPalo Alto, CA 94034, USAEMail: masinter@parc.xerox.comPaul J. LeachMicrosoft Corporation1 Microsoft WayRedmond, WA 98052, USAEMail: paulle@microsoft.comTim Berners-LeeDirector, World Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridge, MA 02139, USAFax: +1 (617) 258 8682EMail: timbl@w3.org |
| 19 付録 |
|
| 19.1 インターネットメディアタイプ message/http と application/http |
HTTP/1.1 プロトコルの定義に追加して、この文書ではインターネットメディアタイプ "message/http" と "application/http" についての仕様を示す。 |
| 19.2 インターネットメディアタイプ multipart/byteranges |
HTTP 206 (Partial Content) レスポンスメッセージが複数の範囲の内容 (複数の重ならない範囲のリクエストへのレスポンス) を含む時、これらはマルチパートメッセージボディとして転送される。 |
| 19.3 寛容なアプリケーション |
この文書は HTTP/1.1 メッセージの生成についての要求を表しているものであるが、すべてのアプリケーションが正しくそれらを実装しているわけでは無いであろう。 |
| 19.4 HTTP のエンティティ と RFC2045 のエンティティとの違い |
HTTP/1.1 は、エンティティが公開されている様々な表現や拡張可能なメカニズムによって転送できるようにするためにインターネットメール (RFC 822[9]) や Multipurpose Internet Mail Extensions (MIME [7]) のために定義されている多くの構造を使用する。 |
| 19.4.1 MIME-Version |
HTTP は MIME 準拠のプロトコルではない。 |
| 19.4.2 公式形式への変換 |
RFC 2045 [7] は、RFC 2049 [48] の section 4 にて記述される様に、インターネットメールエンティティが転送される前に公式形式に変換される事を要求する。 |
| 19.4.3 日付フォーマットの変換 |
HTTP/1.1 は日付比較の処理を簡単にするために制限された日付フォーマット(section 3.3.1) のセットを使用する。 |
| 19.4.4 内容コーディングの導入 |
RFC 2045 は HTTP/1.1 の Content-Encoding ヘッダフィールドに相当するどんな概念も含んでいない。 |
| 19.4.5 No Content-Transfer-Encoding |
HTTP は RFC 2045 の Content-Transfer-Encoding (CTE) フィールドを使用していない。 |
| 19.4.6 転送エンコーディングの導入 |
HTTP/1.1 は Transfer-Encoding ヘッダフィールド (section 14.41) を導入する。 |
| 19.4.7 MHTML と行末制限 |
MHTML [45] インプリメンテーションに伴うコードを共有する HTTP インプリメンテーションは、MIME 行末制限に気をつける必要がある。 |
| 19.5 追加機能 |
RFC 1945 や RFC 2068 ではいくつかの既存の HTTP インプリメンテーションによって使われているプロトコル要素について記述したが、これらは多くのHTTP/1.1 アプリケーションを通じて一貫していなく、また正確ではない。 |
| 19.5.1 Content-Disposition |
Content-Disposition レスポンスヘッダフィールドは、ユーザがその内容をファイルに保存したい場合にオリジンサーバがデフォルトのファイル名を提案する事を意味するように勧告されている。 |
| 19.6 前バージョンとの互換性 |
前のバージョンに従うように指示する事はプロトコル仕様書としての範疇を超える。 |
| 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) を受け入れる、という必要条件はこの仕様書にて定義されている最も重要な変更の一つである。 |
| 19.6.2 HTTP/1.0 持続的接続との互換性 |
クライアントやサーバの中には HTTP/1.0 のクライアントやサーバ中における持続的接続についてある以前のインプリメンテーションと互換性を持たせたいと思うかもしれない。 |
| 19.6.3 RFC 2068 からの変更点 |
この仕様書はキーワードの仕様について正しくまた曖昧で無い様に慎重に検査された。 |
| 20 索引 |
索引についてはこの RFC の PostScript 版を見ていただきたい。 |
| 21. 完全なる著作権宣言 |
Copyright (C) The Internet Society (1999). All Rights Reserved.この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。 |
