#======================================================================# $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