#======================================================================# $Id: rfc2616_ja.txt,v 0.56 2004/05/16 20:08:14 H-Hash Exp $ 使用上の注意 以下は当リソースを利用するにあたっての注意事項です。 以下について了 承されない方は、速やかに当リソースを破棄して下さい。 ! 当リソースは、Hypertext Transfer Protocol -- HTTP/1.1 (RFC 2616) を *個人的* に日本語訳したリソースです。 ! 正式なる RFC は、英語版のみです。従って、当リソース中のすべての情報 についてその正確性・有効性を保証しません。それら情報の使用の際に生 じた損害等については、一切の責任は負わない事をご了承下さい。 ! 原版にある、ヘッダ、フッタ、改ページ制御文字等は削除しています。 ! 日本語訳が難しい語は、{ } にてその語を括っています。 ! また Typo 等があった場面では、(※) として訳注を付記しています。 ! 原版中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 各キーワー ド (これらの意味については、本文中 section 1.2 を参照) にあたる日本 語は、* * にて印付しています。 ! 当リソースの最新版は以下の URI から取得できます。 http://www.studyinghttp.net/rfc_ja/2616/ ! このリソースについての御意見・御要望は へ お送り下さい。 以上 #======================================================================# Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June 1999 ハイパーテキスト転送プロトコル -- HTTP/1.1 この文書の位置付け この文書は、インターネットコミュニティにおけるインターネット標準化過 程プロトコルを規定し、改良のために議論と提案を求めるものである。この プロトコルの標準化状態と状況については、"Internet Official Protocol Standards" (STD 1) の最新版を参照していただきたい。この文書の配布に制 限は無い。 著作権表示 Copyright (C) The Internet Society (1999). All Rights Reserved. 概要 ハイパーテキスト転送プロトコル (HTTP) は、分散・共同体ハイパーメディ ア情報システムのアプリケーションレベルプロトコルである。このプロトコ ルは、リクエストメソッド、エラーコード、ヘッダ等の拡張を経て、ネーム サーバや分散オブジェクト管理システム等、ハイパーテキストのために使う 以上に多くの作業のために用いる事ができる、一般的でステートレスなプロ トコルである [47]。HTTP の特徴として、データ表現のタイプ付け、及びネ ゴシエーションがあり、これによって転送されるデータの独立性が確立され るようなシステムが構築できる。 HTTP は、World-Wide Web グローバル情報利用の先進として、1990 年から使 われている。この仕様書は、"HTTP/1.1" と呼ばれるプロトコルを定義し、 RFC 2068 [33] を更新するものである。 目次 1 導入 1.1 目的 1.2 必要条件 1.3 専門用語 1.4 全体の動作 2 表記の慣習と一般文法 2.1 拡張 BNF 2.2 基本ルール 3 プロトコルパラメータ 3.1 HTTP のバージョン 3.2 Uniform Resource Identifiers 3.2.1 一般構文 3.2.2 http URL 3.2.3 URI の比較 3.3 日付/時刻フォーマット 3.3.1 完全な日付 3.3.2 秒差 3.4 文字セット 3.4.1 Charset の誤り 3.5 内容コーディング 3.6 転送コーディング 3.6.1 チャンク形式転送コーディング 3.7 メディアタイプ 3.7.1 公式化とテキストデフォルト 3.7.2 マルチパートタイプ 3.8 製品トークン 3.9 品質値 3.10 言語タグ 3.11 エンティティタグ 3.12 レンジ単位 4 HTTP のメッセージ 4.1 メッセージタイプ 4.2 メッセージヘッダ 4.3 メッセージボディ 4.4 メッセージの長さ 4.5 一般ヘッダフィールド 5 リクエスト 5.1 リクエストライン 5.1.1 メソッド 5.1.2 Request-URI 5.2 リクエストによって識別されるリソース 5.3 リクエストヘッダフィールド 6 レスポンス 6.1 ステータスライン 6.1.1 ステータスコードと説明句 6.2 レスポンスヘッダフィールド 7 エンティティ 7.1 エンティティヘッダフィールド 7.2 エンティティボディ 7.2.1 タイプ 7.2.2 エンティティの長さ 8 接続 8.1 持続的接続 8.1.1 目的 8.1.2 全体の動作 8.1.3 プロクシサーバ 8.1.4 現実的な考察 8.2 メッセージ転送の必要条件 8.2.1 持続的接続とフローコントロール 8.2.2 エラーステータスメッセージのための接続のモニタリング 8.2.3 100 (Continue) ステータスの使用 8.2.4 サーバが早まって接続を閉じた場合のクライアントの振る舞い 9 メソッドの定義 9.1 安全なメソッドと等冪{idempotent} なメソッド 9.1.1 安全なメソッド 9.1.2 等冪{Idempotent} なメソッド 9.2 OPTIONS 9.3 GET 9.4 HEAD 9.5 POST 9.6 PUT 9.7 DELETE 9.8 TRACE 9.9 CONNECT 10 ステータスコードの定義 10.1 Informational 1xx 10.1.1 100 Continue 10.1.2 101 Switching Protocols 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 10.3 Redirection 3xx 10.3.1 300 Multiple Choices 10.3.2 301 Moved Permanently 10.3.3 302 Found 10.3.4 303 See Other 10.3.5 304 Not Modified 10.3.6 305 Use Proxy 10.3.7 306 (Unused) 10.3.8 307 Temporary Redirect 10.4 Client Error 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 10.4.6 405 Method Not Allowed 10.4.7 406 Not Acceptable 10.4.8 407 Proxy Authentication Required 10.4.9 408 Request Timeout 10.4.10 409 Conflict 10.4.11 410 Gone 10.4.12 411 Length Required 10.4.13 412 Precondition Failed 10.4.14 413 Request Entity Too Large 10.4.15 414 Request-URI Too Long 10.4.16 415 Unsupported Media Type 10.4.17 416 Requested Range Not Satisfiable 10.4.18 417 Expectation Failed 10.5 Server Error 5xx 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 10.5.6 505 HTTP Version Not Supported 11 アクセス認証 12 コンテントネゴシエーション 12.1 サーバ駆動型ネゴシエーション 12.2 エージェント駆動型ネゴシエーション 12.3 透過的ネゴシエーション 13 HTTP におけるキャッシング 13.1.1 キャッシュの正当性 13.1.2 警告 13.1.3 キャッシュコントロールメカニズム 13.1.4 明示的なユーザエージェントの警告 13.1.5 規則と警告の例外 13.1.6 クライアントにコントロールされた振る舞い 13.2 期限{Expiration} モデル 13.2.1 サーバが指定した期限 13.2.2 帰納的有効期限 13.2.3 経過時間の計算 13.2.4 期限の計算 13.2.5 期限値を曖昧にしない事 13.2.6 複数のレスポンスを曖昧にしない事 13.3 検証{Validation} モデル 13.3.1 Last-Modified の日付 13.3.2 エンティティタグのキャッシュバリディタ 13.3.3 弱いバリディタと強いバリディタ 13.3.4 エンティティタグや Last-Modified の日付を使う場合のルール 13.3.5 非検証条件 13.4 レスポンスのキャッシュ可能性 13.5 キャッシュから構築したレスポンス 13.5.1 エンドトゥエンドヘッダとホップバイホップヘッダ 13.5.2 修正できないヘッダ 13.5.3 ヘッダの連結 13.5.4 バイトレンジの連結 13.6 ネゴシエートされたレスポンスのキャッシング 13.7 共有キャッシュと非共有キャッシュ 13.8 エラーや不完全なレスポンスのキャッシュの振る舞い 13.9 GET と HEAD の副作用 13.10 更新や削除後の無効化 13.11 Write-Through の強制 13.12 キャッシュの代替 13.13 履歴表 14 ヘッダフィールドの定義 14.1 Accept 14.2 Accept-Charset 14.3 Accept-Encoding 14.4 Accept-Language 14.5 Accept-Ranges 14.6 Age 14.7 Allow 14.8 Authorization 14.9 Cache-Control 14.9.1 キャッシュ可能とは何か 14.9.2 キャッシュによって保存されるものは何か 14.9.3 基本的な期限のメカニズムの修正 14.9.4 キャッシュの再検証とリロードコントロール 14.9.5 No-Transform 指示子 14.9.6 キャッシュコントロールの拡張 14.10 Connection 14.11 Content-Encoding 14.12 Content-Language 14.13 Content-Length 14.14 Content-Location 14.15 Content-MD5 14.16 Content-Range 14.17 Content-Type 14.18 Date 14.18.1 時計の無いサーバの動作 14.19 ETag 14.20 Expect 14.21 Expires 14.22 From 14.23 Host 14.24 If-Match 14.25 If-Modified-Since 14.26 If-None-Match 14.27 If-Range 14.28 If-Unmodified-Since 14.29 Last-Modified 14.30 Location 14.31 Max-Forwards 14.32 Pragma 14.33 Proxy-Authenticate 14.34 Proxy-Authorization 14.35 Range 14.35.1 バイトレンジ 14.35.2 レンジ更新リクエスト 14.36 Referer 14.37 Retry-After 14.38 Server 14.39 TE 14.40 Trailer 14.41 Transfer-Encoding 14.42 Upgrade 14.43 User-Agent 14.44 Vary 14.45 Via 14.46 Warning 14.47 WWW-Authenticate 15 セキュリティについての考察 15.1 個人情報 15.1.1 サーバログ情報の乱用 15.1.2 機密性の高い情報の転送 15.1.3 URI での機密性の高い情報のエンコード 15.1.4 Accept ヘッダに関連するプライバシーの問題 15.2 ファイル名やパス名に基づく攻撃 15.3 DNS スプーフィング 15.4 Location ヘッダとスプーフィング 15.5 Content-Disposition 問題 15.6 認証用証明書{credentials} と無配慮なクライアント 15.7 プロクシとキャッシング 15.7.1 プロクシを使ったサービス拒否攻撃 16 謝辞 17 参考文献 18 筆者のアドレス 19 付録 19.1 インターネットメディアタイプ message/http と application/http 19.2 インターネットメディアタイプ multipart/byteranges 19.3 寛容なアプリケーション 19.4 HTTP のエンティティと RFC 2045 のエンティティとの違い 19.4.1 MIME-Version 19.4.2 公式形式への変換 19.4.3 日付フォーマットの変換 19.4.4 内容コーディングの導入 19.4.5 No Content-Transfer-Encoding 19.4.6 転送エンコーディングの導入 19.4.7 MHTML と 行末制限 19.5 追加機能 19.5.1 Content-Disposition 19.6 前バージョンとの互換性 19.6.1 HTTP/1.0 からの変更点 19.6.2 HTTP/1.0 持続的接続との互換性 19.6.3 RFC 2068 からの変更点 20 索引 21 完全なる著作権宣言 1 導入 1.1 目的 ハイパーテキスト転送プロトコル (HTTP) は、分散・共同体ハイパーメディ ア情報システムのアプリケーションレベルプロトコルである。HTTP は、 World-Wide Web グローバル情報利用の先進として、1990 年から使われてい る。HTTP の最初のバージョンは、HTTP/0.9 と呼ばれ、インターネットを通 じて未加工のデータを転送するための単純なプロトコルであった。HTTP/1.0 は、RFC 1945 [6] にて定義され、転送されるデータに関する外部情報とリク エスト／レスポンスセマンティクスの修飾子を含んだ MIME-like なメッセー ジ形式のメッセージを付加する事によってプロトコルを改良した。しかし、 HTTP/1.0 ではプロクシやキャッシングの階層構造、持続的接続の必要性、仮 想ホストへの考慮が十分になされていなかった。さらに、実装が不完全なの に自身を "HTTP/1.0" だと称するアプリケーションの増加で、互いの通信ア プリケーションが互いに真の能力を決定するために、プロトコルバージョン を変更する必要性が出てきた。 この仕様書では、"HTTP/1.1" と呼ばれるプロトコルを定義している。このプ ロトコルはそれらの特徴の確実な実装を保証するため HTTP/1.0 よりも厳格 な要求を含んでいる。 実際の情報システムは、検索、フロントエンドの更新、注釈等を含む、単純 なリソースの回収よりもより多くの機能性を必要としている。HTTP はリクエ ストの目的を示すためのメソッドやヘッダの open-ended セットを認めてい る [47] 。これは、メソッドが適用されるリソースを示すための location (URL) [4] や name (URN) [20] としての Uniform Resource Identifier (URI) [3] によって供給される参照の規律に基づいている。メッセージは Multipurpose Internet Mail Extensions (MIME) [7] にて定義される、イン ターネットメール [9] により使用されている物に似たフォーマットで渡され る。 また HTTP は、ユーザエージェントと SMTP [16], NNTP [13], FTP [18], Gopher [2], WAIS [10] プロトコルをサポートするものを含む、別の情報シ ステムのプロクシ／ゲートウェイ間の通信用の、一般的なプロトコルとして も使用される。これによって、HTTP は様々なアプリケーションから利用でき るリソースへの基本的なハイパーメディアアクセスを可能にする。 1.2 必要条件 この文書中における "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" という 各キーワードは、RFC 2119 [34] にて記述されるように解釈される。 もし、あるインプリメンテーションが、そのプロトコルの MUST あるいは REQUIRED レベルの要求の一つ以上を満足できないのならば、そのインプリメ ンテーションは従順なものではない。もし、あるインプリメンテーションが そのプロトコルのすべての MUST あるいは REQUIRED レベルと、すべての SHOULD レベルの要求を満足していれば、そのインプリメンテーションは "無 条件に従順" と呼ぶ。そして、すべての MUST レベルの要求は満たしている が、一つでも SHOULD 要求を満たしていないものは "条件付きで従順" と呼 ばれる。 1.3 専門用語 この仕様書では、HTTP 通信に参加する人間、あるいは物を参照するための専 門用語をいくつか使用する。 コネクション {connection} 通信の目的で二つのプログラム間に確立されるトランスポート層の仮想通 信路。 メッセージ {message} section 4 にて定義されるシンタックスを持ち構造化されたオクテットシ ーケンスから成り、接続を介して転送される、HTTP 通信での基本単位。 リクエスト {request} section 5 にあるような、HTTP リクエストメッセージ。 レスポンス {response} section 6 にあるような、HTTP レスポンスメッセージ。 リソース {resource} section 3.2 にて定義される URI によって判別されるネットワークデー タオブジェクト、あるいはサービス。リソースは複数の表現 (例えば、複 数の言語、データフォーマット、サイズ、解像度等) で利用したり、別の 方法で変更したりできる。 エンティティ {entity} リクエストやレスポンスの付加物{payload} として転送される情報。エン ティティは、section 7 で記述されるように、エンティティヘッダフィー ルドという形での外部情報と、エンティティボディという形での内容から 成る。 表現 {representation} section 12 にて記述されているようなコンテントネゴシエーションに従 ったレスポンスを含むエンティティ。特定のレスポンスステータスには、 関連する複数の表現が存在する事がある。 コンテントネゴシエーション {content negotiation} section 12 で記述されているように、リクエストを処理する時、適切な 表現を選択するためのメカニズム。エラーレスポンスも含めた、どんなレ スポンスにおいてもエンティティの表現はサーバと交渉 {negotiate} さ れる。 バリアント {variant} リソースはどの瞬間においても一つ、あるいは一つ以上、それに関連付け られた表現を持っている。それらの表現のそれぞれを `バリアント' と呼 ぶ。`バリアント' という語の使用が、そのリソースがコンテントネゴシ エーションされているという事を意図するわけではない。 クライアント {client} リクエストを送信する目的でコネクションを確立するプログラム。 ユーザエージェント {user agent} リクエストを発行するクライアント。これらはしばしば、ブラウザ、エデ ィタ、スパイダ (web ロボット) の事を指すが、その他のエンドユーザツ ールも指す。 サーバ {server} レスポンスを返す事で、リクエストを処理するためのコネクションを受け 入れるアプリケーションプログラム。プログラムの中にはクライアントと サーバの両方の機能を持つものがあるが、ここでは一般的なプログラムの 機能を表すというよりはむしろ、特定のコネクションのためにプログラム によって果たされる役割のみを表す。同様に、リクエストに応じてオリジ ンサーバ、プロクシ、ゲートウェイ、トンネルと振る舞いを切り換える場 合がある。 オリジンサーバ {origin server} 指定されるリソースが存在するか、あるいは生成されるサーバ。 プロクシ {proxy} 他のクライアントの代わりとしてリクエストを行うためにサーバとクライ アントの両方の役割を果たす中継プログラム。リクエストは、可能な変換 をもって、内部で処理されるか、あるいは他のサーバに渡される。プロク シは、この仕様書が要求するクライアントとサーバの両方の機能を実装し *なければならない*。"透過的プロクシ" とは、プロクシへの認証やクラ イアント自身の証明が要求されるようなもの以外のリクエストやレスポン スを修正しないようなプロクシである。"透過的でないプロクシ" とは、 ユーザエージェントに、ある種の翻訳、メディアタイプの変形、使用プロ トコルの制限、匿名性向上のためのフィルタリング等のような、追加的サ ービスを提供するためにリクエストやレスポンスを修正するようなプロク シである。その振る舞いが透過的であるか無いかが明言されている部分を 除けば、それぞれのプロクシは HTTP プロクシとして必要な要素を共に持 ち合わせている。 ゲートウェイ {gateway} 他のサーバを中継するサーバ。プロクシとは違い、ゲートウェイはまるで リクエストされたリソースのオリジンサーバのように、リクエストを受け る。リクエストしたクライアントは、それをゲートウェイと通信している という事を気付かないかもしれない。 トンネル {tunnel} 二つの接続の間をまるで目隠しリレーを行う様に振る舞う中継プログラ ム。一度起動したら、それが HTTP リクエストによるものであっても、ト ンネル自身は HTTP 通信における当事者とみなさない。トンネルは中継す る両端の通信が終了した時、終了する。 キャッシュ {cache} プログラムがレスポンスメッセージをローカルに記録しておく場所であ り、それらメッセージの保存、検索、削除を管理するサブシステムを指 す。キャッシュは、同様のリクエストが起きた際にレスポンス時間やネッ トワーク帯域幅の消費の軽減のために、キャッシュ可能なレスポンスを保 存する。どのようなクライアントもサーバもキャッシュを持つ事はできる が、トンネルとして振る舞っているサーバはキャッシュを使用できない。 キャッシュ可能 {cacheable} レスポンスは、もしキャッシュが後続のリクエストに答えるという目的で の使用のために、レスポンスメッセージのコピーを保存する事が許される ならばキャッシュ可能であるという。HTTP レスポンスのキャッシュ使用 の決定の決まりは section 13 にて定義されている。例えリソースがキャ ッシュ可能でも、キャッシュは特定のリクエストのためにキャッシュされ たコピーを使うかどうかについて制限を受ける可能性がある。 ファーストハンド {first-hand} レスポンスが、オリジンサーバ、あるいは一つ以上経由したプロクシから 不必要な遅れ無しに届くならば、それをファーストハンドであるという。 また、オリジンサーバで有効性を直接チェックされたレスポンスもファー ストハンドであるという。 明示的有効期限 {explicit expiration time} オリジンサーバが、エンティティの有効性の再確認無しにキャッシュを返 すべきではないとしている時刻。 帰納的有効期限 {heuristic expiration time} 有効期限が指定されていない時に、キャッシュによって指定される有効期 限。 経過時間 {age} レスポンスの経過時間とは、それがオリジンサーバから送られてから、あ るいはオリジンサーバによって十分に有効性が確認された時からの時間を 指す。 有効期間 {freshness lifetime} レスポンスが生成されてから有効期限までの時間の長さ。 新鮮である {fresh} レスポンスは、その経過時間が有効期間を経過していないものを新鮮であ るという。 新鮮でない {stale} レスポンスは、その経過時間が有効期間を経過したものを新鮮でないとい う。 意味的に透過である {semantically transparent} キャッシュは、パフォーマンスの向上以外に、リクエストしたクライアン トにもオリジンサーバにも影響が無い時、特定のレスポンス関して、意味 的に透過な方法で振る舞う。キャッシュが意味的に透過な時、クライアン トはオリジンサーバから直接処理された時に受け取るであろうリクエスト と全く同じレスポンスを受け取る。(ホップバイホップヘッダを除く) バリディタ {validator} キャッシュ内にあるリソースが、エンティティのコピーと同等かどうかが わかるとされている (例えば、エンティティタグや Last-Modified 時刻 等の) プロトコルエレメント。 アップストリーム／ダウンストリーム {upstream/downstream} アップストリームとダウンストリームとは、メッセージの流れを表す。す べてのメッセージは、上流{upstream} から下流{downstream} へと流れ る。 インバウンド／アウトバウンド {inbound/outbound} インバウンドとアウトバウンドは、メッセージを送るためのリクエストと レスポンスの道のりに従う。"インバウンド" とは "オリジンサーバに向 かって行く事" を、"アウトバウンド" とは "ユーザエージェントに向か かって行く事" を、それぞれ意味する。 1.4 全体の動作 HTTP プロトコルはリクエスト／レスポンスプロトコルである。クライアント は、サーバへの接続上で、リクエストメソッド、URI、そしてプロトコルバー ジョン、その後にリクエスト修飾子、クライアント情報、可能であれば内容 本体を含んだ MIME-like メッセージ形式をサーバにリクエストとして送る。 サーバは、メッセージのプロトコルバージョンと成功か失敗を表すコードを 含むステータス行に続き、サーバ情報、エンティティメタ情報、可能であれ ばエンティティボディの内容を含む MIME-like メッセージで応答する。HTTP と MIME の関係は、付録 19.4 に記述されている。 多くの HTTP 接続は、ユーザエージェントによって開始され、あるオリジン サーバ上のリソースに適用するためのリクエストから成り立つ。この最も簡 単な場合、ユーザエージェント (UA) とオリジンサーバ (O) との間の単一接 続経由 (v) で成し遂げられるだろう。 request chain ------------------------> UA -------------------v------------------- O <----------------------- response chain リクエスト／レスポンス連鎖中に一つ以上の中継者が現れると、状況はより 複雑になる。一般的な中継者には、プロクシ、ゲートウェイ、トンネルの三 つが存在する。プロクシは、その絶対形式の URI のリクエストを受け取り、 メッセージのすべてもしくは一部を書き換え、URI によって識別されるサー バに再フォーマットされたリクエストを転送する転送エージェントである。 ゲートウェイは、ある別のサーバ (群) の上の層として動作し、もし必要な らリクエストを根底にあるサーバのプロトコルに変換するための受信エージ ェントである。トンネルは、メッセージを変更する事なく二つの接続間の中 継点として動作する。トンネルは通信が (ファイアウォールのような) 中継 者を通して伝えられる必要がある時、さらに中継者がメッセージの内容を理 解できない時に使用される。 request chain --------------------------------------> UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------- response chain 上図は、ユーザエージェントとオリジンサーバの間の三中継者 (A, B, C) を 表している。リクエストやレスポンスのメッセージが移動する全体の連鎖は 四つに分ける事ができるであろう。HTTP 通信オプションによっては、適用 できる範囲が、隣の接続にのみだったり、トンネルではない隣接接続だった り、連鎖の終末のみだったり、あるいは連鎖上のすべての接続に適用できた りするので、この区別は重要である。図形では線形であるが、それぞれが複 数に、また同時に通信を行う事ができる。例えば、B は A からのリクエスト を処理すると同時に、A 以外の多くのクライアントからリクエストを受信し ているかもしれないし、あるいは C 以外のサーバにリクエストを転送してい るかもしれない。 トンネルとして動作していない 通信のすべてのパーティは、内部的なキャッ シュやリクエスト処理に使用できる。キャッシュの効果とは、もし連鎖上に 連なるある一つがそのリクエストに適用できるキャッシュされたレスポンス を持っているなら、リクエスト／レスポンス連鎖を短縮する事である。以下 では、もし B が、UA や A がキャッシュしていないリクエストに対する O からの (C を経由した) 以前のレスポンスのキャッシュされたコピーを持っ ている場合の結果となる連鎖を説明している。 request chain ----------> UA -----v----- A -----v----- B - - - - - - C - - - - - - O <--------- response chain すべてのレスポンスがキャッシュ可能であるわけではなく、いくつかのリク エストではキャッシュの動作への特別な要求を行う修飾子を含む事ができ る。キャッシュの動作やキャッシュ可能なレスポンスに対する HTTP の要求 は section 13 で定義されている。 事実、現在 World Wide Web 上にて実験され、設置されているキャッシュと プロクシには幅広い種類のアーキテクチャやコンフィギュレーションがあ る。これらのシステムには、海を渡るような通信{transoceanic} のバンド幅 を節約するためにプロクシキャッシュを全国的な組織が階層的に管理するも の{national hierarchies} や、エントリしているキャッシュを放送するため のシステムや、CD-ROM を使ってキャッシュされたデータのサブセットを配布 する組織等も含む。HTTP システムは、高バンド幅通信上の社内イントラネッ トでも、そして非力なラジオ通信や断続的な接続を使う PDA 経由でアクセス するためにも使用される。HTTP/1.1 が目指すものは、高い信頼性と、もし失 敗するとしても少なくとも確実な徴候が要求されるウェブアプリケーション を作る人間のニーズに合ったプロトコル構造を取り入れていく一方で、既に 設置されている幅広い多様なコンフィギュレーションをサポートする事であ る。 HTTP 通信は、普通 TCP/IP 接続上で行う。デフォルトポートは TCP 80 であ るが、他のポートを使用する事もできる [19] 。これは、インターネットや 他のネットワーク上の別のプロトコルの最上部として、HTTP を実装する事を 排除しない。HTTP は確実な転送のみを前提し、そのような保証を供給するど んなプロトコルでも使用できる。問題においてプロトコルのデータ転送ユニ ット上の HTTP/1.1 リクエストとレスポンス構造のマッピングはこの仕様書 の範疇を超える。 HTTP/1.0 では、ほとんどのインプリメンテーションはそれぞれのリクエスト ／レスポンスを交換するために新しい接続を使用していた。HTTP/1.1 では、 接続は一つ以上のリクエスト／レスポンス交換に使用できるが、レスポンス の種類によっては接続がクローズされるかもしれない (section 8.1 参照)。 2 表記の慣習と一般文法 2.1 拡張 BNF この文書において詳述されるメカニズムのすべては、単調 Backus-Naur Form (BNF) と、RFC 822 [9] で使用されているものに似た拡張 BNF との両方で記 述されている。実装者は、この仕様書を理解するためにこの表記法に精通し ている必要があるだろう。拡張 BNF は以下の構造を含んでいる。 name = definition name とは、("<" と ">"で囲まれているものを除き) 単純にそれ自身の名 前であり、その定義とは等号 "=" 文字によって分割されている。空白 は、二行以上に渡るルール定義を示すために使われる連続行の行頭空白に おいてのみ意味を持つ。特定の基本ルールは SP, LWS, HT, CRLF, DIGIT, ALPHA 等のように大文字である。角括弧は、それらの存在がルール名の使 用の理解を容易にするであろうときに定義の中に使用される。 "literal" クォーテーション記号はリテラルテキストを囲む。もし特に明言されなけ れば、テキストは大文字・小文字を区別しない。 rule1 | rule2 バー ("|") で区切られた要素は二者択一である。例えば "yes | no" は yes か no を受け入れるだろう。 (rule1 rule2) 括弧で囲まれた要素は単一の要素として扱われる。従って、 "(elem (foo | bar) elem)" は、トークンシーケンス "elem foo elem" と "elem bar elem" を認める。 *rule 要素の前にある "*" 文字は繰り返しを意味する。完全な形式は "*element" で、これは element 出現が最低、最大であるこ とを示している。デフォルト値は 0 と無限なので、"*(element)" はゼロ を含むどんな回数も可能であり、"1*element" は最低一つ、"1*2element" は一つか二つが可能である。 [rule] 角括弧は省略可能な要素を囲む。すなわち 、"[foo bar]" は "*1(foo bar)" と同等である。 N rule 具体的な繰り返し。"(element)" は "*(element)" と同等であ る。これは、(element) の出現が確実に 存在する。従って 2DIGIT は二文字の数字であり、3ALPHA は三文字の アルファベット文字の文字列 である。 #rule "#" 構造は、"*" と似て、要素のリストを定義するために定義されてい る。完全な形式は "#element" で、これは element が最低 、 最大 の存在を示していて、それぞれは一つ以上のコンマ (",") と *省略可能な* 連続空白 (LWS) で区切られる。これによって、通常のリス ト形式をとても簡単にできる。例えば、 ( *LWS element *( *LWS "," *LWS element )) のルールは 1#element として表す事ができる。 この構造が使用されているどこでも、null 要素が許されるが、存在する 要素の数に影響しない。つまり、"(element), , (element)" は許される が、二つの要素として数えられる。それゆえに、最低一つの要素が必要な 所では、最低一つの null でない要素が与えられ *なければならない* 。 デフォルト値は 0 と無限であるので、"#element" はゼロを含むどんな数 も認め、"1#element" は最低 1 個を必要とし、"1#2element" は 1 個か 2 個を認めている。 ; comment ルールテキストの右からいくらか距離を置いて始まるセミコロンは、 行 末まで続くコメントの始まりである。これは、この仕様書と共に有益な記 述を含めるための簡単な方法である。 黙示的 *LWS この仕様書によって記述される文法は、単語に基づいている。その他の方 法で明記していなければ、連続した空白(LWS) は、フィールドの解釈を変 える事無く、二つの隣接した言葉 (トークンや引用符で囲まれた文字列) の間や隣接したトークンとデリミタ (LWS かセパレータ) の間に含む事が できる。二つのトークンの間には、最低一つのデリミタ (LWS かセパレー タ) が、それらが単一のトークンとして解釈されないように存在し *なけ ればならない*。 2.2 基本ルール 以下のルールは、基本的な構造概念を記述するためにこの仕様書全体に渡っ て使用される。文字セットとしてコード化された US-ASCII は ANSI X3.4-1986 [21] にて定義されている。 OCTET = <8-bit のデータシーケンス> CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = <"> = HTTP/1.1 は、エンティティボディ以外のすべてのプロトコル要素のための行 末の印として CR LF というシーケンスを定義している (寛容なアプリケーシ ョンのためには、付録 section 19.3 参照)。エンティティボディ内の行末の 印は、section 3.7 で記述されているように、その関連するメディアタイプ によって定義される。 CRLF = CR LF HTTP/1.1 ヘッダフィールドの値は、もし続く行が空白か水平タブで始まって いるならば複数行にまたがって折り返す事ができる。すべての連続空白は、 折り返しているものを含め、SP と同じ意味を持つ。受信者は、フィールドの 値を解釈したり、メッセージを下層{downstream} に流す前に、すべての連続 空白を１つの SP に置きかえた方が *よい* 。 LWS = [CRLF] 1*( SP | HT ) TEXT ルールは、メッセージパーサによって解釈される事を望まないフィール ドの内容と値の説明にのみ使用される。*TEXT の言葉は、RFC 2047 [14] の ルールに従ってエンコードされた時にのみ、ISO-8859-1 [22] 以外の文字セ ットの文字を含む事が *できる* 。 TEXT = CRLF は、ヘッダフィールドの連続行の一部として使う時のみ、TEXT の定義 に含まれる。折り返し LWS は TEXT の値を解釈する前に１つの SP に置きか えるであろう事が予想される。 16 進数文字は様々なプロトコル要素において使用される。 HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 多くの HTTP/1.1 ヘッダフィールドの値は、LWS か特別な文字によって区切 られた言葉から成る。これらの特別な文字がパラメータ値内で使用されるた めには (section 3.6 で定義される様に) 引用された文字列内に存在し *な ければならない* 。 token = 1* separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT コメントは、いくつかの HTTP ヘッダ内でコメント文字を括弧で囲む事によ り含む事ができる。コメントは、それらのフィールド値定義の一部として "comment" を含んでいるフィールドにおいてのみ許される。その他のすべて のフィールドにおいては、括弧はフィールド値の一部とみなされる。 comment = "(" *( ctext | quoted-pair | comment ) ")" ctext = <"(" と ")" を除いたあらゆる TEXT> テキストの文字列は、ダブルクォート記号を使って引用されているなら、単 一の言葉として解析される。 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = <<"> を除いたあらゆる TEXT> バックスラッシュ文字 ("\") は、quoted-string と comment 構造内でのみ 単一文字引用メカニズムとして使用する事が *できる*。 quoted-pair = "\" CHAR 3 プロトコルパラメータ 3.1 HTTP のバージョン HTTP では、プロトコルのバージョンを示すために "<メジャーバージョン>. <マイナーバージョン>" と番号づける。プロトコルバージョンのつけ方の方 針としては、その通信で得られたものの特徴を伝えるというよりも、送信者 がメッセージのフォーマットや将来的な HTTP 通信においての理解能力を表 すために使わせようとするものである。通信の振る舞いが影響を受けないメ ッセージの構成要素が追加されたり、拡張可能なフィールドの値が追加され るような場合ではバージョン番号は変更されない。<マイナー> バージョン は、その変更が、一般的なメッセージ解析アルゴリズムを変えるものではな いが、メッセージセマンティクスを付け加え、送信者の機能に追加があった 事を意図する時に、上がる。<メジャー> バージョンは、プロトコル内のメッ セージのフォーマットが変更される時に、上がる。完全なる解説を必要とす る場合は RFC 2145 [36] 参照。 HTTP メッセージのバージョンは、メッセージの最初の行の HTTP-Version フ ィールドで示される。 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT メジャー番号とマイナー番号は、分割された整数値として扱われ *なければ ならない* ので、メジャー番号とマイナー番号はそれぞれ、一桁以上に増や しても *よい* という事に注意せよ。従って、HTTP/2.4 は HTTP/2.13 より も下のバージョンで、さらにそれらは HTTP/12.3 よりも下となる。先行する ゼロは受け取り側によって無視され *なければならない* し、また送られ *てはならない*。 "HTTP/1.1" という HTTP-Version を含むリクエストやレスポンスメッセージ を送るアプリケーションは、少なくとも条件付きでこの仕様書に準じてい *なければならない* 。少なくとも条件付きでこの仕様書に準じているアプリ ケーションならば、送信するメッセージに "HTTP/1.1" という HTTP-Version を含める *べきであり*、HTTP/1.0 と互換性の無い全てのメッセージには、 必ず含め *なければならない*。 特定の HTTP-Version を送る時についての詳細は、RFC 2145 [36] 参照。 アプリケーションの HTTP バージョンとは、そのアプリケーションが少なく とも条件付きで準じている最も高い HTTP バージョンの事である。 プロクシやゲートウェイなどのアプリケーションは、プロトコルにおけるア プリケーションのバージョンの違うメッセージを転送する時に注意する必要 がある。プロトコルバージョンは送り手のプロトコル能力を示すので、プロ クシ／ゲートウェイは、決して自身の実際のバージョンよりも大きなバージ ョン指標が付いたメッセージを送っ *てはならない*。もし、より高いバージ ョンのリクエストを受けたならば、プロクシ／ゲートウェイはリクエストの バージョンを下げるか、エラーを返すか、トンネル動作にスイッチするかの いずれかを行わ *なければならない*。 RFC 2068 [33] の発行以降に HTTP/1.0 プロクシの通信上の問題が発見され た事を受けて、キャッシュするプロクシは、必ずサポートする最新のバージ ョンにアップグレードし *なければならない*。ゲートウェイは、可能であれ ばアップグレードしても *よい*。またトンネルは、アップグレードし *ては ならない*。そのリクエストのプロクシ／ゲートウェイのレスポンスは、リク エストと同じメジャーバージョンでなければならない。 注意: HTTP のバージョン間の変換は、含まれるバージョンによって要求され る、あるいは禁止されるヘッダフィールドの修正を含んでいてもよい。 3.2 Uniform Resource Identifiers URI とは、既に多くの名前で、例えば WWW address, Universal Document Identifier, Universal Resource Identifier [3], そして、最終的に Universal Resource Locator (URL) [4] と Name (URN) [20] という名で知 られている。HTTP に限って言えば、Uniform Resource Identifier とはリソ ースを名前や場所、その他の特徴で識別する簡潔に書式化された文字列のこ とである。 3.2.1 一般構文 HTTP における URI は、絶対形式か、それが使われている状況に依存する、 ある既知の基底 URI [11] からの相対形式で表される。この二つの形式は、 絶対 URI は常にコロンを後に持つスキーム名から開始しているという事から 区別される。URL 構文やセマンティクスの定義についての情報については、 (RFC 1738 [4] と RFC 1808 [11] を置き換えた) "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] を参 照。この規格書では、その規格書にある、"URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path", "rel_path", "authority" の 定義を採用する。 HTTP プロトコルでは、URI の長さにどんな制限も設けていない。サーバは、 自身が持つどんなリソースの URI も扱え *なければならない* し、もしその ような URI を生成する GET ベースのフォームを用意するなら、無制限の長 さの URI を扱える *べきである*。もし、その URI がサーバが処理できるも のよりも長ければ、サーバは 414 (Request-URI Too Long) ステータスを返 す *べきである* (section 10.4.15 参照)。 注意: いくつかの古いクライアントやプロクシインプリメンテーションは 255 バイトを超える長さを持つ URI を適切にサポートしていないかもし れないので、サーバはそのような URI に頼る場合は注意を払うべきであ る。 3.2.2 http URL "http" スキームは HTTP プロトコル経由でネットワークリソースの位置を指 すために使われる。このセクションでは http URL について、スキーム特有 のシンタックスとセマンティクスを定義する。 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] もし、port が空かあるいは与えられていなければ、ポート 80 が仮定され る。そのセマンティクスは、識別されるリソースはそのホストのそのポート で TCP 接続のためのリスニングをしているサーバ上にあり、リソースに対す する Request-URI は、abs_path である (section 5.1.2)。できれば、URL での IP アドレスの使用は避ける *べきである* (RFC 1900 [24] 参照)。も し、abs_path が URL で与えられていなければ、そのリソースへの Request- URI として使われる時に、"/" が与えられなければならない (section 5.1.2)。もし、プロクシが fully qualified domain name ではない ホスト ネームを受けとったならば、プロクシは自分のドメインにそのホストネーム を追加する事が *できる*。もし、プロクシが fully qualified domain name を受けとったならば、プロクシは絶対にホストネームを書き換え *てはなら ない*。 3.2.3 URI の比較 二つの URI が一致しているかどうかを決めるために比較する時、クライアン トは URI 全体で大文字・小文字を区別したオクテット同士の比較をす *べき である* が、以下は例外とする。 - ポートが空、あるいは与えられていない場合は、その URI のデフォル トのポートと等価である。 - ホスト名の比較は、大文字・小文字を区別し *てはならない*。 - スキーム名の比較は、大文字・小文字を区別し *てはならない*。 - 空の abs_path は、"/" という abs_path と等価である。 "reserved" あるいは "unsafe" セット (RFC 2396 [42] 参照) 以外の全ての 文字は、それらを ""%" HEX HEX" エンコーディングしたものと等しい。(※) (※訳注) "unsafe" セットは、RFC 2396 中には存在しない。 例えば、以下の三つの URI は等価である。 http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html 3.3 日付/時刻フォーマット 3.3.1 完全な日付 HTTP アプリケーションは、歴史的に日付／時刻スタンプの表現のために三つ の異なるフォーマットが許されている。 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 最初のフォーマットはインターネット標準としてより好まれ、RFC 1123 [8] (RFC 822 [9] の改定) にて定義される固定長サブセットを表す。第二のフ ォーマットは一般的に使用されているが、時代遅れ{obsolete} な RFC 850 [12] 日付フォーマットに基づいており、四桁年号が欠落している。日付の値 を解析する HTTP/1.1 クライアントとサーバは (HTTP/1.0 との互換性のため に) 三つすべてのフォーマットを受け入れ *なければならない* が、ヘッダ フィールドにおいて HTTP-date 値を表す時は RFC 1123 フォーマットのみを 生成し *なければならない*。更なる情報については、section 19.3 参照。 注意: 日付の値の受取人は、時々 SMTP や NNTP のプロクシ／ゲートウェ イを経由してメッセージが回収されたり送信されたりするような場合の時 に、非 HTTP アプリケーションによって送られるであろう日付の値を受け 入れる程に強固である事が推奨される。 すべての HTTP 日付／時刻スタンプは、例外を除いてグリニッジ標準時刻 (GMT) で表され *なければならない*。HTTP の用途では、GMT は UTC (Coordinated Universal Time) と正確に一致する。これは、タイムゾーンを 表す三文字略として "GMT" の含める事によって最初の二つのフォーマットの 中で示され、asctime フォーマットを解釈する時には仮定され *なければな らない*。HTTP-date は大文字・小文字を区別するが、文法書中の SP のよう に、含まれる特定のもの以上の追加的 LWS を含ん *ではならない*。 HTTP-date = rfc1123-date | rfc850-date | asctime-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP "GMT" asctime-date = wkday SP date3 SP time SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) date2 = 2DIGIT "-" month "-" 2DIGIT ; day-month-year (e.g., 02-Jun-82) date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) ; month day (e.g., Jun 2) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" weekday = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday" month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" 注意: この日付／時刻スタンプフォーマットの HTTP 的要求は、プロトコ ルストリーム内での使用にのみ適用される。クライアントやサーバは、こ れらのフォーマットをユーザ提示やログイン要求などのために使用する必 要はない。 3.3.2 秒差 ある HTTP ヘッダフィールドでは、メッセージが受信されてからの時間を、 10 進数で表される整数の秒数値で、表す事ができる。 delta-seconds = 1*DIGIT 3.4 文字セット HTTP では、"文字セット" という用語を MIME で表現される場合と同じ定義 で使用する。 この文書中では "文字セット" という用語を、一つ以上のテーブルを使って オクテットシーケンスを文字シーケンスに変換するための方法を述べるため に使う。与えられた文字セットですべての文字が利用できるわけではなかっ たり、文字セットがある特定の文字を表すために二つ以上のオクテットシー ケンスを供給する場合でも、別の指示による無条件な変換が必要でないは事 に注意せよ。この定義は、US-ASCII のような簡単な単一テーブルマッピング から、ISO-2022 の技術を使うような複雑なテーブルをスイッチする方法ま で、さまざまな種類の文字エンコーディングを認めようとするものである。 しかし、MIME 文字セット名に関連したこの定義は、1 オクテットから文字に 行われるマッピングを完全かつ明確に述べ *なければならない*。特に、正確 なマッピングを決定するために外部プロフィール情報を使用する事は許され ない。 注意: ここで使われる "文字セット" という用語は、より一般的には "文 字エンコーディング" という語で述べられる。しかし、HTTP と MIME と で同じ登録を共有しているので、用語もまた共有される事は重要な事であ る。 HTTP 文字セットは大文字・小文字を区別しないトークンによって識別され る。トークンの完全なセットは、IANA の文字セット登録機構 [19] によって 定義される。 charset = token HTTP では、文字セットの値として独自のトークンを使用する事を認めている が、IANA の文字セット登録機構 [19] によって定義済みであるトークンは、 すべてその登録機構で定義された文字セットを表さ *なければならない*。ア プリケーションは、使用する文字セットを IANA の登録機構によって定義さ れたものに制限す *べきである*。 HTTP アプリケーションの開発者は、IETF の文字セット要求を認識す *べき である* [38] [41]。 3.4.1 Charset の誤り いくつかの HTTP/1.0 ソフトウェアは、"受領者が推測すべき"という意図 で、文字セットの無い Content-Type ヘッダを不正確に解釈している。この 振る舞いをやめさせたい送信者は、例え文字セットが ISO-8859-1 の時でも 文字セットパラメータを含む事が *できる* し、受領者が混乱する事が無い であろうという事がわかっていれば、それを含む *べきである*。 不幸な事に、いくつかの古い HTTP/1.0 クライアントでは、明示的文字コー ドパラメータを適切に扱えなかった。HTTP/1.1 の受領者は、送信者によって 供給される文字セットラベルを尊重し *なければならない*。そして、文字コ ードを "推測" する機能を持つユーザエージェントは、もしその文字セット をサポートしていれば、始めに文書を表示する時に、受領者が好むものより も content-type フィールドにある文字セットを使わ *なければならない*。 section 3.7.1 参照。 3.5 内容コーディング 内容コーディング値は、エンティティに適用されている、もしくは適用でき るエンコーディング変換を示す。内容コーディングは、文書をその根本的な メディアタイプのアイデンティティを失ったり、情報の欠落する事が無いよ うに、圧縮したり、他の有用な変換が行われる事を許可するために、主に使 用される。しばしば、エンティティはコード化された形態で保存され、直接 転送され、受け取り側によってのみデコードされる。 content-coding = token すべての content-coding 値は、大文字・小文字を区別しない。HTTP/1.1 で は、content-coding 値を Accept-Encoding (section 14.3) と Content-Encoding (section 14.11) ヘッダフィールドで使用する。その値は content-coding で表されるけれども、そのエンコーディングを解読するため にはどんなデコーディングメカニズムが必要であるかを示す事は、より重要 な事である。 Internet Assigned Numbers Authority (IANA) は、content-coding 値トー クンに対する登録を行なっている。初めに登録されているものには、以下の トークンが含まれる: gzip RFC 1952 [25] に記述されているファイル圧縮プログラム "gzip" (GNU zip) によって作られるエンコーディングフォーマット。このフォーマ ットは32 bit CRC 付きの Lempel-Ziv コーディング (LZ77) である。 compress 一般的な UNIX ファイル圧縮プログラム "compress" で作られるエンコ ーディングフォーマット。このフォーマットは Lempel-Ziv-Welch コー ディング (LZW) に適合している。 エンコーディングフォーマットの確認のためにプログラム名を使用する 事は望ましくなく、将来的なエンコーディングを妨害する。ここでのこ れらの使用は歴史的な慣例であり、決して良い方法ではない。HTTP の 過去のインプリメンテーションへの互換性のため、アプリケーションは "x-gzip" と "x-compress" をそれぞれ "gzip" と "compress" に等価 であるとみなす *べきである*。 deflate RFC 1951 [29] に記述されている "deflate" 圧縮メカニズムと結合し た、RFC 1950 [31] にて定義されている "zlib" フォーマット。 identity デフォルトエンコーディング、つまり圧縮・変形をしない場合に使う。 この content-coding 値は、Accept-Encoding ヘッダでのみ使用し、 Content-Encoding ヘッダでは使用す *べきではない*。 新しい content-coding 値トークンは登録される *べきである*。すなわち、 クライアントとサーバとの間での内部操作性を認めるため、新しい値を実装 する必要のある内容コーディングアルゴリズムの仕様は、広く利用できて、 独立したインプリメンテーションに適し、そしてこの章で定義された内容コ ーディングの目的に従う *べきである*。 3.6 転送コーディング 転送コーディング値は、ネットワークを通して "安全な転送" を保証するた めに、エンティティボディに適用されている、する事のできる、する必要の あるエンコーディング変換を示すために使われる。転送コーディングは、元 のエンティティではなくメッセージの特性である、という点で内容コーディ ングとは異なる。 transfer-coding = "chunked" | transfer-extension transfer-extension = token *( ";" parameter ) パラメータは、attribute/value ペアの形態を為す。 parameter = attribute "=" value attribute = token value = token | quoted-string すべての transfer-encoding 値は、大文字・小文字を区別しない。HTTP/1.1 では、TE ヘッダフィールド (section 14.39) と Transfer-Encoding ヘッダ フィールド (section 14.41) で転送コーディング値を使用している。 接続を閉じる事でメッセージの終了を示す場合以外に、転送コーディングが メッセージボディに適用される時は常に、転送コーディングのセットは "chunked" を含んでい *なければならない*。"chunked" 転送コーディングが 使われた時は、メッセージボディに適用される最後の転送コーディングにし *なければならない*。"chunked" 転送コーディングは、一度メッセージボデ ィに適用したら、それ以上適用し *てはならない*。これらのルールによっ て、受信者はメッセージの転送長さ (section 4.4) を決定できる。 転送エンコーディングは、MIME の Content-Transfer-Encoding 値 [7] と似 ていて、7-bit 転送サービス上でのバイナリデータの安全な転送を可能にす るために設計されている。しかし、完全な 8bit 転送プロトコルにおける安 全な転送とは異なる焦点を持つ。HTTP では、メッセージボディに特有の危険 さは、明確なボディ長 (section 7.2.2) を決定する事が困難な事や、共有さ れた転送経路上でデータの暗号化を望む、という事だけである。 Internet Assigned Numbers Authority (IANA) は、transfer-coding 値トー クンに対する登録を行なっている。初めに登録されているものには、以下の トークンが含まれる: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), "deflate" (section 3.5). (※) (※訳注) section 3.6.2 は、RFC 2616 中には存在しない。 新しい transfer-coding 値トークンは、新しい content-coding 値トークン と同様にして登録される *べきである* (section 3.5)。 理解できない transfer-coding を含むエンティティボディを受信したサーバ は、501 (Unimplemented) を返して接続を閉じる *べきである*。サーバは、 HTTP/1.0 クライアントに転送エンコーディングを送っ *てはならない*。 3.6.1 チャンク形式転送エンコーディング チャンク形式エンコーディングは、それぞれが自身のサイズ指標を持つ、一 連のチャンクと、エンティティヘッダフィールドを含む *オプショナルな* trailer を付加して転送するためにメッセージのボディを書き換える。 これによって、受信者が全メッセージを受信した事を確かめるために必要な 情報を、動的に生成された内容と一緒に転送できるようにする。 Chunked-Body = *chunk last-chunk trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF) chunk-size フィールドは、チャンクのサイズを示す 16 進数の数字列であ る。チャンク形式エンコーディングは、サイズが 0 のチャンクで終わり、空 行によって終わる物{trailer} が続く。 trailer では、送信者はメッセージの末尾に HTTP ヘッダフィールドを追加 できる。Trailer ヘッダフィールドは、trailer の中に含まれたヘッダフィ ールドを示すために使う事ができる。 レスポンスでチャンク形式転送コーディングを使うサーバは、以下のどれに も当てはまらなければ、ヘッダフィールドにおいて trailer を使っ *てはな らない*。 a)section 14.39 で示すように、"trailers" を表す TE ヘッダフィールドを 含むリクエストが、レスポンスの転送コーディングで受け入れ可能であ る。 b)そのサーバがレスポンスのオリジンサーバで、trailer フィールド全体が オプショナルなメタデータから成り、受信者はこのメタデータを受け入れ る事無しにその (マナーとしてオリジンサーバは受け入れ可能な) メッセ ージを使う事ができる。言い換えれば、オリジンサーバは、クライアント までの道のりの中で trailer フィールドが黙って廃棄されるかもしれない という可能性を受け入れる事を意図する。 この要求は、HTTP/1.1 (もしくはそれ以降) のプロクシがメッセージを受信 して、それを HTTP/1.0 の受信者に転送する時に、相互通信が失敗しないよ うにする。これは、もしかしたらプロクシに無限のバッファを送る必要があ るような規約を伴う承諾の場面を避ける。 Chunked-Body デコーディングのための例題過程は、付録の 19.4.6 で紹介さ れている。 すべての HTTP/1.1 アプリケーションは、"chunked" 転送コーディングを受 信しデコードでき *なければならない* し、理解できない転送コーディング 拡張は無視し *なければならない*。 3.7 メディアタイプ HTTP は、Content-Type (section 14.17) と Accept (section 14.1) ヘッダ フィールドにおいて、開放・拡張データタイプの決定やタイプネゴシエーシ ョンを供給するために Internet Media Type [17] を使用する。 media-type = type "/" subtype *( ";" parameter ) type = token subtype = token (section 3.6で定義されているように) attribute/value ペアの形態で、タ イプ／サブタイプがあり、その後にパラメータを置く事が *できる*。 タイプ、サブタイプ、パラメータ属性名は、大文字・小文字を区別しない。 しかし、パラメータ値は、パラメータ名のセマンティクスに依存するので、 大文字・小文字は区別されるかもしれない。連続した空白文字 (LWS: Linear white space) は、タイプとサブタイプの間や属性とその値の間で使われ *て はならない*。パラメータのある無しは、メディアタイプの定義に依存するの で、メディアタイプ決定のプロセスに重要なものとなるだろう。 古い HTTP アプリケーションの中には、メディアタイプパラメータを認識し ないものもある事に注意せよ。従って、インプリメンテーションが古い HTTP アプリケーションにデータを送る時は、タイプ／サブタイプ定義を要求した 場合に時のみ、メディアタイプパラメータを使用す *べきである*。 メディアタイプ値は、Internete Assigned Number Authority (IANA [19]) によって登録される。メディアタイプ登録手続きの方法は、RFC 1590 [17] において概説されている。登録されていないメディアタイプの使用は推奨さ れない。 3.7.1 公式化とテキストデフォルト インターネットメディアタイプは、公式の形式で登録される。HTTP メッセー ジ経由で転送されるエンティティボディは、次のパラグラフで定義されるよ うな "text" タイプを除けば、転送する前に、その適切な公式形式で表され *なければならない*。 公式形式では、"text" タイプのメディアサブタイプは、テキストの行末に CRLF を使う。HTTP では、エンティティボディ全体で一貫している場合は、 この要求をゆるめ、行末を表すのに単独の CR や LF をつけたテキストメデ ィアの転送を認めている。HTTP アプリケーションは、HTTP 経由で受信され るテキストメディアの行末表現として、CRLF, CR, LF を受け入れ *なければ ならない*。加えて、もしテキストが、幾つかのマルチバイト文字セットの 場合のように、CR と LF それぞれに対してオクテットの 13 と 10 が使われ ていないような文字セットで表現されているならば、HTTP は、行末の CR や LF と同等の表現をするための、その文字セットで定義されているどんなオク テットシーケンスの使用をも認める。行末に関するこの柔軟性は、エンティ ティボディ内のテキストメディアにのみ適用される。すなわち、(ヘッダフィ ールドやマルチパート境界等の) HTTP 制御構造では、いかなる単独の CR や LF も、CRLF に置き換え *てはならない*。 エンティティボディが内容エンコーディングでエンコードされている場合 は、根底のデータは、エンコードされる前には上で定義される形態をとって い *なければならない*。 "charset" パラメータは、データの文字セット (section 3.4) を定義するた めにいくつかのメディアタイプで使用されている。明示的な charset パラメ ータが送り側から供給されない時に、HTTP 経由で受信される "text" タイプ のメディアサブタイプは、デフォルトの charset である "ISO-8859-1" とい う値を持つと定義される。"ISO-8859-1" やそのサブセット以外の文字セット を使うデータは、適切な charset 値をラベル付け *なければならない*。互 換性の問題については section 3.4.1 参照。 3.7.2 マルチパートタイプ MIME は、一つのメッセージボディの中に複数のエンティティをカプセル化す る "multipart" タイプをいくつか供給する。すべてのマルチパートタイプは RFC 2046 [40] の section 5.1.1 で定義されているように、共通のシンタッ クスを共有し、メディアタイプ値の一部として境界パラメータ{boundary parameter} を含め *なければならない*。メッセージボディは、それ自身プ ロトコル要素の一部であり、それゆえに、body-parts 間の行末を表すために は CRLF のみを使用し *なければならない*。RFC 2046 と異なり、どのマル チパートメッセージのエピローグ{epilogue} も空でなければならない。その ため、HTTP アプリケーションは (たとえ元のマルチパートがエピローグを含 んでいても) エピローグを転送し *てはならない*。これらの制限は、最後の マルチパートの境界線によってメッセージボディの "終端" を示せるよう に、マルチパートのメッセージボディに自己限界性質{the self-delimiting nature} を持たせるために存在する。 一般的に、HTTP はマルチパートメッセージボディを他のメディアタイプとは 区別無く、すなわち単なる付加物{payload} として扱う。ただ一つ例外は、 206 (Partial Content) レスポンス中に現れる時の "multipart/byteranges" タイプ (appendix 19.2) であり、その場合 section 13.5.4 や section 14.16 で表されるような、いくつかの HTTP キャッシュメカニズムによって 解釈されるだろう。その他のすべての場合では、HTTP ユーザエージェント は、MIME ユーザエージェントがマルチパートタイプの受けとる時と同じ、ま たは似たような振る舞いをす *べきである*。マルチパートメッセージボディ の各々のボディ部分中の MIME ヘッダフィールドは、HTTP ではそれらの MIME セマンティクスによる定義以上にどんな意味も持たない。 一般的には、HTTP ユーザエージェントは、MIME ユーザエージェントがマル チパートタイプの受けとる時と同じ、または似たような振る舞いをす *べき である*。アプリケーションが認識できないマルチパートサブタイプを受け取 った場合は、それを "multipart/mixed" に相当するものとして扱わ *なけれ ばならない*。 注意: "multipart/form-data" タイプは、RFC 1867 [15] で表されるよう に、特に POST リクエストメソッド経由で処理するのに合ったフォームデ ータを転送するために特別に定義されている。 3.8 製品トークン 製品トークンは、ソフトウェアの名前とバージョンによってその製品である 事を識別するアプリケーションと通信する事ができるようにするために使わ れる。製品トークンで使用されるほとんどのフィールドは、アプリケーショ ンの重要な部分を形成する部分製品{sub-product} を空白で区切るように列 挙できるようになっている。慣習では、製品はそのアプリケーションを識別 するために重要なものの順に列挙される。 product = token ["/" product-version] product-version = token 例を見よ。 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4 製品トークンは短く要点のみである *べきである*。宣伝や別の本質的でない 情報のために使用し *てはならない*。製品バージョンにはあらゆるトークン 文字を使用 *できる* が、このトークンはバージョン識別子に対してのみ使 われる *べきである*。(例えば、同じ製品の連続したバージョンは、製品値 の製品バージョン部分のみが異なる *べきである*)。 3.9 品質値 HTTP 内容ネゴシエーション (section 12) は、さまざまなネゴシエート可能 なパラメータの相対な重要性 ("ウェイト") を示すために短い "浮動小数点" 数を使う。ウェイトは、0 から 1 までの実数値と標準化され、0 は最小値で 1 は最大値である。もしパラメータが 0 の品質値を持っていたら、そのパラ メータと共にあるものはクライアントは「利用不可能」である。HTTP/1.1 ア プリケーションは、小数点以下で三桁を越える数字を生成し *てはならな い*。これらの値のユーザ設定も、この様式にかぎられる *べきである*。 qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] ) "品質値" とは、単に要請される特質の相対的な格付けを示すものなので、実 際は誤った表現である。 3.10 言語タグ 言語タグは、他の人間との情報のコミュニケーションのため、人間によって 話され、書かれ、あるいは別の方法で伝えられる自然言語を識別する。コン ピュータ言語は完全に除外される。HTTP では、Accept-Language や Content-Language 各フィールドにおいて言語タグを使用する。 HTTP言語タグのシンタックスや登録は、RFC 1766 [1] で定義されたものと同 じである。要約すると、言語タグは、第1の言語タグと空の可能性のあるサブ タグのいくつかから成る。 language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA ホワイトスペースはタグの中では認められず、すべてのタグで大文字・小文 字を区別しない。言語タグの名前空間は IANA によって管理されている。例 えば、言語タグには以下のような物がは含まれる。 en, en-US, en-cockney, i-cherokee, x-pig-latin 第一タグの二文字は、ISO-639 の言語短縮形であり、サブタグの最初の二文 字は、ISO-3166 カントリーコードである。(上記の後の三タグは登録されて いないタグである。しかし、すべて将来は登録されるかもしれないタグの例 である。) 3.11 エンティティタグ エンティティタグは、同一の要求リソースからの二つ以上のエンティティを 比較するために使用される。HTTP/1.1 では、ETag (section 14.19), If- Match (section 14.24), If-None-Match (section 14.26), If-Range (section 14.27) 各ヘッダフィールドで、エンティティタグを使う。それら がキャッシュバリディタとして、どのよう使われ、比較されるかの定義は、 section 13.3.3 にある。エンティティタグは、引用符で囲まれた opaque 文 字列から成り、weakness インジケータが前方に付く場合もある。 entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string "strong entity tag" では、もしそれらがオクテット文字によって同等の場 合にのみ、リソースの二つのエンティティが共有 *できる*。 "W/" プレフィクスによって示される "weak entity tag" では、エンティテ ィが等価であり、セマンティクスにおいてそれぞれ重要な変更がなく互いを 代わりに使う事ができる場合のみ、リソースの二つのエンティティが共有 *できる*。weak エンティティタグは、弱い比較の時のみ使用される。 エンティティタグは、特有のリソースと関連付けられたすべてのエンティテ ィのすべてのバージョンの中でユニークで *なければならない*。与えられた エンティティタグの値は、異なる URI へのリクエストから得られたエンティ ティのために使う事が *できる*。異なる URI へのリクエストから得られた エンティティに同じエンティティタグの値を使っているからといって、それ らのエンティティの同等性を暗に意味するものではない。 3.12 レンジ単位 HTTP/1.1 では、クライアントはレスポンス内に含まれるレスポンスエンティ ティの (範囲の) 一部だけを要求できる。HTTP/1.1 は、Range (section 14.35) と Content-Range (section 14.16) 各ヘッダフィールドにおいてレ ンジ単位を使用する。エンティティは、さまざまな構造上の単位に従ったサ ブレンジへと分解されるだろう。 range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = token HTTP/1.1 で定義されている唯一のレンジ単位は、"bytes" である。HTTP/1.1 インプリメンテーションは、別の単位を使って指定されたレンジは無視する 事が *できる*。 HTTP/1.1 では、アプリケーションの実装がレンジについての知識に依存しな いという事が認められる様に設計されている。 4 HTTP メッセージ 4.1 メッセージタイプ HTTPメッセージは、クライアントからサーバへのリクエストと、サーバから クライアントへのレスポンスから成る。 HTTP-message = Request | Response ; HTTP/1.1 messages リクエスト (section 5) と レスポンス (section 6) 各メッセージは、エン ティティ (メッセージの付加物) を転送するために RFC 822 [9] の一般的な メッセージフォーマットを使用する。両タイプとも、開始行、0 以上のヘッ ダフィールド ("headers"として知られているもの)、ヘッダフィールドの終 了を示す (CRLF の前に何もない行のような) 空行、そして任意のメッセージ ボディからなる。 generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-Line 強い関心を持って、サーバは、Request-Line である事が期待できる位置で受 け取った空行はいかなるものも無視す *べきである*。言いかえれば、サーバ が、メッセージの開始地点からプロトコルストリームで読み出しを行って、 最初に CRLF を受信した場合、その CRLF は無視すべきである。 バグを持つ HTTP/1.0 クライアントインプリメンテーションの中には、POST リクエストの後に余計な CRLF を生成するものもある。BNF によって明示的 に禁止される事を再述すれば、HTTP/1.1 クライアントはリクエストの際に 余計 CRLF を前にも後ろにもつけ *てはならない*。 4.2 メッセージヘッダ 一般ヘッダ (section 4.5)、リクエストヘッダ (section 5.3)、レスポンス ヘッダ (section 6.2)、エンティティヘッダ (section 7.1) 各フィールドを 含む HTTP ヘッダフィールドは、RFC 822 [9] の Section 3.1 で与えられて いるものと同じである共通のフォーマットに従う。それぞれのヘッダフィー ルドは、名前、その後にコロン(":")、そしてフィールド値から成る。フィー ルド名は、大文字・小文字を区別しない。フィールド値には、いくつもの LWS を先行させる事が *できる* が、SP 一つだけが好ましい。ヘッダフィー ルドは、一つ以上の SP や HT をそれぞれの行頭につける事で複数行にまた がる事ができる。アプリケーションが HTTP 構造を生成する時には、"共通形 式" を超えたものは受け入れられないインプリメンテーションがいくつか存 在するであろう事を考慮し、知られている、あるいは示されている "共通形 式"に従うべきである。 message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = field-content は、LWS を前にも後ろにも、すなわち field-value の最初の 空白以外の文字の前にも、あるいは field-value の最後の空白以外の文字の 後ろにも、空行を含まない。そのような前後の LWS は、フィールド値のセマ ンティクスを変える事無く削除される *であろう*。field-content の間のい かなる LWS もフィールド値に解釈されたり、下流{downstream} に転送され る前に単なる SP に置き換えられる *であろう*。 異なるフィールド名を持つヘッダフィールドが受信される順序は、重要では ない。しかしながら、最初に一般ヘッダフィールド、その後にリクエストヘ ッダやレスポンスヘッダ、そして最後にエンティティフィールドを送る事が "良い習慣" である。 同じフィールド名を持つ複数のメッセージヘッダフィールドは、そのヘッダ フィールドの全体のフィールド値が [例えば、#(value) のように] コンマで 区切られたリストとして定義される場合にのみ、メッセージに存在 *でき る*。そしてそれら複数のヘッダフィールドは、最初の field-value に、コ ンマによって分けられたそれぞれの field-value を追加する事で、メッセー ジのセマンティクスを変える事無く、一つの "header-name: header-value" ペアに結合でき *なければならない*。それゆえ、同じフィールド名のヘッダ フィールドが受信される順番は、連結されたフィールド値の中間処理のため に重要なので、プロクシはメッセージを転送する時にはそれらのヘッダ値の 順番を変え *てはならない*。 4.3 メッセージボディ HTTPメッセージにメッセージボディがあったとしたら、それはリクエストや レスポンスに関連するエンティティボディを運ぶために使われる。メッセー ジボディは、Transfer-Encoding ヘッダフィールド (section 14.41) によっ て示されるように、転送コーディングが適用された場合のみ、エンティティ ボディとは異なる。 message-body = entity-body | Transfer-Encoding は、メッセージの安全かつ適切な転送を保障するアプリ ケーションによって、適用されるすべての転送コーディングを示すために使 われ *なければならない*。Transfer-Encoding は、メッセージの性質であ り、エンティティの性質ではないので、リクエスト／レスポンス連鎖に関わ るあらゆるアプリケーションによって追加されたり削除されたり *されう る*。(しかしながら、確実に転送コーディングが用いられているであろう時 のために、section 3.6 にて制限を設けている。) メッセージボディがメッセージにおいて認められるルールは、リクエストと レスポンスで異なる。 リクエストにおけるメッセージボディの存在は、リクエスト時にメッセージ ヘッダに Content-Length や Transfer-Encoding 各ヘッダフィールドを含む 事によって伝えられる。リクエスト時に、もし使用するリクエストメソッド (section 5.1.1) の定義で、リクエスト時にエンティティボディを送信する 事を許可していなければ、メッセージボディをリクエストに含ん *ではなら ない*。サーバは、どんなリクエストでもメッセージボディを読んで転送す *べきである*。すなわち、もしリクエストメソッドがエンティティボディに ついて定義されたセマンティクスを含んでいなければ、そのメッセージボデ ィはリクエストを処理した時に無視する *べきである*。 レスポンスメッセージでは、メッセージボディがメッセージに含まれている かどうかは、リクエストメソッドとレスポンスステータスコード (section 6.1.1) の両方に依存する。HEAD リクエストメソッドへのレスポンスは、た とえそこに含まれるエンティティヘッダフィールドがそうするようにあった としても、いかなる場合もメッセージボディを含ん *ではならない*。1xx (Information)、204 (no content)、304 (not modified) レスポンスでは、 すべてメッセージボディを含ん *ではならない*。その他のレスポンスでは、 その長さはゼロである *かもしれない* が、すべてメッセージボディを含ん でいる。 4.4 メッセージの長さ メッセージの転送長さ{transfer-length} は、それがメッセージの中に現れ た時、つまりある転送コーディングが適用された後のメッセージボディの長 さである。メッセージボディがメッセージに含まれる時、そのボディの転送 長さは以下のうちのどれかで決定される (優先順位順)。 1.メッセージボディを含ん "*ではならない*" (1xx, 204, 304 レスポンスや HEAD リクエストに対するすべてのレスポンス) レスポンスメッセージは、 メッセージ中にエンティティヘッダフィールドがあるか無いかに関わら ず、常にヘッダフィールドの後の最初の空行で終了する。 2.もし、Transfer-Encoding ヘッダフィールド (section 14.41) があり、 "identity" 以外の値を持っていて、接続を閉じる事でメッセージが終了し ているのでなければ、転送長さは "chunked" エンコーディング (section 3.6) の使用によって定義される。 3.もし、Content-Length ヘッダフィールド(section 14.14) があれば、その オクテット中の10進数の値は、エンティティ長さ{entity-length} と転送 長さを表す。もしそれら二つの長さが違うのならば、Content-Length ヘッ ダフィールドを送っ *てはならない* (例えば、Transfer-Encoding がある 場合)。もし、メッセージが Transfer-Encoding ヘッダフィールドと Content-Length ヘッダフィールドとを一緒に送ってきたならば、後者は無 視し *なければならない*。 4.もし、メッセージがメディアタイプ "multipart/byteranges" を使い、そ の転送長さが別の方法で特定できなければ、自身で区切りを持つこのメデ ィアタイプは、その転送長さを定義する。送信者は、受信者がこのメディ アタイプを解析できる事という事を知らないのでならば、使っ *てはなら ない*。リクエスト時の複数のバイトレンジを持つ Range ヘッダの存在 は、クライアントが multipart/byterange レスポンスを解析できる事を暗 黙的に意味する。 multipart/byterange を理解しない HTTP/1.0 プロクシは、Range ヘッ ダを転送するだろう。この場合、サーバはこの章で定義されているうち の 1, 3, 5 の項目のいずれかの方法を使って、このメッセージを制御し *なければならない*。 5.接続を閉じるサーバによる。(サーバがレスポンスを送り返す可能性がある 事を捨て置けないので、リクエストボディの終了を示すために接続を閉じ じるという方法は、使えない。) HTTP/1.0 アプリケーションへの互換性のため、メッセージボディを含む HTTP/1.1 リクエストは、もしサーバが HTTP/1.1 に準じている事を知らなけ れば、適した Content-Length ヘッダフィールドを含ま *なければならな い*。もし、リクエストがメッセージボディを含んでいて、Content-Length を含んでいなかったら、サーバは、それによってメッセージの長さが決定で きない場合は 400 (bad request) を、有効な Content-Length を受けとりた い場合は 411 (length required) を、それぞれ返す *べきである*。 エンティティを受け取るすべての HTTP/1.1 アプリケーションは、"chunked" 転送エンコーディング (section 3.6) を受け入れられ *なければならない* ので、メッセージ長が前もって決定できない時には、このメカニズムをメッ セージに対して使う事が認められる。 メッセージには、Content-Length ヘッダフィールドと identity でない転送 コーディングの両方を含ん *ではならない*。メッセージが、identity でな い転送コーディングを含んでいたら、Content-Length は無視され *なければ ならない*。 メッセージボディが認められるメッセージにて Content-Length が与えられ る時には、そのフィールド値はメッセージボディにおけるオクテットの数と 正確に一致し *なければならない*。HTTP/1.1 ユーザエージェントは、不正 な長さが受信されたり検出された時には、それをユーザに通知し *なければ ならない*。 4.5 一般ヘッダフィールド リクエストとレスポンスの両メッセージで、一般的な適用性を持つが、転送 されたエンティティには適用されないヘッダがいくつかある。これらのヘッ ダフィールドは、伝えられているメッセージに対してのみ適用する。 general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.18 | Pragma ; Section 14.32 | Trailer ; Section 14.40 | Transfer-Encoding ; Section 14.41 | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 一般ヘッダフィールド名は、プロトコルバージョンの変化に伴う連動におい てのみ確実に拡張されうる。しかしながら、新しい、あるいは実験的なヘッ ダフィールドは、もしそのコミュニケーションでのすべてのパーティがそれ らを一般ヘッダフィールドであると認識できるなら、一般的なヘッダフィー ルドのセマンティクスを与えてもよい。認識されないヘッダフィールドは、 エンティティヘッダフィールドとして扱われる。 5 リクエスト クライアントからサーバへのリクエストメッセージには、リソースに適用さ れるメソッド、リソースの識別子、使用するプロトコルのバージョンが最初 の行に含まれる。 Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3 5.1 リクエストライン リクエストラインは、メソッドトークンに始まり、 Request-URI とプロトコ ルバージョンが後に続き、CRLF で終了する。要素は SP によって分けられ る。最後の CRLF シーケンス以外には、CR も LF も許されない。 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 5.1.1 メソッド メソッドトークンは、 Request-URI により識別されるリソースに働きかける ためのメソッドを示す。メソッドは大文字・小文字を区別する。 Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | "CONNECT" ; Section 9.9 | extension-method extension-method = token リソースにより認められるメソッドのリストは、Allow ヘッダフィールド (section 14.7) により示される。許されるメソッドのセットは動的に変化で きるため、レスポンスのリターンコードはそのメソッドが現在リソースに許 されているかどうかにかかわらず、常にクライアントに通知される。オリジ ンサーバは、メソッドを理解できても要求されたリソースに対して許されて いない場合は、ステータスコード 405 (Method Not Allowed) を返す *べき であり*、またオリジンサーバがそのメソッドを認識できなかったり実装され ていない場合には 501 (Not Implemented) を返す *べきである*。すべての 一般目的サーバ{general-purpose servers} では、GET とHEAD メソッドは、 サポートしてい *なければならない*。他のすべてのメソッドは *オプショナ ル* であるが、もし上記のメソッドが実装されるなら、それらは section 9 で記述されているものと同じセマンティクスで実装されなければならない。 5.1.2 Request-URI Request-URI は、Uniform Resource Identifier (section 3.2) であり、リ クエストを適用するリソースを識別する。 Request-URI = "*" | absoluteURI | abs_path | authority Request-URI の四つのオプションは、そのリクエストの性質に依存する。ア スタリスク "*" は、そのリクエストが特有のリソースではなく、サーバ自身 に適用するという事を意味し、使われているメソッドがリソースに適用され る必要がないときにのみ許される。一例を挙げる。 OPTIONS * HTTP/1.1 absoluteURI 形式は、リクエストがプロクシに対して生成されている時に *要求される*。プロクシは、そのリクエストを転送するか、有効なキャッシ ュ内から提供する時に呼び出され、レスポンスを返す。プロクシは、そのリ クエストを別のプロクシか、あるいは absoluteURI によって特定されたサー バに直接送る事が *できる* 事に注意せよ。リクエストループを避けるため に、プロクシはそのサーバ名をエイリアス、ローカルバリエーション、数値 IP アドレスまで含め、すべて理解でき *なければならない*。Request-Line の例は以下の様になる。 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 HTTP の将来のバージョンにおいてすべてのリクエストが absoluteURI へ移 行する事ができるように、例え HTTP/1.1 クライアントはプロクシへのリク エストとしてのみしか生成しないものであったとしても、全ての HTTP/1.1 サーバはリクエストにおける absoluteURI 形式を受け入れ *なければならな い*。 authority 形式は、CONNECT メソッド (section 9.9) のみで使用する。 Request-URI の最も一般的な形式は、オリジンサーバやゲートウェイ上の リソースを識別するために使用される事である。この場合、URI の絶対パス は Request-URI として通信され *なければならない* (section 3.2.1, abs_path 参照) し、URI のネットワークロケーション(authority) は、Host ヘッダフィールドにおいて転送され *なければならない*。例えば、オリジン サーバから直接上記のリソースを回収する事を望むクライアントは、ホスト "www.w3.org" のポート 80 に TCP 接続を確立し、その行を送る。 GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org 残りのリクエストをその後に送る。絶対パスは空ではない事に注意せよ。も し、元の URI で何も与えられていなければ、それは "/" (サーバのルート) が与えられ *なければならない*。 Request-URI は、section 3.2.1 に記された形式で送られる。もし、 Request-URI に "% HEX HEX" エンコード [42] が使用されていたら、オリジ ンサーバはそのリクエストを適切に解釈するためにその Request-URI をデコ ードし *なければならない*。サーバは、不正な Request-URI には、適切な ステータスコードをもって応答す *べきである*。 透過的プロクシは、上で記した空の{null} abs_path を "/" に置き換えると いう場合以外は、次のインバウンドサーバに転送する時に、受け取った Request-URI の "abs_path" の一部を書き換え *てはならない*。 注意: "書き換え禁止" という規則は、オリジンサーバが予約された目的 のための予約されていない URL 文字を不適当に使用している時に、プロ クシがリクエストの意味を変えないようにする狙いがある。実装者は、い くつかの HTTP/1.1 以前のプロクシが Request-URI を書き換える事が知 られている、という事を認識すべきである。 5.2 リクエストによって識別されるリソース インターネットリクエストにより識別された正確なリソースは、Request-URI と Host ヘッダフィールドの両方で調べる事で決定される。 HTTP/1.1 リクエストによってリソースを決定する時、リクエストされたホス トによってリソースが異なるという事を認めていないオリジンサーバは、 Host ヘッダフィールド値を無視するで *あろう*。(但し、HTTP/1.1 での Host をサポートする別の必要条件について section 19.6.1.1 参照。) リクエストされたホストに基づいてリソースを区別する (しばしば仮想ホス トや空虚{vanity} なホスト名として参照される) オリジンサーバは、 HTTP/1.1 リクエストで要求されたリソースを決定するために以下のルールを 使わ *なければならない*。 1.もし、Request-URI が absoluteURI ならば、ホストは Request-URI の一 部である。リクエストにおけるどんな Host ヘッダフィールド値も無視さ れ *なければならない*。 2.もし、Request-URI が absoluteURI でなく、リクエストが Host ヘッダフ ィールドを含んでいるならば、ホストは Host ヘッダフィールド値によっ て決定される。 3.もし、規則 1 や 2 で決定されるようなホストがそのサーバで正当なホス トでないならば、レスポンスは 400 (Bad Request) エラーメッセージで *なければならない*。 Host ヘッダフィールドが無い HTTP/1.0 リクエストを受信した者は、要求さ れたリソースがどれほど正確な要求されているかを決定するため (例えば、 特定のホストのユニークな何かに対する URI パスの試験のような) 発見方法 を試す事が *できる*。 5.3 リクエストヘッダフィールド リクエストヘッダフィールドを用いて、クライアントはサーバにリクエスト やクライアント自身に関する追加的な情報を渡す事ができる。これらのフィ ールドは、メソッド発動{invocation} プログラミング言語におけるパラメー タと同等なセマンティクスを持つ、リクエスト修飾子として動作する。 request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization ; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 | If-Match ; Section 14.24 | If-Modified-Since ; Section 14.25 | If-None-Match ; Section 14.26 | If-Range ; Section 14.27 | If-Unmodified-Since ; Section 14.28 | Max-Forwards ; Section 14.31 | Proxy-Authorization ; Section 14.34 | Range ; Section 14.35 | Referer ; Section 14.36 | TE ; Section 14.39 | User-Agent ; Section 14.43 リクエストヘッダフィールド名は、プロトコルバージョンの変化に伴っての み確実に拡張されうる。しかしながら、新しい、あるいは実験的なヘッダフ ィールドは、もしそのコミュニケーションでのすべてのパーティがそれらを リクエストヘッダフィールドであると認識できるなら、一般的なヘッダフィ ールドのセマンティクスを与えても *よい*。認識されないヘッダフィールド は、エンティティヘッダフィールドとして扱われる。 6 レスポンス リクエストメッセージを受信・解釈した後、サーバは HTTP レスポンスメッ セージを返す。 Response = Status-Line ; Section 6.1 *(( general-header ; Section 4.5 | response-header ; Section 6.2 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 7.2 6.1 ステータスライン レスポンスメッセージの最初の行は、プロトコルのバージョン、ステータス コード番号、それに関連したテキストフレーズからなるステータスライン で、それぞれの要素は、SP によって分けられる。最後の CRLF シーケンス以 外には、CR も LF も許されない。 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 6.1.1 ステータスコードと説明句 ステータスコード要素とは、リクエストを理解し満足するための試行につい ての三桁の数字による結果コードである。これらのコードは、section 10 に て完全に定義されている。説明句は、ステータスコードについて短いテキス ト記述を与える目的を持つ。ステータスコードは自動処理によって、また説 明句は人間によってそれぞれ使われる事を意図している。クライアントは、 説明句を調べたり表示したりする必要はない。 ステータスコードの最初の数字はレスポンスのクラスを定義する。後ろの二 つの数字はどんな分類ルールも持たない。最初の数字には五つの値がある。 - 1xx: Informational - リクエストは受け入れられ、処理を続けている - 2xx: Success - 動作は正常に受信され、理解され、受け入れられた - 3xx: Redirection - リクエストを完了するためには、さらに動作を行 わなければならない - 4xx: Client Error - リクエストは間違った構文か、果たす事のできな いものを含んでいる - 5xx: Server Error - サーバは明らかに正当なリクエストを果たすのに 失敗した HTTP/1.1 で定義された個々のステータスコード数値、及びそれに相当する説 明句のセットの例の値を以下に示す。ここでリストされた説明句は推奨に過 ぎない。すなわち、これらはプロトコルに影響が出ないローカルな範囲で、 それに相当するものに置き換えても *よい*。 Status-Code = "100" ; Section 10.1.1: Continue | "101" ; Section 10.1.2: Switching Protocols | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created | "202" ; Section 10.2.3: Accepted | "203" ; Section 10.2.4: Non-Authoritative Information | "204" ; Section 10.2.5: No Content | "205" ; Section 10.2.6: Reset Content | "206" ; Section 10.2.7: Partial Content | "300" ; Section 10.3.1: Multiple Choices | "301" ; Section 10.3.2: Moved Permanently | "302" ; Section 10.3.3: Found | "303" ; Section 10.3.4: See Other | "304" ; Section 10.3.5: Not Modified | "305" ; Section 10.3.6: Use Proxy | "307" ; Section 10.3.8: Temporary Redirect | "400" ; Section 10.4.1: Bad Request | "401" ; Section 10.4.2: Unauthorized | "402" ; Section 10.4.3: Payment Required | "403" ; Section 10.4.4: Forbidden | "404" ; Section 10.4.5: Not Found | "405" ; Section 10.4.6: Method Not Allowed | "406" ; Section 10.4.7: Not Acceptable | "407" ; Section 10.4.8: Proxy Authentication Required | "408" ; Section 10.4.9: Request Time-out | "409" ; Section 10.4.10: Conflict | "410" ; Section 10.4.11: Gone | "411" ; Section 10.4.12: Length Required | "412" ; Section 10.4.13: Precondition Failed | "413" ; Section 10.4.14: Request Entity Too Large | "414" ; Section 10.4.15: Request-URI Too Large | "415" ; Section 10.4.16: Unsupported Media Type | "416" ; Section 10.4.17: Requested range not satisfiable | "417" ; Section 10.4.18: Expectation Failed | "500" ; Section 10.5.1: Internal Server Error | "501" ; Section 10.5.2: Not Implemented | "502" ; Section 10.5.3: Bad Gateway | "503" ; Section 10.5.4: Service Unavailable | "504" ; Section 10.5.5: Gateway Time-out | "505" ; Section 10.5.6: HTTP Version not supported | extension-code extension-code = 3DIGIT Reason-Phrase = * HTTP ステータスコードは拡張可能である。HTTP アプリケーションは、登録 されたすべてのステータスコードを明確に理解できる事が望ましいが、それ らのすべての意味を理解する必要はない。しかし、アプリケーションは最初 の数字によって示されるステータスコードのクラスはすべて理解し *なけれ ばならない* し、理解できないレスポンスはキャッシュし *てはならない* という例外を除いて、すべての理解できないレスポンスをそのクラスの x00 ステータスコードと同等に扱わ *なければならない*。例えば、431 という 理解できないステータスコードがクライアントに受信されたなら、そのリク エストに何か誤りがあると安全に推測ができ、それが 400 ステータスコード を受信したかのようにレスポンスを扱う事ができる。このような場合、エン ティティはこの異常なステータスを説明しているであろう人間が読める情報 を含んでいると思われるから、ユーザエージェントはレスポンスと共に返さ れたエンティティをユーザに見せる *べきである*。 6.2 レスポンスヘッダフィールド レスポンスヘッダフィールドを用いて、サーバはステータスラインに置けな いレスポンスに関する追加的な情報を渡す事ができる。これらのヘッダフィ ールドは、サーバについてや、Request-URI によって識別されるリソースへ の更なるアクセスに関する情報を与える。 response-header = Accept-Ranges ; Section 14.5 | Age ; Section 14.6 | ETag ; Section 14.19 | Location ; Section 14.30 | Proxy-Authenticate ; Section 14.33 | Retry-After ; Section 14.37 | Server ; Section 14.38 | Vary ; Section 14.44 | WWW-Authenticate ; Section 14.47 レスポンスヘッダフィールド名は、プロトコルバージョンの変化に伴っての み確実に拡張されうる。しかしながら、新しい、あるいは実験的なヘッダフ ィールドは、もしそのコミュニケーションでのすべてのパーティがそれらを レスポンスヘッダフィールドであると認識できるなら、一般的なヘッダフィ ールドのセマンティクスを与えても *よい*。認識されないヘッダフィールド は、エンティティヘッダフィールドとして扱われる。 7 エンティティ リクエストやレスポンスでのメッセージは、リクエストメソッドやレスポン スステータスコードによって規制されていなければ、エンティティを転送す る事が *できる*。エンティティは、エンティティヘッダフィールドとエンテ ィティボディから成るが、エンティティヘッダのみを含むレスポンスもあ る。 この章においては、送信者と受信者の両方がクライアントかサーバのどちら かを表すが、それはエンティティを送信するか受信するかに依存する。 7.1 エンティティヘッダフィールド エンティティヘッダフィールドは、エンティティボディや、もしボディが無 ければリクエストによって識別されたリソースについての外部情報を定義す る。この外部情報は、*オプションナル* なものもあるが、この仕様書の中で *要求している* ものもある。 entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Range ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header 拡張ヘッダメカニズムは、プロトコルを変更する事無く追加的エンティティ ヘッダフィールドを定義できるようにしているが、これらのフィールドが受 信者によって認識されるという事は仮定できない。認識されないヘッダフィ ールドは、受信者によって無視される *べきであり*、透過的プロクシによっ て転送され *なければならない*。 7.2 エンティティボディ もし、HTTP リクエストやレスポンスと共にエンティティボディが送られてき たら、それはエンティティヘッダフィールドによって定義されるフォーマッ トをもってエンコーディングされている。 entity-body = *OCTET エンティティボディは、section 4.3 に記されるように、メッセージボディ がある時のみ、メッセージの中に存在する。エンティティボディは、メッセ ージの安全かつ適切な転送を保証するために適用されるであろうあらゆる転 送エンコーディングをデコードする事によってメッセージボディから得られ る。 7.2.1 タイプ エンティティボディがメッセージに含まれる時、このボディのデータタイプ は Content-Type と Content-Encoding 各ヘッダフィールドによって決定さ れる。これらは、2層の順列エンコーディングモデル {ordered encoding model} を定義する。 entity-body := Content-Encoding( Content-Type( data ) ) Content-Type は、元のデータのメディアタイプを示す。Content-Encoding は、要求されたリソースが持つデータを、通常はデータ圧縮という目的のた めに適用されるあらゆる追加的な内容コーディングを示すために使われるで あろう。デフォルトのエンコーディングはない。 エンティティボディを含む HTTP/1.1 メッセージは、いつでもそのボディの メディアタイプを定義するための Content-Type ヘッダフィールドを含む *べきである*。メディアタイプが Content-Type ヘッダによって与えられな い場合に限り、受信者はリソースの内容の検査や、あるいはリソースを識別 するために使用されている URI の名前拡張子を調べる事によってメディアタ イプを推測してみても *よい*。もしメディアタイプが分からないままであっ たら、受信者はそれをタイプ "application/octet-stream" として扱う *べ きである*。 7.2.2 エンティティ長 メッセージのエンティティボディ長は、あらゆる転送エンコーディングが適 用される前のメッセージボディの長さである。section 4.4 では、どのよう にメッセージボディの転送長さが決められているかを定義している。 8 接続 8.1 持続的接続 8.1.1 目的 持続的接続が無い時代には、別々の URL からリソースを取得するために、そ れぞれで TCP 接続を確立していたため、サーバのロードを増加させ、インタ ーネットの混雑を引き起こす原因になっていた。インラインイメージやその 他の関連するデータの使用のために、クライアントはしばしば短時間に同じ サーバへ複数のリクエストを行う必要がある。これらのパフォーマンスの問 題の解析や持続的接続のプロトタイプの実装から得られた結果については、 現在入手可能である [26] [30]。持続的接続を実装する過程で得た経験や、 実際に HTTP/1.1 (RFC 2068) を実装したものを測定した所、良い結果が得ら れた [39]。また一方で、例えば T/TCP [27] のような、違う選択肢も研究さ れてきている。 持続的 HTTP 接続には、いくつかの利点がある。 - TCP コネクションの開閉が少なくなる事で、ルータやホスト (クライア ント、サーバ、プロクシ、ゲートウェイ、トンネル、キャッシュ) にお ける CPU 時間は節約され、TCP プロトコルコントロールブロックのた めに使用されるメモリも節約される。 - HTTP リクエストとレスポンスは、接続上でパイプライン化する事がで きる。パイプライン化によって、クライアントは、各々のレスポンスを 待つ事なく複数のリクエストを行う事ができ、また一つの TCP 接続を より少ない経過時間で、より効果的に使用できる。 - TCP のオープンや、TCP sufficient time にネットワークの混雑状況を 決定させるために使われるパケットの数の減少によって、ネットワーク における混雑は減少される。 - TCP 接続がすでに確立しているので、次回リクエスト時にはそのための 時間が必要無く、リクエストへの反応時間は短縮される。 - TCP 接続を閉じるという罰則無しにエラーを報告できるため、HTTP は より上品に発展する。もし古いサーバと通信するとしても、HTTP の将 来のバージョンを使用するクライアントは、楽天的に新しい機能を試み る事ができ、エラー報告の後には古いセマンティクスが伴う再試行も報 告されるであろう。 HTTP インプリメンテーションは持続的接続を実装す *べきである*。 8.1.2 全体の動作 HTTP/1.1 と HTTP のそれ以前のバージョンとの重要な違いは、すべての HTTP 接続において持続的な接続がデフォルトの動作であるかどうかという事 である。すなわち、何か別の方法が示されない限り、クライアントは、例え サーバからエラーレスポンスが返されても、サーバが持続的接続を維持する であろうと仮定す *べきである*。 持続的接続は、クライアントとサーバが TCP 接続を閉じる時に合図を行える というメカニズムを提供する。この合図は、Connection ヘッダフィールド (section 14.10) を用いて示す。一度接続を閉じる事が示されたら、クライ アントはその接続でそれ以上のリクエストを送っ *てはならない*。 8.1.2.1 ネゴシエーション HTTP/1.1 サーバは、HTTP/1.1 クライアントがリクエスト中に "close" とい う connection-token を含んでいる Connection ヘッダを送られなければ、 持続的接続を維持するつもりである事を想定しても *よい*。もし、サーバが レスポンスを送信した後すぐに接続を閉じる事を選ぶのであれば、 connection-token に close を含んでいる Connection ヘッダを送信す *べ きである*。 HTTP/1.1 クライアントは、接続が開いたままである事を期待しても *よい* が、サーバからのレスポンスが connection-token が close である Connection ヘッダを含んでいるかどうかに基づいて回線の維持についてを決 めるであろう。クライアントがそのリクエスト以上に接続を維持する事を望 まない場合は、connection-token に close を含む Connection ヘッダを送 る *べきである*。 もし、クライアントかサーバのどちらかが、Connection ヘッダにおいて close トークンを送ったならば、そのリクエストはその接続に対する最後の ものとなる。 クライアントやサーバは、それが明確に合図された場合以外は、1.1 よりも 低い HTTP のバージョンにおいては、持続的接続が維持されていると仮定す *べきではない*。HTTP/1.0 クライアントとの下位互換性に必要な情報につい ては section 19.6.2 参照。 持続性を維持するために、接続上のすべてのメッセージは section 4.4 で定 義されているように、自身で定義した (例えばそれが接続の閉鎖によって定 義されるようなものではない) メッセージ長さを持た *なければならない*。 8.1.2.2 パイプライン化 持続的接続をサポートするクライアントは、そのリクエストを "パイプライ ン" する事が *できる* (例えば、複数のレスポンスを待つ事無く、複数のリ クエストを送る)。サーバは、リクエストが受信されたのと同じ順番で、それ らのリクエストのレスポンスを返さ *なければならない*。 持続的接続を想定し、接続確立の後にすぐパイプラインを行うクライアント は、もし最初のパイプライン化への試行が失敗した場合は、それらの接続を 再試行する準備をす *べきである*。クライアントがそのような再試行を行う 場合は、その接続が持続的であると分かるまではパイプラインを行っ *ては ならない*。もし、サーバがすべての通信のレスポンスを返す前に接続を閉 じてしまったら、クライアントはそれらのリクエストを再送信する準備をし *なければならない*。 クライアントは、等冪でない{non-idempotent} メソッド、あるいはメソッド のシーケンスを使ったリクエストをパイプラインす *べきではない* (section 9.1.2 参照)。そうでなければ、転送接続の早過ぎる終了が不確定 な結果を招く事になるだろう。等冪でないリクエストを送ろうとするクライ アントは、前のリクエストのレスポンスステータスを受け取るまでリクエス トを送る事を待つ *べきである*。 8.1.3 プロクシサーバ プロクシが section 14.10 で指定されるように Connection ヘッダの機能を 正確に実装する事は特に重要である。 プロクシサーバは、自身が接続しているクライアントとオリジンサーバ (あ るいは別のプロクシサーバ) のそれぞれに持続的接続を知らせ *なければな らない*。それぞれの持続的接続は、一つの転送リンクのみで適用される。 プロクシサーバは、HTTP/1.0 クライアントと HTTP/1.1 の持続的接続を確立 し *てはならない* (但し、多くの HTTP/1.0 クライアントに実装されている Keep-Alive ヘッダを使った問題の情報と議論については RFC 2068 [33] 参 照)。 8.1.4 現実的な考察 多くのサーバは、もはや接続を維持しないとするタイムアウト値を持ってい るであろう。クライアントはたぶん同じサーバへとより多くの接続を持とう とするはずなので、プロクシサーバはサーバが設定するタイムアウト値より も大きな値にしたほうがよい。持続的接続の使用は、クライアントやサーバ のためのこのタイムアウト値の長さ (あるいは存在) に必要性を置かない。 クライアントやサーバがタイムアウトを望む時は、転送接続上礼儀正しい閉 鎖を発行す *べきである*。クライアントもサーバも、他方の転送の閉鎖を絶 えず監視し、適切にそれに応じる *べきである*。もし、クライアントやサー バが、相手側の閉鎖を即座に検出しなければ、それはネットワーク上の不必 要なリソース消耗を引き起こすかもしれない。 クライアント、サーバ、あるいはプロクシは、どんな時でも転送接続を閉鎖 する事が *できる*。例えば、サーバが "アイドル" 状態の接続を閉鎖しよう と決めたのと同時に、クライアントは新しいリクエストを送り始めるかもし れない。サーバ側から見れば接続はアイドルである間に閉鎖されているが、 クライアント側から見ればリクエストは進行中である。 これは、クライアント、サーバ、プロクシが、非同期のクローズイベントか ら回復でき *なければならない* という事を意味する。クライアントソフト ウェアは転送接続を再度オープンし、リクエストシーケンスが等冪 {idempotent} (section 9.1.2 参照) である限り、ユーザインタラクション なしに中止されたリクエストのシーケンスを再送信す *べきである*。そうで ないメソッドやシーケンスは自動的に再試行し *てはならない* が、ユーザ エージェントは人間のオペレータにリクエストの再試行についての選択を尋 ねても *よい*。アプリケーションが意味を理解した上で、ユーザ自身の確認 の代わりにユーザエージェントソフトウェアが確認しても *よい*。この自動 再試行は、もし二回目のリクエストシーケンスが失敗したなら繰り返す *べ きではない*。 サーバは、もし完全に可能なら、常に一つの接続につき少なくとも一つのリ クエストにレスポンスす *べきである*。サーバは、ネットワークやクライア ントの失敗を疑う場合以外は、レスポンスの転送中に接続をクローズす *べ きではない*。 持続的接続を使用するクライアントは、サーバへ維持する同時接続の数を制 限す *べきである*。シングルユーザクライアントは、どんなサーバやプロク シへも 2 接続より多く維持す *べきではない*。プロクシは、N は同時のア クティブユーザの数として、別のサーバやプロクシへの 2*N 接続以上を使用 す *べきである*。これらのガイドラインは HTTP レスポンスタイムを改善 し、ネットワークの混雑を避けようとするものである。 8.2 メッセージ転送の必要条件 8.2.1 持続的接続とフローコントロール HTTP/1.1 サーバは、一時的な過負荷を解消するためには、持続的接続を維持 し、TCP フローコントロールメカニズムを使う *べきであり*、クライアント が再試行するであろうという期待を持って接続を終了させるよりもよい。後 者の方法ではネットワークの混雑はよりひどくなるであろう。 8.2.2 エラーステータスメッセージのための接続のモニタリング メッセージボディを送る HTTP/1.1 (あるいはそれ以降) のクライアントは、 リクエストを送っている間、エラーステータスのためにネットワークの接続 をモニタリングす *べきである*。エラーステータスを発見した場合、すぐに ボディの転送を止める *べきである*。もしボディに "chunked" エンコーデ ィング (section 3.6) を施していたら、早過ぎるメッセージの終わりを表す ために 0 サイズのチャンクと空の trailer を使う事が *できる*。もしボデ ィより Content-Length ヘッダが先に送られていたら、クライアントは接続 を閉じ *なければならない*。 8.2.3 100 (Continue) ステータスの使用 100 (Continue) ステータス (section 10.1.1 参照) は、オリジンサーバが クライアントがリクエストボディを送る前に (リクエストヘッダに基づいた) リクエストを受け入れようとする場合に、リクエストボディを伴ったリクエ ストメッセージを送る事をクライアントに決めさせるという目的を持つ。い くつかのケースでは、サーバがボディを見る事も無くメッセージを受けつけ ていない場合にクライアントがボディを送る事は、不適切でひどく効率が悪 くなる事がある。 HTTP/1.1 クライアントの必要条件は、以下の通りである。 - もしクライアントがリクエストボディを送る前に 100 (Continue) レス ポンスのために待とうとするならば、"100-continue" という expectation を持った Expect リクエストヘッダフィールド(section 14.20) を送ら *なければならない*。 - もしリクエストボディを送るつもりが無いならば、"100-continue" と いう expectation を持った Expect リクエストヘッダフィールド (section 14.20) を送っ *てはならない*。 未だに古いインプリメンテーションが存在するため、プロトコルではクライ アントが 417 (Expectation Failed) ステータスや 100 (Continue) ステー タスを受け取る前に、"Expect: 100-continue" を送ってしまうかもしれない ようなあいまいな場面を認めている。それ故に、クライアントが 100 (Continue) ステータスを見た事が無いようなオリジンサーバ (あるいは経由 するプロクシ) にこれを送るような時でも、リクエストボディを送る前に無 期限で待つような事はす *べきではない*。 HTTP/1.1 オリジンサーバの必要条件は、以下の通りである。 - "100-continue" という expectation を持つ Expect リクエストヘッダ フィールドを含むリクエストを受け取った時は、100 (Continue) ステ ータスを応答し引き続き入力ストリームを読み続けるか、最終ステータ スコードを応答するか、どちらかを実行し *なければならない*。オリ ジンサーバは、100 (Continue) レスポンスを送る前にリクエストボデ ィを待ってい *てはならない*。最終ステータスコードを応答した場合 は、転送接続を切断しても *よい* し、引き続き読みこんで残りのリク エストを破棄しても *よい*。最終ステータスコードを返した場合は、 そのリクエストメソッドを実行し *てはならない*。 - オリジンサーバは、リクエストメッセージが "100-continue" という expectation を持つ Expect リクエストヘッダを含んでいなければ 100 (Continue) レスポンスを送る *べきではなく*、リクエストが HTTP/1.0 (あるいはそれ以前) のクライアントからのものであったら、 100 (Continue) レスポンスを送っ *てはならない*。この規則には拡張 がある。すなわち、RFC 2068 との互換性のため、サーバは "100-continue" という expectation を持つ Expect リクエストヘッダ を含んでいない HTTP/1.1 PUT あるいは POST リクエストへのレスポン スに 100 (Continue) を送る事が *できる*。クライアントのプロセス が 100 (Continue) ステータスのために宣言されない待機によって遅れ る事を最小限にするという目的を持つこの拡張は、HTTP/1.1 リクエス トにのみ適用され、他の HTTP バージョン値を持つリクエストには適用 されない。 - オリジンサーバは、すでにそのリクエストに関する一部、あるいは全部 のリクエストボディを既に受け取っている場合、100 (Continue) レス ポンスを省略する事が *できる*。 - 100 (Continue) レスポンスを送るオリジンサーバは、先に転送接続が 切られているので無ければ、一度リクエストボディが受け取られ、処理 され、最終的には最終ステータスコードを送ら *なければならない*。 - オリジンサーバが "100-continue" という expectation を持つ Expect リクエストヘッダフィールドを含まないリクエストを受け取ったなら ば、リクエストはリクエストボディを含んでいるので、サーバはその転 送接続からのリクエストボディ全体を読みきる前に最終ステータスコー ドを返すが、リクエスト全体を読みきるまで、あるいはクライアントが その接続を切断するまでは、サーバは、その転送接続を切断す *べきで はない*。そうしなければ、クライアントは確実にレスポンスメッセー ジを受け取れないかもしれない。しかし、この必要条件はサーバがサー ビス不能攻撃{denial-of-service attacks} やひどく破綻したクライア ントインプリメンテーションから、己の身を守る事を妨げるようには作 作られてはいない。 HTTP/1.1 プロクシの必要条件は、以下の通りである。 - プロクシが "100-continue" という expectation を持つ Expect リク エストヘッダフィールドを含むリクエストを受け取った時に、プロクシ が次に接続する{next-hop} サーバが HTTP/1.1 以上に従っている事を 知っている、あるいは次に接続するサーバの HTTP バージョンを知らな い場合には、Expect ヘッダフィールドを含めて、リクエストを転送し *なければならない*。 - プロクシが、次に接続するサーバが HTTP/1.0 以下のバージョンである 事を知っていたら、そのリクエストは転送せずに、417 (Expectation Failed) ステータスを返さ *なければならない*。 - プロクシは、最近参照したネクストホップサーバから受け取った HTTP バージョン番号をキャッシュに記録し保管す *べきである*。 - プロクシは、HTTP/1.0 (あるいはそれ以前) のクライアントから受け取 り、そこに "100-continue" という expectation を持つ Expect リク エストヘッダフィールドを含んでいないリクエストメッセージは、100 (Continue) レスポンスを転送し *てはならない*。この必要条件は、 1xx レスポンス (section 10.1 参照) を転送するという一般規則を上 書きする。 8.2.4 サーバが早まって接続を閉じた場合のクライアントの振る舞い もし、HTTP/1.1 クライアントがリクエストボディを持つが、"100-continue" という expectation を持つ Expect リクエストヘッダフィールドを含んでい ないリクエストメッセージを送り、しかもクライアントは HTTP/1.1 オリジ ンサーバには直接接続はしておらず、そこでクライアントがサーバからのど んなステータスをも受け取る前に接続の切断を知った場合は、クライアント はリクエストを再試行す *べきである*。クライアントがこのリクエストを再 試行する時は、確実なレスポンスの獲得を保証させるため、以下の "binary exponential backoff" アルゴリズムを使用 *できる*。 1. サーバへの接続を初期化する 2. リクエストヘッダを転送する 3. サーバへと見積もった round-trip time (つまり、その接続を確立す るためにかかった時間に基づいているもの) か、あるいは round-trip time が利用できい場合は定数値である 5 秒で変数 R を初期化する。 4. T = R * (2**N) を計算する。この時、N はこのリクエストの前までの 試行回数である。 5. サーバからのエラーレスポンスが来るか、もしくは T 秒 (どちらかが 来るまで) 待つ 6. エラーレスポンスが受信されなければ、T 秒後にリクエストのボディ を転送する。 7. クライアントは、コネクションが早まって切断されたのを知ったなら ば、リクエストが受け入れられ、エラーレスポンスを受け取るか、ユ ーザが待ちかねて再試行プロセスを終了するまで、ステップ 1 から繰 り返す。 上のどの時点でも、エラーステータスを受けとったら、クライアントは - 続ける *べきではない* し - もしリクエストメッセージを完全に送信していなければ、接続を切断す *べきである*。 9 メソッド定義 HTTP/1.1 のための一般的なメソッドのセットは以下に定義される。このセッ トは拡張可能であるが、追加されるメソッドは別々に拡張されたクライアン トとサーバに対して同じセマンティクスを共有する事を仮定できない。 Host リクエストヘッダフィールド(section 14.23) は、すべての HTTP/1.1 リクエストに付加され *なければならない*。 9.1 安全なメソッドと等冪{idempotent} なメソッド 9.1.1 安全なメソッド 実装者は、インターネット上における相互動作においてはソフトウェアがユ ーザを表しているという事を認識すべきであり、ユーザがそれら自身や他の ものに対して予測しない意図を持つようなあらゆる動作に気がつく事ができ るように注意すべきである。 特に、GET と HEAD メソッドはその動作にリソースの回収以上の意味を持つ *べきではない* という慣習が確立されている。これらのメソッドは、"安全" だと考えるべきである。これによって、ユーザエージェントがそれ以外の、 例えば POST, PUT, DELETE のようなメソッドを特別な方法で表す事ができる ようになり、ユーザにひょっとしたら安全でない動作が要求されているかも しれないという事実を認識させる。 本質的に、サーバが GET リクエストを実行した結果として副作用を起こさな いという事を保証するのは不可能であり、事実、いくつかの動的なリソース はそれが特徴であると考えている。ここで特に区別すべきなのは、ユーザが 副作用を要求しなかったという事であり、それゆえにそれらに対しては責任 をもてない。 9.1.2 等冪{idempotent} なメソッド メソッドは、(エラーや期限切れ発行とは別に) 同一のリクエストの N > 0 の副作用が単一のリクエストにおけるものと同じであるような際には "等冪{idempotence}" の性質を持つ事もできる。GET, HEAD, PUT, DELETE 各 メソッドはこの性質を共有する。また、OPTIONS と TRACE 各メソッドは副作 用を持つ *べきではない* し、本来等冪であるものである。 しかしながら、たとえその順序にて実行される全てのメソッドが等冪であっ たとしても、いくつかのリクエストの順番は等冪ではない。(もし全体の順序 中のある一つを実行しても、その順序の全体、または一部分を再実行した際 に結果は常に変わらないという事になるのであれば、順序は等冪である。) 例えば、同じ順序でもその結果が後に修正される値に依存するのであれば、 順序は等冪ではない。 副作用を持たない順序は、(同時に起こる動作は同じリソースの一組{set} 上 に実行されている事は無い、との条件で) 定義によって等冪である。 9.2 OPTIONS OPTIONS メソッドは、Request-URI によって識別されるリクエスト／レスポ ンス連鎖上で利用可能な通信オプションについての情報のためのリクエスト を表す。クライアントは、このメソッドはを使ってリソースアクションを暗 に意味したりリソース回収を初期化する事なしに、リソースやサーバの能力 に関するオプションや必要条件を決定する事ができる。 このメソッドへのレスポンスはキャッシュ可能ではない。 もし OPTIONS リクエストが (Content-Length や Transfer-Encoding の存在 によって指し示される様な) エンティティボディを含むならば、そのメディ アタイプは Content-Type フィールドによって指し示され *なければならな い*。この特性は、そのようなエンティティボディのいかなる使用方法も決定 しないが、HTTP の将来的な拡張によってそのサーバについてのより詳細な情 報文字列を作るために OPTIONS のボディを使うかもしれない。そのような拡 張機能をサポートしていないサーバでは、リクエストボディを廃棄する *か もしれない*。 もし、Request-URI がアスタリスク ("*") なら、OPTIONS リクエストは特定 のリソースへというよりも全体としてサーバへ適用する意思を示す。サーバ のコミュニケーションオプションは典型的にリソースに依存するので、"*" リクエストは、まるで "ping" や "no-op" のように使われるのみで、すなわ ちサーバの能力をテストするする事をクライアントに許可する以上には意味 を持たない。例えば、これはプロクシに HTTP/1.1 に従っているか (あるい はその機能が欠けているか) をテストするために使われる。 もし、Request-URI が アスタリスクでなければ、OPTIONS リクエストはその リソースと通信する時に利用可能なオプションのみを尋ねる。 200 レスポンスには、サーバによって実装され、そのリソースに適用できる オプション的な機能を示す (例えば、Allow のような) ヘッダフィールド や、可能であればこの仕様書で定義されていないような拡張も含む *べきで ある*。もしレスポンスボディがあれば、それはコミュニケーションオプショ ンについての情報も含む *べきである*。そのようなボディのフォーマットは この仕様書では定義しないが、HTTP の将来の拡張によって定義されるであろ う。適切なレスポンストを選択するために、フォーマッコンテントネゴシエ ーションを使われる *かもしれない*。もしレスポンスボディが含まれていな ければ、そのレスポンスは "0" というフィールド値を持つ Content-Length フィールドを含ま *なければならない*。 Max-Forwards リクエストヘッダフィールドは、リクエスト連鎖中で特定のプ ロクシを目標に使われるで *あろう*。プロクシは、転送が許可されたリクエ ストのための absoluteURI と共に OPTIONS リクエストを受けとった時に は、Max-Forwards フィールドをチェックし *なければならない*。もし、 Max-Forwards フィールドの値がゼロ("0") ならば、プロクシはそのメッセー ジを転送し *てはならない*。その代わりに、プロクシ自身のコミュニケーシ ョンオプションを返す *べきである*。もし、Max-Forwards フィールドの値 がゼロより大きな整数値ならば、プロクシはリクエストを転送する際にその 値を一つ減らさ *なければならない*。リクエストの中に Max-Forwards フィ ールドが存在していなければ、転送するリクエストに Max-Forwards フィー ルドを含め *てはならない*。 9.3 GET GET メソッドは、Request-URI で識別される (エンティティ形式の) 情報な らなんでも回収する事を意味する。もし、Request-URI がデータ生産プロセ ス{data-producing process} を参照するのであれば、それはレスポンスのエ ンティティとして返されるであろうとして生産されるデータであり、もしそ のテキストがプロセスの出力として生じるのでなければ、プロセスのソース テキストではない。 リクエストメッセージに If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range のいずれかのヘッダフィールドを含ん でいる場合、GET メソッドのセマンティクスは条件付き GET に変わる。条件 付き GET メソッドは、エンティティがその条件付きヘッダフィールドによっ て表される状況下でのみ転送されるようにリクエストする。条件付き GET メ ソッドは、キャッシュされるエンティティに複数のリクエストを要求する事 や、クライアントによってすでに保持されているデータを転送する事無く清 新できるようにする事で、不必要なネットワークの使用を減らそうというも のである。 リクエストメッセージに Range ヘッダフィールドを含んでいる場合、GET メ ソッドのセマンティクスは "部分的 GET" に変わる。部分的 GET は、 section 14.35 で示されるように、転送されるエンティティの一部のみを要 求する。部分的 GET メソッドは、クライアントによって既に保持されている データを転送する事無くエンティティを部分的に取得させ、完全なものにで きるようにする事で、不必要なネットワークの使用を減らそうというもので ある。 GET リクエストへのレスポンスは、section 13 に示されるような HTTP キャ ッシングのための必要条件がそろった場合にのみ、キャッシュ可能となる。 フォームを使った場合のセキュリティの考察については、section 15.1.3 を 見よ。 9.4 HEAD HEAD メソッドは、サーバがレスポンスにおいてメッセージボディを返し *て はならない* 事を除けば GET と同一である。HEAD リクエストへのレスポン スにおける HTTP ヘッダに含まれる外部情報は、GET リクエストへのレスポ ンスで送られる情報と同一である *べきである*。このメソッドは、エンティ ティボディ自身を転送する事なしにリクエストによって意味されるエンティ ティに付いての外部情報を得るために使用される。このメソッドは、ハイパ ーテキストリンクの正当性、アクセス可能性、最近の修正のテストのため に、しばしば使用される。 HEAD リクエストへのレスポンスは、そのレスポンスに含まれる情報はリソー スから前もってキャッシュされたエンティティを更新するために使う事が *できる* 、という意味でキャッシュ可能である *かもしれない*。もし、新 しいフィールド値がキャッシュされたエンティティは (Content-Length, Content-MD5, ETag, Last-Modified 各値の変更によって示されるように) 現 在のエンティティと違うという事を示すならば、キャッシュはそのキャッシ ュエンティティを新鮮でないものとして扱わ *なければならない*。 9.5 POST POST メソッドは、サーバがリクエストライン内の Request-URI により識別 されるリソースへの新しい従属{subordinate} として、リクエストに同封さ れるエンティティを受け入れる事を要求するために使用される。POST は以下 の機能のカバーするための画一的メソッドとして設計されている。 - 既存リソースの注釈 - 掲示板、ニュースグループ、メーリングリスト、あるいはその類の記事 グループへのメッセージの投稿 - フォーム提出の結果のような、データ処理プロセス {data-handling process} へのデータブロックの供給 - 追加動作を通したデータベースの拡張 POST メソッドによって実行される実際の機能はサーバによって決定され、通 常は Request-URI に依存する。ポストされたエンティティは、ファイルが ディレクトリに従属し、ニュース記事がそれがポストされたニュースグルー プに従属し、レコードがそのデータベースに従属しているという事と同じ形 で、その URI に従属する。 POST メソッドによって実行される動作は、URI によって識別されうるリソー スという結果にはならないかもしれない。この場合、200 (OK) か 204 (No Content) が適切なレスポンスステータスであり、それはレスポンスが結果を 記述したエンティティを含んでいるかどうかに依存する。 リソースがオリジンサーバで既に生成されている場合、レスポンスは 201 (Created) であり、リクエストのステータス、新しいリソースへの参照、 Location ヘッダ (section 14.30) を記述したエンティティを含む *べきで ある*。 レスポンスが適切な Cache-Control や Expires ヘッダフィールドを含んで いなければ、このメソッドのレスポンスはキャッシュ可能ではない。しかし ながら、303 (See Other) レスポンスは、ユーザエージェントにキャッシュ 可能なリソースの検索を指示するために使用される。 POST リクエストは、section 8.2 にあるメッセージ転送要求に従わ *なけれ ばならない*。 セキュリティの考察については、section 15.1.3 参照。 9.6 PUT PUT メソッドは、同封されたエンティティを供給される Request-URI の元に 保存するように要求する。Request-URI が既に存在するリソースを参照して いる場合は、同封されるエンティティはオリジンサーバにあるそれの修正版 とみなされる *べきである*。Request-URI が既存のリソースを指していない 場合に、その URI がリクエストしているユーザエージェントによって新しい リソースとして定義する事ができる時は、オリジンサーバはその URI にリソ ースを作成できる。新しいリソースが作成された場合、オリジンサーバは 201 (Created) レスポンスをもってユーザエージェントに知らせ *なければ ならない*。既存のリソースが更新された場合は、リクエストが成功し終了し た事を示すために 200 (OK) か 204 (No Content) のいずれかのレスポンス コードを送る *べきである*。もし、リソースがその Request-URI に作成、 あるいは更新されなかった時は、問題の本質を反映する適切なエラーレスポ ンスが与えられる *べきである*。エンティティを受ける側は、理解できなか ったり実装していないようないかなる Content-* ヘッダ (例えば Content-Range 等) も無視してはならず、そのような場合には 501 (Not Implemented) レスポンスを返さ *なければならない*。 リクエストがキャッシュを通り抜けたり、Request-URI が現在キャッシュさ れている一つ以上のエンティティを識別する場合、これらのエンティティは 新鮮でないものとして扱われる *べきである*。このメソッドのレスポンスは キャッシュできない。 リクエスト POST と PUT とでの根本的な違いは、Request-URI の意味の違い をもたらす。POST リクエストにおける URI は、同封されたエンティティを 処理するであろうリソースを識別する。リソースは、データ受諾プロセス {data-accepting process} か、ある別のプロトコルへのゲートウェイ、ある いは注釈を受け入れる分割されたエンティティであろう。それに対して、PUT リクエストにおける URI は、リクエストとともに同封されたエンティティを 識別する。しかし、ユーザエージェントがリソースにその URI を割り当てる つもりであっても、サーバはそのリクエストをある別のリソースへと割り当 てようとし *てはならない*。そのリクエストを別の URI に申しこむように 要求する時は、サーバは 301 (Moved Permanently) レスポンスを返さ *なけ ればならない*。この時、ユーザエージェントはそのリクエストをリダイレク トするかどうかに関して決める事が *できる*。 単一のリソースが、多くの異なった URI によって識別される *かもしれな い*。例えば、ある記事が各々のバージョンを識別する URI とは別に、"最新 のバージョン" を識別するための URI を持っているかもしれない。この場 合、一般の URI への PUT リクエストは、オリジンサーバによって定義され ているいくつかの他の URI へと行われるはずである。 HTTP/1.1 では、PUT メソッドがオリジンサーバの状態にどのように影響を及 ぼすかは定義しない。 PUT リクエストは、section 8.2 にあるメッセージ転送要求に従わ *なけれ ばならない*。 特定のエンティティヘッダが別の方法では指定できない場合、PUT リクエス トにおけるエンティティヘッダは、PUT によって作成、あるいは修正された リソースに適用される *べきである*。 9.7 DELETE DELETE メソッドは、オリジンサーバが Request-URI により識別されるリソ ースを削除する事を要求する。このメソッドは、オリジンサーバにおいて人 間の手 (あるいは別の方法) によって上書きされている *かもしれない*。例 えオリジンサーバから返されたステータスコードは動作がうまく完了したと いう事を示していたとしても、クライアントはその操作が実行された事は保 証されない。しかしそのレスポンスが与えられた場合に、サーバがそのリソ ースを削除したり、アクセスできない場所へ移動したりしようとしていない のであれば、成功を示す *べきではない*。 成功したレスポンスは、もしレスポンスがステータスで表しているエンティ ティを含んでいるなら 200 (OK)、もし動作がまだ行われていないなら 202 (Accepted)、もし動作は行われたが、レスポンスにエンティティを含んでい ないなら 204 (No Content) である *べきである*。 もし、リクエストがキャッシュを通り抜けたり、Request-URI が現在キャッ シュされている一つ以上のエンティティとして識別されるなら、これらのエ ンティティは新鮮でないものとして扱われる *べきである*。このメソッドの レスポンスはキャッシュできない。 9.8 TRACE TRACE メソッドは、リクエストメッセージのアプリケーション層のループバ ックを遠隔的に発動するために使用される。リクエストの最後の受信者は、 200 (OK) レスポンスのエンティティボディとして、そのメッセージをクライ アントにそのまま送り返す *べきである*。最後の受信者とは、オリジンサー バ、もしくはリクエストで Max-Forwards (section 14.31) 値がゼロ (0) で あったものを受け取った最初のプロクシかゲートウェイである。TRACE リク エストはエンティティを含ん *ではならない*。 TRACE を使って、クライアントはリクエスト連鎖の反対側では何が受け取ら れているのかを見る事や、テストや診断情報のためのデータを使用する事が できる。これはリクエスト連鎖のトレースとして動作するので、Via ヘッダ フィールド (section 14.45) の値が特に重要である。Max-Forwards ヘッダ フィールドを使用する事で、クライアントにリクエスト連鎖の大きさに制限 を与える事ができ、これは無限ループ上でメッセージを転送するプロクシ連 鎖をテストするために有用である。 もしリクエストが妥当ならば、レスポンスは "message/http" という Content-Type と一緒に、エンティティボディとしてリクエストメッセージの 全体を含む *べきである*。このメソッドのレスポンスはキャッシュされ *て はならない*。 9.9 CONNECT この仕様書では、(例えば SSLトンネリング [44] 等の) トンネルとなるよう に動的に切り換える事ができるプロクシが使用する時のために CONNECT とい うメソッド名を予約する。 10 ステータスコード定義 各々のステータスコードについて、レスポンス時に後に従える事のできるメ ソッドと必要とされるすべての外部情報の記述と共に、以下に記述する。 10.1 Informational 1xx このステータスコードのクラスは一時的なレスポンスを示し、ステータスラ インとオプション的なヘッダからのみなり、空行で終了する。このステータ スコードのクラスのための必要なリクエストヘッダは無い。HTTP/1.0 では、 どんな 1xx ステータスコードも定義していないので、サーバは実験的な状況 下以外では HTTP/1.0 クライアントに 1xx レスポンスを送っ *てはならな い*。 クライアントは、例え 100 (Continue) ステータスメッセージを期待してい なかったとしても、通常のレスポンスの前の一つ以上の 1xx レスポンスを受 け入れるよう準備されてい *なければならない*。ユーザエージェントは、期 待していない 1xx レスポンスを無視する事が *できる*。 プロクシは、もしプロクシとクライアント間の接続が切断されている、ある いはプロクシ自身が 1xx レスポンスの生成を要求したという場合以外は、 1xx レスポンスを転送しなければならない。 (例えば、プロクシがリクエス トを転送する時に "Expect: 100-continue" というフィールドを付け加えた 時には、それに相当する 100 (Continue) レスポンスを転送する必要はな い。) 10.1.1 100 Continue クライアントは、そのリクエストを続ける *べきである*。この暫定的レスポ ンスは、リクエストの始めの部分は受け取られ、サーバによって拒否された ものではないという事をクライアントに知らせるために使用される。クライ アントは、リクエストの残りを送り続けるか、もし既にリクエストが完了し ていれば、このレスポンスを無視す *べきである*。サーバは、リクエストが 完了した後に最終的なレスポンスを送ら *なければならない*。このステータ スコードの使用・処理の詳細な議論のために section 8.2.3 参照。 10.1.2 101 Switching Protocols サーバは理解し、Upgrade メッセージヘッダフィールド (section 14.42) を 使って、この接続で使用されているアプリケーションプロトコルを変更する 事でクライアントのリクエストに従おうとしている。サーバは 101 レスポン スを終了する空行のあと、すぐにレスポンスの Upgrade ヘッダフィールドに よって定義されたプロトコルに変更するだろう。 プロトコルは、変更した方が有益な場合にのみ変更される *べきである*。例 えば、HTTP のより新しいバージョンに変更するという事は、古いバージョン 以上に有益だし、リアルタイムに、同期するプロトコルを変更する事はその ような機能を使うリソースを配布するときに都合が良いだろう。 10.2 Successful 2xx このステータスコードのクラスは、クライアントのリクエストがうまく受信 され、理解され、そして受け入れられた事を示す。 10.2.1 200 OK リクエストは成功した。レスポンスと共に返される情報はリクエストに使用 されたメソッドに依存し、例えば以下の様になる。 GET リクエストされたリソースに対応するエンティティがレスポンスとし て送られる。 HEAD リクエストされたリソースに対応するエンティティヘッダフィールド がメッセージボディを伴わずにレスポンスとして送信される。 POST 動作の結果を記述もしくは含んでいるエンティティ TRACE 端末サーバによって受信されたリクエストメッセージを含んでいるエ ンティティ 10.2.2 201 Created リクエストは果たされ、結果として新しいリソースが作成された。新しく作 成されたリソースは Location ヘッダにより与えられるリソースに対する最 も明確な URI を伴って、レスポンスのエンティティにおいて返される URI によって参照される。レスポンスは、ユーザあるいはユーザエージェントが 最も適切なものを選択するために、リソースの特徴と場所のリストをエンテ ィティとして含む *べきである*。エンティティのフォーマットは、 Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定 される。オリジンサーバは、201 ステータスコードを返す前にリソースを作 成し *なければならない*。もし動作がすぐに実行できないのであれば、サー バは代わりに 202 (Accepted) レスポンスを返す *べきである*。 201 レスポンスは、作成されたばかりのリクエストされたバリアントのため に、現在のエンティティタグの値を示す ETag レスポンスヘッダフィールド を含む事が *できる*。section 14.19 参照。 10.2.3 202 Accepted リクエストは処理のために受け入れられたが、処理は完了されていない。こ のリクエストは、実際に処理される時に拒否されるかもしれないので、最終 的に動作されるかどうかは不明である。このような非同期操作からステータ スコードを再送信するための機能は存在しない。 202 レスポンスは、意図的に責任を持たない{non-committal}。これはサーバ が、プロセスが完了されるまでユーザエージェントとの接続を持続させる事 無く、他のいくつかのプロセス (多分一日に一度しか実行されないバッチ志 向プロセス{batch-oriented process}) のためのリクエストを受け入れる事 を可能にするという目的を持つ。このレスポンスによって返されるエンティ ティは、リクエストの現在の状態を表すものと、状態モニタへのポインタ、 あるいはそのリクエストがいつ果たされるかをユーザが予期できる見積もり のどちらかを含む *べきである*。 10.2.4 203 Non-Authoritative Information エンティティヘッダにおいて返された外部情報は、オリジンサーバから利用 できるような決定的なセットではなく、ローカルもしくはサードパーティコ ピーから集められたものである。提示されたセットは元のバージョンのサブ セットかスーパーセットで *あろう*。例えば、リソースについてのローカル な注釈情報を含む事はオリジンサーバによって知らされる外部情報のスーパ ーセットとなるかもしれない。そのレスポンスが 200 (OK) とは別の方法で 示したい場合、このレスポンスコードを使用する必要はないが、そのような 場合にのみ適切である。 10.2.5 204 No Content サーバはリクエストを受け入れたが、エンティティボディを送り返す必要は 無く、更新された外部情報を返す事を望むだろう。レスポンスは、エンティ ティヘッダ形式の中に、新規あるいは更新された外部情報を含む事が *でき*、もしあればリクエストされたバリアントが関連付けられる *べきで ある*。 もしクライ