TITLE : Hypertext Transfer Protocol -- HTTP/1.1 Network Working Group R. Fielding Request for Comments: 2068 UC Irvine Category: Standards Track J. Gettys J. Mogul DEC H. Frystyk T. Berners-Lee MIT/LCS January 1997 [セマンティクス]: semantics (意味論、記号論) 意味的に日本語に相当する言葉はないが、強いて言えば『単純な記号 の並びなどに割り当てられる特別な意味』。 [誰何 (すいか)]: challange (番兵や門衛などが見知らぬ人を「だれか？」などと呼びとがめる事) HTTP アクセス認証 や内容ネゴシエーションで使用される。 [表現]: representation 中に含まれる情報が全く同じでも、データは異なる言語、画像フォーマット、圧縮形式な ど、さまざまなバリエーションを持つ事ができる点に注意。たとえば何かのグラフを表す のに GIF, JPEG, EPS などの画像フォーマットを使う事が考えられる (もしかしたら ASC II キャラクタ図形かもしれない) し、固有の表計算ソフトで与えられるかもしれない。 また、全く同じ画像フォーマットでも圧縮形式が異なるかもしれない。つまり、データの 情報が同じでもいくつかの異なる表現で与えられる事がある。 -------------------------------------------------------------------------------- Hypertext Transfer Protocol HTTP/1.1 この記述の状態 このドキュメントはインターネットコミュニティのためのインターネット標準トラックプ ロトコルを詳述し、改善のための論議と提案を要求する。標準化の状態とこのプロトコル は "インターネット公式プロトコル標準" (STD 1) の最新版を参照してください。この記 述の配布は無制限である。 概要 Hypertext Transfer Protocol (HTTP) は共同的ハイパーメディア情報システム配布シス テムのためのアプリケーションレベルプロトコルである。これはリクエストメソッドの拡 張を通じて、ネームサーバやオブジェクト配布管理システムなど、さまざまな作業に対し て使用する事のできる一般的で国に依存しないオブジェクト指向プロトコルである。HTTP の機構はデータ表現のタイプ付けやネゴシエーションを行う事であり、転送データに依存 しないシステムを構築できる。 HTTP は 1990 から World-Wide Web グローバル情報イニシアティブとしてすでに使用さ れている。この仕様書は "HTTP/1.1" として言及されるプロトコルを定義する。 目次 1 Introduction.............................................7 1.1 Purpose ..............................................7 1.2 Requirements .........................................7 1.3 Terminology ..........................................8 1.4 Overall Operation ...................................11 2 Notational Conventions and Generic Grammar..............13 2.1 Augmented BNF .......................................13 2.2 Basic Rules .........................................15 3 Protocol Parameters.....................................17 3.1 HTTP Version ........................................17 3.2 Uniform Resource Identifiers ........................18 3.2.1 General Syntax ...................................18 3.2.2 http URL .........................................19 3.2.3 URI Comparison ...................................20 3.3 Date/Time Formats ...................................21 3.3.1 Full Date ........................................21 3.3.2 Delta Seconds ....................................22 3.4 Character Sets ......................................22 3.5 Content Codings .....................................23 3.6 Transfer Codings ....................................24 3.7 Media Types .........................................25 3.7.1 Canonicalization and Text Defaults ...............26 3.7.2 Multipart Types ..................................27 3.8 Product Tokens ......................................28 3.9 Quality Values ......................................28 3.10 Language Tags ......................................28 3.11 Entity Tags ........................................29 3.12 Range Units ........................................30 4 HTTP Message............................................30 4.1 Message Types .......................................30 4.2 Message Headers .....................................31 4.3 Message Body ........................................32 4.4 Message Length ......................................32 4.5 General Header Fields ...............................34 5 Request.................................................34 5.1 Request-Line ........................................34 5.1.1 Method ...........................................35 5.1.2 Request-URI ......................................35 5.2 The Resource Identified by a Request ................37 5.3 Request Header Fields ...............................37 6 Response................................................38 6.1 Status-Line .........................................38 6.1.1 Status Code and Reason Phrase ....................39 6.2 Response Header Fields ..............................41 7 Entity..................................................41 7.1 Entity Header Fields ................................41 7.2 Entity Body .........................................42 7.2.1 Type .............................................42 7.2.2 Length ...........................................43 8 Connections.............................................43 8.1 Persistent Connections ..............................43 8.1.1 Purpose ..........................................43 8.1.2 Overall Operation ................................44 8.1.3 Proxy Servers ....................................45 8.1.4 Practical Considerations .........................45 8.2 Message Transmission Requirements ...................46 9 Method Definitions......................................48 9.1 Safe and Idempotent Methods .........................48 9.1.1 Safe Methods .....................................48 9.1.2 Idempotent Methods ...............................49 9.2 OPTIONS .............................................49 9.3 GET .................................................50 9.4 HEAD ................................................50 9.5 POST ................................................51 9.6 PUT .................................................52 9.7 DELETE ..............................................53 9.8 TRACE ...............................................53 10 Status Code Definitions................................53 10.1 Informational 1xx ..................................54 10.1.1 100 Continue ....................................54 10.1.2 101 Switching Protocols .........................54 10.2 Successful 2xx .....................................54 10.2.1 200 OK ..........................................54 10.2.2 201 Created .....................................55 10.2.3 202 Accepted ....................................55 10.2.4 203 Non-Authoritative Information ...............55 10.2.5 204 No Content ..................................55 10.2.6 205 Reset Content ...............................56 10.2.7 206 Partial Content .............................56 10.3 Redirection 3xx ....................................56 10.3.1 300 Multiple Choices ............................57 10.3.2 301 Moved Permanently ...........................57 10.3.3 302 Moved Temporarily ...........................58 10.3.4 303 See Other ...................................58 10.3.5 304 Not Modified ................................58 10.3.6 305 Use Proxy ...................................59 10.4 Client Error 4xx ...................................59 10.4.1 400 Bad Request .................................60 10.4.2 401 Unauthorized ................................60 10.4.3 402 Payment Required ............................60 10.4.4 403 Forbidden ...................................60 10.4.5 404 Not Found ...................................60 10.4.6 405 Method Not Allowed ..........................61 10.4.7 406 Not Acceptable ..............................61 10.4.8 407 Proxy Authentication Required ...............61 10.4.9 408 Request Timeout .............................62 10.4.10 409 Conflict ...................................62 10.4.11 410 Gone .......................................62 10.4.12 411 Length Required ............................63 10.4.13 412 Precondition Failed ........................63 10.4.14 413 Request Entity Too Large ...................63 10.4.15 414 Request-URI Too Long .......................63 10.4.16 415 Unsupported Media Type .....................63 10.5 Server Error 5xx ...................................64 10.5.1 500 Internal Server Error .......................64 10.5.2 501 Not Implemented .............................64 10.5.3 502 Bad Gateway .................................64 10.5.4 503 Service Unavailable .........................64 10.5.5 504 Gateway Timeout .............................64 10.5.6 505 HTTP Version Not Supported ..................65 11 Access Authentication..................................65 11.1 Basic Authentication Scheme ........................66 11.2 Digest Authentication Scheme .......................67 12 Content Negotiation....................................67 12.1 Server-driven Negotiation ..........................68 12.2 Agent-driven Negotiation ...........................69 12.3 Transparent Negotiation ............................70 13 Caching in HTTP........................................70 13.1.1 Cache Correctness ...............................72 13.1.2 Warnings ........................................73 13.1.3 Cache-control Mechanisms ........................74 13.1.4 Explicit User Agent Warnings ....................74 13.1.5 Exceptions to the Rules and Warnings ............75 13.1.6 Client-controlled Behavior ......................75 13.2 Expiration Model ...................................75 13.2.1 Server-Specified Expiration .....................75 13.2.2 Heuristic Expiration ............................76 13.2.3 Age Calculations ................................77 13.2.4 Expiration Calculations .........................79 13.2.5 Disambiguating Expiration Values ................80 13.2.6 Disambiguating Multiple Responses ...............80 13.3 Validation Model ...................................81 13.3.1 Last-modified Dates .............................82 13.3.2 Entity Tag Cache Validators .....................82 13.3.3 Weak and Strong Validators ......................82 13.3.4 Rules for When to Use Entity Tags and Last- modified Dates..........................................85 13.3.5 Non-validating Conditionals .....................86 13.4 Response Cachability ...............................86 13.5 Constructing Responses From Caches .................87 13.5.1 End-to-end and Hop-by-hop Headers ...............88 13.5.2 Non-modifiable Headers ..........................88 13.5.3 Combining Headers ...............................89 13.5.4 Combining Byte Ranges ...........................90 13.6 Caching Negotiated Responses .......................90 13.7 Shared and Non-Shared Caches .......................91 13.8 Errors or Incomplete Response Cache Behavior .......91 13.9 Side Effects of GET and HEAD .......................92 13.10 Invalidation After Updates or Deletions ...........92 13.11 Write-Through Mandatory ...........................93 13.12 Cache Replacement .................................93 13.13 History Lists .....................................93 14 Header Field Definitions...............................94 14.1 Accept .............................................95 14.2 Accept-Charset .....................................97 14.3 Accept-Encoding ....................................97 14.4 Accept-Language ....................................98 14.5 Accept-Ranges ......................................99 14.6 Age ................................................99 14.7 Allow .............................................100 14.8 Authorization .....................................100 14.9 Cache-Control .....................................101 14.9.1 What is Cachable ...............................103 14.9.2 What May be Stored by Caches ...................103 14.9.3 Modifications of the Basic Expiration Mechanism 104 14.9.4 Cache Revalidation and Reload Controls .........105 14.9.5 No-Transform Directive .........................107 14.9.6 Cache Control Extensions .......................108 14.10 Connection .......................................109 14.11 Content-Base .....................................109 14.12 Content-Encoding .................................110 14.13 Content-Language .................................110 14.14 Content-Length ...................................111 14.15 Content-Location .................................112 14.16 Content-MD5 ......................................113 14.17 Content-Range ....................................114 14.18 Content-Type .....................................116 14.19 Date .............................................116 14.20 ETag .............................................117 14.21 Expires ..........................................117 14.22 From .............................................118 14.23 Host .............................................119 14.24 If-Modified-Since ................................119 14.25 If-Match .........................................121 14.26 If-None-Match ....................................122 14.27 If-Range .........................................123 14.28 If-Unmodified-Since ..............................124 14.29 Last-Modified ....................................124 14.30 Location .........................................125 14.31 Max-Forwards .....................................125 14.32 Pragma ...........................................126 14.33 Proxy-Authenticate ...............................127 14.34 Proxy-Authorization ..............................127 14.35 Public ...........................................127 14.36 Range ............................................128 14.36.1 Byte Ranges ...................................128 14.36.2 Range Retrieval Requests ......................130 14.37 Referer ..........................................131 14.38 Retry-After ......................................131 14.39 Server ...........................................132 14.40 Transfer-Encoding ................................132 14.41 Upgrade ..........................................132 14.42 User-Agent .......................................134 14.43 Vary .............................................134 14.44 Via ..............................................135 14.45 Warning ..........................................137 14.46 WWW-Authenticate .................................139 15 Security Considerations...............................139 15.1 Authentication of Clients .........................139 15.2 Offering a Choice of Authentication Schemes .......140 15.3 Abuse of Server Log Information ...................141 15.4 Transfer of Sensitive Information .................141 15.5 Attacks Based On File and Path Names ..............142 15.6 Personal Information ..............................143 15.7 Privacy Issues Connected to Accept Headers ........143 15.8 DNS Spoofing ......................................144 15.9 Location Headers and Spoofing .....................144 16 Acknowledgments.......................................144 17 References............................................146 18 Authors' Addresses....................................149 19 Appendices............................................150 19.1 Internet Media Type message/http ..................150 19.2 Internet Media Type multipart/byteranges ..........150 19.3 Tolerant Applications .............................151 19.4 Differences Between HTTP Entities and MIME Entities...........................................152 19.4.1 Conversion to Canonical Form ...................152 19.4.2 Conversion of Date Formats .....................153 19.4.3 Introduction of Content-Encoding ...............153 19.4.4 No Content-Transfer-Encoding ...................153 19.4.5 HTTP Header Fields in Multipart Body-Parts .....153 19.4.6 Introduction of Transfer-Encoding ..............154 19.4.7 MIME-Version ...................................154 19.5 Changes from HTTP/1.0 .............................154 19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses .................................155 19.6 Additional Features ...............................156 19.6.1 Additional Request Methods .....................156 19.6.2 Additional Header Field Definitions ............156 19.7 Compatibility with Previous Versions ..............160 19.7.1 Compatibility with HTTP/1.0 Persistent Connections............................................161 1 イントロダクション 1.1 目的 Hypertext Transfer Protocol (HTTP) は共同的ハイパーメディア情報配布システムのた めのアプリケーションレベルプロトコルである。HTTP は 1990 から World-Wide Web グ ローバルインフォメーションイニシアティブによる使用によって存在している。HTTP/0.9 と呼ばれる HTTP の最初のバージョンはインターネット上で未加工のデータを転送するた めの簡単なプロトコルであった。RFC 1945 [6] で定義されている HTTP/1.0 は、転送デ ータに対するメタ情報とリクエスト/レスポンスセマンティクスの修飾子を含めた MIME-l ike なメッセージフォーマットを使用する事でプロトコルを改善した。しかしながら、HT TP/1.0 はプロキシ、キャッシングの階層構造と永続的な接続の必要性、仮想ホストの効 果の熟慮を十分に取っていなかった。さらに、自身を "HTTP/1.0" と称する不完全に実装 されたアプリケーションの激増により、双方の通信アプリケーションが互いに真の能力を 発揮するための適切なプロトコルバージョンの変更が必要となった。 この仕様書は "HTTP/1.1" と呼ばれるプロトコルを定義している。このプロトコルはその 機能の確実な実装を保証するため HTTP/1.0 よりもより厳格な要求を加えている。 現実的なの情報システムは単純な参照や包括的検索、front-end 更新、注釈よりもより多 くの機能性を必要としている。HTTP は要求目的を示すメソッドを開放的 (open-ended) セットにしている。これは、メソッドが適用されるリソースを示す場所 (URL) [4] や名 前 (URN) となる Uniform Resource Identifier (URI) [3][20] によって供給される参照 規律に基づいている。メッセージは Multipurpose Internet Mail Extensions (MIME) と して定義されているインターネットメールで使用されている形式に似たフォーマットで渡 される。 HTTP はユーザエージェントが SMTP [16], NNTP [13], FTP [18], Gopher[2], WAIS [10] プロトコルなどを使用している別の情報システムへのプロキシ/ゲートウェイと通信を行 うための一般的なプロトコルとしても使用される。このように、HTTP は多様なアプリケ ーションから利用できるリソースへの基本的なハイパーメディアアクセスを可能にする。 1.2 要求 この仕様書は入念な要求それぞれの意味を定義するために RFC 1123 [8] と同じ言葉を使 用している。これらの言葉は: MUST: ならない この言葉や形容詞 "必要とされる" はそのその項目が仕様書において絶対に必要であ る事を意味する。 SHOULD: すべきである この言葉や形容詞 "推奨される" はこの項目を無効とするのに妥当な理由が存在する 、特有の状況が存在するかもしれない事を意味する。しかし、完全な実装を行うのであれ ば、別の方法をとる前によく理解して状況を注意深く考えるべきである。 MAY: かもしれない, 事がある, 可能性がある この言葉もしくは形容詞 "オプション的" はこの項目が正確に任意である事を意味する 。たとえば、特有の市場がその項目を要求している場合や製品の改良のためベンダはその 項目を選ぶかもしれないし、別のベンダは同じ項目を除外するかもしれない。 もし実装したプロトコルが MUST 要求を一つでも満足していないなら、インプリメンテー ションは従順ではない。プロトコルのすべての MUST とすべての SHOULD 要求を満たして いるインプリメンテーションは "無条件に従順" と呼ばれる。プロトコルの全 MUST 要求 を満たしているが、すべての SHOULD 要求を満たしているわけではないものは "条件付き で従順である" と呼ばれる。[訳注: 日本語訳において曖昧さが生じるため、厳密な使用 は原文参照] 1.3 用語 この仕様書は HTTP 通信の参加者とオブジェクトが行う役割を表す幾つかの言葉を使用し ている。 接続 通信を目的とする二つのプログラムの間で確立されるトランスポート層仮想回路 (tra nsport layer virtual circuit)。 メッセージ 8 ビットバイト (octet) のシーケンスで構成された 4 章で定義される構文と一致す るものと、接続を経由して転送されたもので成り立つ HTTP 通信の基本ユニット。 リクエスト 5 章で定義されているような HTTP リクエストメッセージ。 レスポンス 6 章で定義されているような HTTP レスポンスメッセージ。 リソース 3.2 章で定義されている URI で識別できるネットワーク上のデータオブジェクトやサ ービス。リソースは複数の表現 (多様な言語、データフォーマット、サイズ、解像度のよ うな) もしくは別の方法で変化させて利用できるかもしれない。 エンティティ リクエストやレスポンスの結果として転送される情報。7 章で表されているように、 エンティティは entity-header フィールド形式のメタ情報や entity-body 形式の内容 ( Content) で構成される。 表現 12 章で表されるように、内容ネゴシエーションを行ったレスポンスに含まれるエンテ ィティ。詳細なレスポンスステータスに関連した複数の表現が存在するかもしれない。 内容ネゴシエーション 12 章で表されるように、あるリクエストに対してサービスを行うときに適切な表現を 選択するためのメカニズム。どのようなレスポンスのエンティティ表現もネゴシエーショ ンする事ができる (エラーレスポンスを含む)。 バリアント リソースは発生したあらゆる瞬間に、自分と関連する一つ以上の表現を持つかもしれ ない。これらの表現のそれぞれは `バリアント' と称される。`バリアント' という言葉 の使用はリソースが内容ネゴシエーションに従っている事を暗黙的に意味するというわけ ではない。 クライアント リクエスト送信の目的のため接続を確立するプログラム。 ユーザエージェント リクエストを開始するクライアント。ブラウザ、エディタ、スパイダー (ウェブをわ たるロボット) やその他のエンドユーザツールなどがある。 サーバ レスポンスを送り返して要求を実行する目的で接続を受け入れるアプリケーションプ ログラム。作成されたどのようなプログラムもクライアントとサーバの両方の機能を持つ ことができる。われわれがクライアントやサーバという言葉を使用する場合、ある接続で プログラムが行う役割のみを指し、一般的なプログラムの機能を意味するのではない。同 様に、どのようなサーバも個々のリクエストの性質に基づいて動作を変化させ、オリジン サーバ、プロキシ、ゲートウェイやトンネルの動作をすることができる。 オリジンサーバ 与えられたリソースが存在もしくは制作されるサーバ。 プロキシ 他のクライアントに代わってリクエストを作成する目的で、サーバとクライアントの 両方の動作を演じる中間プログラム。リクエストはプロキシ内部で、または可能な変換を 伴って別のサーバに渡すことで実行される。プロキシはこの仕様書のクライアントとサー バ両方を実装しなければならない。 ゲートウェイ ある別のサーバへの中継者を演じるサーバ。プロキシと違い、リクエストされたりソ ースのオリジンサーバであるかのように要求を実行する。リクエストしているクライアン トはゲートウェイと通信している事を意識する必要はない。 トンネル 二つの接続間で機械的な中継をする役割の中間プログラム。トンネルは HTTP リクエ ストにより開始されたものかもしれないが、一度活性化すると HTTP 通信の当事者とみな されない。トンネルは中継している接続の両端がクローズされたときに存在を終了する。 キャッシュ プログラムがレスポンスメッセージを保存するローカルな場所か、メッセージの保存 、検索や削除を制御するサブシステム。キャッシュは後のレスポンスタイムを減らしたり ネットワークバンド幅を減少するため、リクエストと同じ処理となるキャッシュ可能なレ スポンスを保存する。トンネルとして動作しているサーバはキャッシュを使うことができ ないが、どんなクライアントもサーバもキャッシュを含むことができる。 キャッシュ可能 もしキャッシュが次回のリクエスト応答で使用するためにレスポンスメッセージのコ ピーを保存する事が認められるならば、レスポンスはキャッシュ可能である。HTTP レス ポンスのキャッシュ可能性を決定するためのルールは 13 章で定義される。たとえリソー スがキャッシュ可能だとしても、キャッシュがあるリクエストに対してキャッシュされた コピーを使えるかどうかに追加的な制約があるかもしれない。 直接的 もしレスポンスが一つ以上のプロキシ経由によるためであろう不要な遅延なしに直接 オリジンサーバから来たなら、レスポンスは直接的 (first-hand) である。レスポンスの 正当性をオリジンサーバに直接確認した場合もレスポンスは直接的となる。 明確な満期時間 オリジンサーバが意図する、キャッシュがさらなる確証動作なしにエンティティを返 すべきではないという意味の時間。 発見的な満期時間 明確な満期時間が利用できないときにキャッシュが割り当てる満期時間。 年齢 レスポンスの年齢は、それがオリジンサーバから送られるか、正当性が首尾良く確証 されてからの時間である。 新鮮さの持続期間 レスポンスの生成時間とその満期時間の間の長さ。 新鮮 もしレスポンスの年齢がその新鮮な存在期間を超えていなければ、レスポンスは新鮮 である。 新鮮でない/古くなった もしレスポンス年齢が新鮮な存在期間を超えていれば、レスポンスは新鮮でない。 意味的に透過 リクエストしているクライアントにもサーバにもキャッシュの使用が影響を与えない とき (パフォーマンスを向上させるという効果を除いて)、キャッシュは個別のレスポン スを尊重して "意味的に透過" な態度をとる。キャッシュが意味的に透過であるとき、ク ライアントはサーバが直接処理したものと正確に同じレスポンス (hop-to-hop ヘッダを 除いて) を受け取る。 正当性確証子 キャッシュエントリがエンティティのコピーと等しいかどうかを調べるために使用さ れるプロトコル要素 (エンティティタグや Last-Modified 時刻など)。 1.4 全体的な操作 HTTP プロトコルはリクエスト/レスポンスプロトコルである。クライアントはサーバへの 接続上で、プロトコルバージョン、リクエストメソッド、URI、そしてそれらの後に続く リクエスト修飾子、クライアント情報、可能であれば内容本体の MIME-like メッセージ 形式でサーバにリクエストを送る。サーバは、メッセージのプロトコルバージョンと成功 やエラーコードを意味するステータス行に続けてサーバ情報、エンティティメタ情報、可 能であればエンティティボディ内容を含む MIME-like メッセージで応答する。HTTP と M IME の関係は付録 19.4 に記述されている。 ほとんどの HTTP 接続はユーザエージェントによって開始され、オリジンサーバ上のリソ ースに適用するリクエストで成り立つ。最も簡単な場合、ユーザエージェント (User Age nt) とオリジンサーバ (Origin Server) との間の単一接続経由で成し遂げられるだろう 。 より複雑な状況は一つ以上の仲介者がリクエスト/レスポンス連鎖に現れるときに起こる 。三つの一般的な仲介者: プロキシ、ゲートウェイそしてトンネルが存在する。プロキシ は絶対形式の URI のリクエストを受け取り、メッセージのすべてもしくは一部を書き換 え、URI によって識別されるサーバに再フォーマットされたリクエストを転送するエージ ェントである。ゲートウェイはある別のサーバ (複数かもしれない) の上の層として動作 し、もし必要ならリクエストを末端サーバのプロトコルに変換する受信エージェントであ る。トンネルはメッセージを変更する事なく二つの接続間の中継点として動作する。トン ネルは通信が (ファイアウォールのような) 仲介者を通して伝えられる必要があるときや 、仲介者がメッセージの内容を理解できないときに使用される。 上記の図はユーザエージェントとオリジンサーバの間の三つの仲介者 (A, B, C) を表し ている。連鎖全体を移動するリクエストやレスポンスメッセージは四つに分割された接続 を通して渡される。いくつかの HTTP 通信オプションは (非トンネルの) 隣接にのみ、連 鎖の端末点にのみ、そして連鎖上のすべての接続に適用できるため、この区別は重要であ る。ダイアグラムは線形であるがそれぞれの当事者は複数同時通信を行う事ができる。た とえば、B は A のリクエストを処理すると同時に、 A 以外のたくさんのクライアントか らリクエストを受信しているかもしれないし、C 以外のサーバにリクエストを転送してい るかもしれない。 トンネルとして動作していない通信のすべての当事者は内部的なキャッシュやリクエスト 処理を使用できる。もし連鎖上の当事者の一つがそのリクエストに適用できるキャッシュ されたレスポンスを持っているなら、キャッシュはリクエスト/レスポンス連鎖を短くす るの効果をもつ。もし B が Origin Server から C を経由して来た、以前の (User Agen t や A にキャッシュされていない) レスポンスのキャッシュコピーを持っているなら、 以下はその結果となる連鎖を説明している。 すべてのレスポンスが有効にキャッシュ可能というわけではなく、いくつかのリクエスト はキャッシュの動作に特別な要求を行う修飾子を含む事ができる。キャッシュの動作やキ ャッシュ可能なレスポンスに対する HTTP の要求は 13 章で定義されている。 事実、現在 World Wide Web 上で実験されて配置されているキャッシュとプロキシのアー キテクチャやコンフィギュレーションは幅広い多様性を持つ。これらのシステムは国際通 信でバンド幅を節約するためのプロキシキャッシュの国際間階層や、キャッシュエンティ ティのブロードキャスト・マルチキャストを行うシステム、キャッシュされたデータのサ ブセットを CD-ROM で配布する組織などを含んでいる。HTTP システムは高バンド幅通信 の社内イントラネット上で、そして非力なラジオ通信や断続的な接続を使う PDA 経由の アクセスで使用される。HTTP/1.1 の目的は、高い信頼性と、通信に失敗するなら少なく とも失敗の確実な指示が必要となるウェブアプリケーションを構築する人々のニーズに合 うプロトコル構造を導入する事であるが、同時に既に設置されている構成の広い多様性を サポートする事でもある。 HTTP 通信は常に TCP/IP 接続上で行う。デフォルトポートは TCP 80 であるが、他のポ ートを使用する事もできる。これは HTTP がインターネットや他のネットワーク上で別の プロトコルの最上部として実装されるのを妨害しない。HTTP は確実な転送のみを前提と する。そのような保証を供給するどんなプロトコルでも使用できる。この問題でプロトコ ルのデータ転送単位の HTTP/1.1 リクエストとレスポンスのマッピングはこの仕様書の範 囲外である。 HTTP/1.0 において、ほとんどのインプリメンテーションは個々のリクエスト/レスポンス 交換のために新しい接続を使用していた。HTTP/1.1 では、接続を一つ以上のリクエスト/ レスポンス交換に使用できるが、レスポンスの種類によっては接続がクローズされるかも しれない (8.1 章参照)。 2 表記法的慣習と一般文法 2.1 拡張 BNF このドキュメントにおいて詳述されるメカニズムのすべては、単調 Backus-Naur Form (B NF) と 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 baf]" は "*1(foo bar)" と等しい。 N rule 具体的な繰り返し: "(element)" は "*(element)" と等しい。これは、(ele ment) が正確に 存在する。従って 2DIGIT は二つの数字であり、3ALPHA は三つのア ルファベット文字の文字列である。 #rule "*" と類似した "#" 構造は要素のリストを定義するために定義されている。完全な形 式は element 最低 、最大 の存在を示している "#element" であり、それ ぞれは一つ以上のコンマ (",") と省略可能な連続空白 (LWS) で区切られる。これは普通 とても簡単にリストのフォームを作る。"( *LWS element *(LWS "," *LWS element))" の ルールは "1#element" として表す事ができる。この構造が使用されているどこでも、nul l 要素が許されるが、与えられた要素の数に影響しない。"(element), , (element)" は 許されるが、二つの要素として数えられる。それゆえ、最低一つの要素が必要とされると ころでは最低一つの null でない要素が与えられなければならない。デフォルト値は 0 と無限である。"#element" はゼロを含むどんな数も認め、"1#element" は最低一つを必 要とし、"1#2element" は一つか二つを認めている。 ; comment ルールテキストの右からある距離を置いて始まるセミコロンは、行末まで続くコメン トを開始している。これはこの仕様書で平行した有用な記述を加えるための簡単な方法で ある。 implied *LWS この仕様書によって記述される文法は word-based である。別の方法で明記していな ければ、連続した空白 (LWS) はフィールドの解釈を変更しないで二つの隣接した言葉 ( トークンや quoted-string) の間や隣接したトークンとデリミタ (tspecials) の間に追 加する事ができる。二つのトークンの間にはそれらが単一のトークンとして解釈されない ように最低一つのデリミタ (tspecials) が存在しなければならない。 2.2 基本ルール 以下のルールは基本的な構造説明を記述するためこの仕様書全体に渡って使用されている 。文字セットとしてコード化された US-ASCII は ANSI X3.4-1986[12] で定義されている 。 OCTET = <データの 8-bit シーケンスすべて> CHAR = <すべての US-ASCII 文字 (8 ビットバイト 0 - 127)> UPALPHA = <すべての US-ASCII 大文字 "A".."Z"> LOALPHA = <すべての US-ASCII 小文字 "a".."z"> ALPHA = UPALPHA | LOALPHA DIGIT = <すべての US-ASCII 数字 "0".."9"> CTL = <すべての US-ASCII 制御文字 (8 ビットバイト 0 - 31) と DEL (127)> CR = LF = SP = HT = <"> = HTTP/1.1 はエンティティボディ以外のすべてのプロトコル要素に対する行末として CR L F シーケンスを定義している (耐性のあるアプリケーションのための付録 19.3 章参照) 。エンティティボディ内の行末マーカーは 3.7 章で記述されているように、その関連す るメディアタイプによって定義される。 CRLF = CR LF HTTP/1.1 ヘッダは続く行が空白か水平タブで開始しているなら複数行にまたがって折り 返す事ができる。折り返しているものを含むすべての連続空白は SP と同じ意味を持つ。 LWS = [CRLF] 1*( SP | HT ) TEXT ルールはメッセージパーサーによって解釈されるのを目的とする説明的なフィール ドの内容と値にのみ使用される。*TEXT の言葉は、RFC 1522 [14] のルールにしたがって エンコードされたときのみ、ISO-8859-1 [22] 以外の文字セットの文字を含む事ができる 。 TEXT = 16 進数文字はいくつかのプロトコル要素において使用される。 HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 多くの HTTP/1.1 ヘッダフィールド値は LWS か特別な文字によって区切られた言葉から 成り立つ。これらの特別な文字がパラメータ値内で使用されるためには引用された文字列 内に存在しなければならない。 token = 1* tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT コメントは、いくつかの HTTP ヘッダ内でコメント文字を括弧で囲む事により加える事が できる。コメントは、それらのフィールド値定義の一部として "comment" を含んでいる フィールドにおいてのみ許される。その他のすべてのフィールドにおいては、括弧はフィ ールド値の一部とみなされる。 comment = "(" *( ctext | comment ) ")" ctext = <"(" と ")" を含むすべての TEXT> テキストの文字列はダブルクォート記号を使って引用されているなら、単一の言葉として 解析される。 quoted-string = ( <"> *(qdtext) <"> ) qdtext = < <"> 以外のすべての TEXT> バックスラッシュ文字 ("\") は quoted-string と comment 構造内でのみ単一文字引用 メカニズムとして使用されるだろう。 quoted-pair = "\" CHAR 3 プロトコルパラメータ 3.1 HTTP バージョン HTTP はプロトコルのバージョンを含むる "." 番号スキームを使用する。 プロトコルのバージョン付け処理は、この転送を使って得られる機構というよりも、サー バに対してメッセージのフォーマットを示したり、今後の HTTP 転送を理解する為の能力 を表す。転送動作に影響を及ぼさなかったり、拡張可能なフィールド値を追加するだけの メッセージ構成要素の追加に対して、バージョン番号のどんな変更も行われない。 番号はプロトコルによってなされる変更が一般的なメッセージ解析アルゴリズムを変更 しない機能を追加するときに増やされるが、これはメッセージセマンティクスを追加し、 送り側の追加的な性能を暗黙的に意味するだろう。 番号はプロトコル内のメッセ ージのフォーマットが変更されるときに増やされる。 HTTP メッセージのバージョンはメッセージの最初の行の HTTP-Version フィールドで示 される。 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT メジャー番号とマイナー番号は分割した整数値として扱われるべきであり、一文字以上に 増やされる事に注意する。従って、HTTP/12.3 よりも順序的に下となる HTTP/2.4 は HTT P/2.13 よりも下のバージョンである。先行するゼロは受け取り側によって無視されなけ ればならず、送られてはならない。 この仕様書により定義されるような Request や Response メッセージを送るアプリケー ションは "HTTP/1.1" の HTTP-Version を含まなければならない。このバージョン番号の 使用は送り側のアプリケーションが少なくとも条件付きでこの仕様書に準じていると言う 事を示す。 アプリケーションの HTTP バージョンはアプリケーションが少なくとも条件付きで準じて いる最も高い HTTP バージョンである。 プロキシとゲートウェイアプリケーションはプロトコル上で転送するバージョンの違うメ ッセージに注意しなければならない。プロトコルバージョンは送り側のプロトコル機能を 示すため、プロキシ/ゲートウェイは決して実際のバージョンよりも大きなバージョン指 標が付いたメッセージを送ってはならない。もしより高いバージョンのリクエストを受け たなら、エラーを返すか、トンネル動作にスイッチする。そのプロキシ/ゲートウェイの バージョンよりも低いバージョンのリクエストは転送される前にアップグレードできる。 そのリクエストのプロキシ/ゲートウェイのレスポンスはリクエストと同じメジャーバー ジョンでなければならない。 注意: HTTP のバージョン間の変換は含まれるバージョンによって要求されるか禁止され ているヘッダフィールドの修正を含んでいる。 3.2 Uniform Resource Identifiers URI は多くの名前: WWW address, Universal Document Identifier, Universal Resource Identifier 最終的には Universal Resource Locator(URL) と Name(URN) で既に知られ ている。HTTP が関心を持たれる限り、Uniform Resource Identifier は 名前、ロケーシ ョンやその他の特徴で リソースを識別する簡単にフォーマットされた文字列である。 3.2.1 一般構文 HTTP における URI は、絶対形式か当事者たちが置かれている状況に依存する幾つかの既 知 URI の相対形式で表される。二つの形式は絶対形式の URI が常にコロンを後に持つス キーム名で開始しているという事実により区別される。 URI = ( absoluteURI | relativeURI ) [ "#" fragment ] absoluteURI = scheme ":" *( uchar | reserved ) relativeURI = net_path | abs_path | rel_path net_path = "//" net_loc [ abs_path ] abs_path = "/" rel_path rel_path = [ path ] [ ";" params ] [ "?" query ] path = fsegment *( "/" segment ) fsegment = 1*pchar segment = *pchar params = param *( ";" param ) param = *( pchar | "/" ) scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) net_loc = *( pchar | ";" | "?" ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | ":" | "@" | "&" | "=" | "+" uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national escape = "%" HEX HEX reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" extra = "!" | "*" | "'" | "(" | ")" | "," safe = "$" | "-" | "_" | "." unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" national = URL 構文や意味の定義的な情報は RFC 1738 [4] と RFC 1808 参照。HTTP サーバはアド レスの rel_path 部分を表す事のできる予約されていない文字セットにおいて制限されて いないし、HTTP プロキシは RFC 1738 で定義されていない URI のリクエストを受信でき るかもしれないため、この上記の BNF は RFC 1738 のよって示されているような正当な URLに入る事を許されていない国際文字を含む。 HTTP プロトコルは URI の優先的な長さに関してどんな制限も設けていない。サーバは当 事者たちが送付してくるどんなリソースの URI も処理できなければならなず、もしその ような URI を生成する GET ベースのフォームを用意するなら、無制限の長さの URI を 処理できるべきである。もし URI がサーバが処理できる限界 (10.4.15 章参照) よりも 長いなら 414 (Request-URI Too Long) ステータスを返すべきである。 注意: サーバは古いクライアントやプロキシ実装が 255 バイトを超える長さを適切にサ ポートしていないかもしれないため、そのような長さの URI への依存に関して注意すべ きである。 3.2.2 http URL "http" スキームは HTTP プロトコル経由でネットワークリソースの位置を定めるために 使用される。このセクションでは http URL に対するスキーム記述構文とセマンティクス を定義している。 http_URL = "http:" "//" host [ ":" port ] [ abs_path ] host = port = *DIGIT もし port が空であったり省略されていれば、ポート 80 が仮定される。そのセマンティ クスは、識別するリソースがそのホストのそのポートで TCP 接続のための接続待ちをし ているサーバの場所を特定し、リソースに対する Request-URI は abs_path である。可 能であれば URI での IP アドレスの使用は避るべきである (RFC 1900 [24] 参照)。もし abs_path が URI で与えられなければ、リソースに対する Request-URI として使われる とき "/" として与えられなければならない (5.1.2 章)。 3.2.3 URI の比較 もし二つの URI が一致しているかどうかを判別するためそれらを比較するなら、クライ アントは以下を例外として URI 全体の大文字と小文字を区別した 8 ビットバイト同士を 比較すべきである: * 与えられた空やそうでない部分がその URI のデフォルト部分と等価である。 * ホスト名の比較は大文字小文字を区別してはならない。 * スキーム名の比較は大文字と小文字を区別してはならない。 * 空の abs_path は "/" の abs_path と等価である。 これら以外の "予約された" もしくは "危険な" セット (3.2 章参照) 文字はそれらの " "%" HEX HEX" エンコーディングと等しい。 たとえば、以下の三つの 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, RFC 1123 で改定された Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, RFC 1036 により時代遅れ Sun Nov 6 08:49:37 1994 ; ANSI C の asctime() フォーマット 最初のフォーマットはインターネット標準としてより好まれ、RFC 1123 (RFC822 の改定) で定義されている物の固定長サブセットに相当する。第二のフォーマットは一般的に使用 されているが、時代遅れの RFC 850 [12] 日付フォーマットをベースにし、4 桁年号が欠 落している。日付の値を解析する HTTP/1.1 クライアントとサーバは (HTTP/1.0 との互 換性のため) 三つすべてのフォーマットを受け入れなければならないが、それらがヘッダ フィールドで HTTP-date 値を表す時には RFC 1123 フォーマットのみを使用しなければ ならない。 注意: 日付の値の受取側は、しばしば SMTP や NNTP のプロキシ/ゲートウェイを経由し て受送信されたメッセージを考慮して、非 HTTP アプリケーションによって送られるであ ろう日付の値を受け入れるような強固さを持つ事が推奨される。 すべての HTTP 日付/時刻スタンプは例外を除いてグリニッジ標準時刻 (GMT)で表されな ければならない。これはタイムゾーンに対する三文字略として"GMT" の包括によって最初 の二つのフォーマットで示され、asctime フォーマットの解釈のときに仮定されなければ ならない。 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 のために表されているような "文字セット" 用語と同じ定義を使用する: "文字セット" 用語はこのドキュメントで 8 ビットバイトシーケンスを文字シーケンスに 変換するための一つ以上のテーブルで使用される方法を提示するために使用されている。 すべての文字が与えられた文字セットで利用できるわけではなかったり、固有の文字を表 すため文字セットが一つ以上の 8 ビットバイトシーケンスを供給する場合において、別 の指示で無条件な変換が必要でない事に注意。この定義は US-ASCII のような簡単な単一 テーブルマッピングから、ISO 2022 の技術を使うような複雑なテーブルをスイッチする 方法まで、さまざまな種類の文字エンコーディングを認める目的を持つ。しかしながら、 MIME 文字セット名に関連したこの定義は 8 ビットバイトから文字に行われるマッピング を完全に詳述しなければならない。特に、正確なマッピングを決定するための外部のプロ フィール情報の使用は許されない。 注意: この "文字セット" 用語の使用は "文字エンコーディング" としてより一般的に参 照されている。しかしながら、HTTP と MIME が同じ登録を共有しているため、用語も共 有される事が大切である。 HTTP 文字セットは大文字と小文字を区別しないトークンによって識別される。トークン の完全セットは IANA Character Set 登録機構 [19] によって定義される。 charset = token とはいえ、HTTP は文字値として使用される任意のトークンを認めている。IANA Characte r Set 登録機構によって定義済みの値を持つどんなトークンもその登録機構で定義された 文字セットを表さなければならない。アプリケーションは文字セットのそれらの使用に I ANA 登録機構により定義されたこれらを制限すべきである。 3.5 内容コーディング 内容コーディング値はエンティティに適用されているもしくは適用できるエンコーディン グ変換を示す。内容コーディングは、その根本的なメディアタイプのアイデンティティを 失ったり情報の欠落がおこなわれないで、圧縮されたり別の有用な変換が行われたドキュ メントを許可するために使用される。しばしば、エンティティはコード化された形態で保 存され、直接転送され、受け取り側によってのみデコードされる。 content-coding = token すべての content-coding 値は大文字と小文字を区別しない。HTTP/1.1 は Accept-Encod ing (14.3 章) と Content-Encoding (14.12 章) ヘッダフィールドにおいて content-co ding 値を使用する。値が 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" フォーマット。 新しい conetnt-coding 値トークンが登録されるべきである。クライアントとサーバの間 での内部操作性を認めるため、新しい値を実装する必要のある内容コーディングアルゴリ ズムの仕様は公的に利用でき独立したインプリメンテーションに適し、この章で定義され た内容コーディングの目的に従うべきである。 3.6 転送コーディング 転送コーディング値はネットワークを通して "安全な転送" を保証するためエンティティ ボディに適用されている、される事のできる、する必要のあるエンコーディング変換を示 す。これは転送コーディングが元のエンティティではなくメッセージの特性である内容エ ンコーディングとは異なる。 transfer-coding = "chunked" | transfer-extension transfer-extension = token すべての transfer-encoding 値は大文字小文字を区別しない。HTTP/1.1 は Transfer-En coding ヘッダフィールド (14.40 章) で転送コーディング値を使用している。 転送エンコーディングは MIME の Content-Transfer-Encoding 値と類似している。これ は 7-bit 転送サービス上でバイナリデータの安全な転送を可能にするために設計されて いる。しかしながら、安全な転送の焦点は完全な 8 bit転送プロトコルに対して異なる。 HTTP では、メッセージボディに特有の危険さは、明確なボディ長 (7.2.2 章) を決定す る事が困難なことや、共有された転送経路上でデータの暗号化を望む事だけである。 chunked エンコーディングは、それぞれエンティティヘッダフィールドを含んでいるオプ ション的なフッタが続くそれ自身のサイズ指標をつけて、チャンクの連続としてそれを転 送するためにメッセージのボディを修正する。これは、受取人が全メッセージを受信した 事を確かめるための必要な情報とともに転送される動的に生成された内容を認めている。 Chunked-Body = *chunk "0" CRLF footer CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF hex-no-zero = chunk-size = hex-no-zero *HEX chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) footer = *entity-header chunked エンコーディングはサイズがゼロにされたチャンクとそれに続くフッタにより終 了する。これは空行によって終わる。フッタの目的は動的に生成されたエンティティに付 いての情報を供給するための効果的な方法を備える事である。アプリケーションは、電子 署名や別の機能のための Content-MD5 や HTTP の将来的な拡張のように、フッタに対し て適切であるようなものとして明白に定義されていないフッタのヘッダフィールドを送っ てはならない。 Chunked-Body デコーディングのための例題過程は付録 19.4.6 で紹介されている。 すべての HTTP/1.1 アプリケーションは "chunked" 転送コーディングを受信しデコード できなければならず、それらが理解できない転送コーディング拡張は無視されなければな らない。理解できない transfer-coding 付きのエンティティボディを受信したサーバは 501 (Unimplemented) を返して接続を閉じるべきである。サーバは HTTP/1.0 クライアン トに転送エンコーディングを送ってはならない。 3.7 メディアタイプ HTTP は Content-Type (14.18 章) と Accept (14.1 章) ヘッダフィールドにおいてオー プンや拡張データタイプ定義やタイプネゴシエーションを供給するために Internet Medi a Type を使用する。 media-type = type "/" subtype *( ";" parameter ) type = token subtype = token パラメータは attribute/value ペアの形態で タイプ/サブタイプ が続くであろう。 parameter = attribute "=" value attribute = token value = token | quoted-string タイプ、サブタイプやパラメータ属性名は大文字と小文字を区別しない。パラメータ値は パラメータ名のセマンティクスに依存して大文字小文字の区別が行われるであろう。連続 した空白文字 (LWS: Linear white space) はタイプとサブタイプの間や属性とその値の 間で使われてはならない。メディアタイプを識別するユーザエージェントはユーザに検知 したどんな問題も知らせるため、この type/subtype 定義により表されるような MIME タ イプに対するパラメータを処理 (もしくはユーザエージェントによりこの type/subtype を処理するために使われるどんな外部アプリケーションにも処理されるように) しなけれ ばならない。 注意: 幾つかの古い HTTP アプリケーションはメディアタイプパラメータを認識しない。 この時、古い HTTP アプリケーションにデータを送るため、インプリメンテーションはそ れらがこの type/subtype 定義により要求されるときのみメディアタイプを使用すべきで ある。 メディアタイプ値は Internete Assigned Number Authority (IANA) によって登録される 。メディアタイプ登録手続きは RFC 2048 [17] において概説されている。登録されてい ないメディアタイプの使用は慎むべきである。 3.7.1 公式化とテキストデフォルト インターネットメディアタイプは公式の形式で登録される。一般的には、HTTPメッセージ 経由で転送されるエンティティボディはその転送に前述の適切な公式形式で表されなけれ ばならない。例外は次のパラグラフで定義されるような "text" タイプである。 公式形式において、"text" タイプのメディアサブタイプはテキスト行末に CRLF を使う 。HTTP はこの要求をゆるめ、それがエンティティボディ全体に対して一貫ししていると き、行末を表すのに単独の CR や LF をつけたテキストメディアの転送を認めている。HT TP アプリケーションは HTTP 経由で受信されるテキストメディアにおいて行末表現であ るものとして CRLF, CR や LF を受け入れなければならない。追加として、もしテキスト が、幾つかのマルチバイト文字セットに対する場合であるように、CR と LF それぞれに 対して8 ビット文字 13 と 10 が使われていないような文字セットに相当するならば、HT TP は行末の CR と LF の評価を表すためのこの文字セットによって定義されているどん な 8 ビット文字の使用をも認める。行末に関するこの柔軟性はエンティティボディのテ キストメディアにのみ適用される。単独の CR や LF は HTTP 制御構造 (ヘッダフィール ドやマルチパート境界など) のすべてにおいて CRLF に置き換えられてはならない。 もしあるエンティティボディが Content-Encoding でエンコードされているならば、根本 的なデータはエンコードされるために上記で定義される形態とならなければならない。 "charset" パラメータはデータの文字セット (3.4 章) を定義するための、幾つかのメデ ィアタイプで使用されている。明確な charset パラメータが送り側から供給されない場 合、"text" タイプのメディアサブタイプは HTTP 経由でそれが受信されるときデフォル トの "ISO-8859-1" の charset 値を持つと定義される。"ISO-8859-1" やそのサブセット 以外の文字セットにおけるデータは適切な charset 値付きでラベル付けされなければな らない。 幾つかの HTTP/1.0 ソフトウェアは charset パラメータを使っていない Content-type ヘッダを "受取人が推測する" を意味するものとして間違って中間処理している。この振 る舞いを無効にする事を望む送り側は charset が ISO-8859-1 であるような charset を 含んでも良く、それが受取人を混乱させないであろうという事を知っている場合にはその ようにすべきである。 不幸にも、幾つかの古い HTTP/1.0 クライアントは明白な charset パラメータを適切に 処理していない。HTTP/1.0 の受け取り側は送り側によって供給される charset ラベルを 尊重しなければならない。そして charset を "推測する" 準備のあるユーザエージェン トは、もしそれらがその charset をサポートしているならば、ドキュメントを最初に表 示するときに受取人の好みよりも Content-Type フィールドからの charset を使わなけ ればならない。 3.7.2 マルチパートタイプ MIME は "multipart" タイプ 単一の message-body の中への一つ以上のエンティティの カプセル化を幾つかを備えている。MIME [7] で定義されているように、すべてのマルチ パートタイプは共通の構文を割り当て、メディアタイプ値の一部として境界パラメータを 含まなければならない。メッセージボディはそれ自身プロトコル要素の一部であり、それ ゆえ body-parts 間の行末を表すために CRLF のみを使用しなければならない。MIME と 違い、どのマルチパートメッセージのエピローグも空でなければならない。HTTP アプリ ケーションは (たとえ元のマルチパートがエピローグを含んでいても) エピローグを伝え てはならない。 HTTP では、マルチパート body-parts はその部分の意味に重要な意義を持つヘッダフィ ールドを含むかもしれない。Content-Location ヘッダフィールド (14.15 章) は URL に よって識別されうるそれぞれの同封されたエンティティの body-part において含まれる べきである。 一般的には、HTTP ユーザエージェントは MIME ユーザエージェントがマルチパートタイ プの受領上でするであろうと同じまたは似たような振る舞いに習うべきである。アプリケ ーションが認識されないマルチパートサブタイプを受け取ったなら、アプリケーションは それを "multipart/mixed" に相当するものとして扱わなければならない。 注意: "multipart/form-data" タイプは RFC 7867 [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 内容ネゴシエーション (12 章) はさまざまな交渉可能なパラメータの相対的な重要 性 ("ウェイト") を示す短い "浮動小数点" 数を使う。ウェイトは実数値 0 から 1 まで に標準化され、0 は最小値で 1 は最大値である。HTTP/1.1 アプリケーションは小数点以 下の 3 つの数字以上を生成してはならない。これらの値のユーザ設定もこの様式にかぎ られるべきである。 qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] ) "Quality value" はそれらの値が単に要請される特質の相対的な格付けを示すため誤称で ある。 3.10 言語タグ 言語タグは別の人間との情報コミュニケーションのため、人間によって話されたり書かれ たり、別の方法で伝えられる自然言語を識別する。コンピュータ言語は明らかに除外され る。HTTP は Accept-Language や Content-Language フィールドにおいて言語タグを使用 する。第一の言語タグと空でも良いサブタグの連続である。 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 タグは登録されていない タグである; しかし最後のすべては将来的に登録されるかもしれないタグの例である。) 3.11 エンティティタグ エンティティタグは要求された同じリソースからの二つ以上のエンティティを比較するた めに使用される。HTTP/1.0 は ETag (14.20 章)、If-Match (14.25章)、If-None-Match ( 14.26 章)、及び If-Range (14.27 章) ヘッダフィールドでエンティティタグを使用する 。それらがどのよう使われ、キャッシュが正しいと確認するものとして比較されるかの定 義は 13.3.3 章で成される。エンティティタグはひょっとすると weakness インジケータ が前方に付く、非空白の引用文字列とみなされるかもしれない。 entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string "string entity tag" はもしそれらが 8 ビット文字と等価とみなされるときのみリソー スの 2 つのエンティティによって分けられるであろう。 "W/" プレフィクスによって示される "weak entity tag" はエンティティが等価でありセ マンティクスにおいてそれぞれ重要な変更がないそれぞれを用いる事ができるときのみ、 リソースの 2 つのエンティティによって分けられる。weak エンティティタグは不十分な 比較に対してのみ使用される。 エンティティタグは特有のリソースと結び付けられたすべてのエンティティのすべてのバ ージョンを超えてユニークでなければならない。与えられたエンティティタグの値はそれ らのエンティティの等価性に付いてすべてを暗に意味することなしに異なる URI での要 求によって得られるエンティティに対して使用されうる。 3.12 レンジユニット HTTP/1.1 はクライアントに、レスポンス内に含まれるレスポンスエンティティの (範囲 の) 一部だけリクエストする事を可能にしている。HTTP/1.1 は Range (14.36 章) と Co ntent-Range (14.17 章) においてレンジユニットを使用する。エンティティはさまざま な構造上のユニットにしたがったサブレンジのなかで分解されるだろう。 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 要求 (5 章) と応答 (6 章) メッセージはエンティティ転送 (メッセージの負担荷重) の ため RFC 822 [9] の一般的なメッセージフォーマットを使用する。メッセージの両方の タイプは一つの開始行、一つ以上のヘッダフィールド(ヘッダとしても知られる)、ヘッダ フィールドの終了を示す (CRLF の前に何もない行のような) 空行、そして任意のメッセ ージボディからなる。 generic-message = start-line *message-header 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 メッセージヘッダ 一般ヘッダ (4.5 章)、レスポンスヘッダ (6.2 章)、及びエンティティヘッダ(7.1 章) を含む HTTP ヘッダフィールドは RFC 822 [9] の 3.1 章で与えられているもとの同じ一 般的なフォーマットに従う。それぞれのヘッダフィールドはコロン (":") が後に続く名 前とフィールド値から成る。フィールド名は大文字と小文字を区別しない。フィールド値 は、一つの SP が好まれるが、幾つかの LWS を先頭に付ける事もできる。ヘッダフィー ルドは最低一つ以上のSP や HT をそれぞれの行頭につける事で複数行にまたがる事がで きる。アプリケーションは、共通形式を超えたあらゆるものの受け入れに失敗する幾つか のインプリメンテーションが存在するであろうため、HTTP 構造を生成するとき "共通形 式" に従うべきである。 message-header = field-name ":" [ field-value ] CRLF field-name = token field-value = *( field-content | LWS ) field-content = 異なるフィールド名を持つヘッダフィールドの受信される順序は重要性を持たない。しか しながら、リクエストヘッダやレスポンスヘッダに先立って一般ヘッダフィールドを最初 に送りエンティティフィールドを最後にする事が "良い慣例" である。 同じフィールド名を持つ複合メッセージヘッダフィールドは、そのようなヘッダフィール ドに対するエンティティフィールド値がコンマで区切られたリスト[#(value) のような] として定義される場合、かつその場合にのみ、メッセージに存在しうる。コンマによって それぞれ分けられるそれぞれの続く field-value を最初に追加する事により、メッセー ジのセマンティクスを変える事無しにある "header-name: header-value" ペアでの複合 ヘッダフィールドを結合する事が可能でなければならない。それゆえ同じフィールド名を 持つヘッダフィールドが受信される順番は、連結されたフィールド値の中間処理に重要で あり、したがってプロキシはメッセージが転送されるときにそれらのヘッダ値の順番を変 えてはならない。 4.3 メッセージボディ HTTP メッセージの message-body はリクエストやレスポンスに関連するentity-body を 運ぶために使用される。message-body は Transfer-Encodingヘッダフィールド (14.40 章) によって示された転送コーディングが適用されたときのみ entity-body とは異なる 。 message-body = entity-body | Transfer-Encoding はアプリケーションにより安全を保障しメッセージのふさわしい転送 を行うために適用されるすべての転送コーディングを示すために使用される。Transfer-E ncoding はそのメッセージの性質であり、エンティティの性質ではない。したがってそれ はリクエスト/レスポンス連鎖に伴うすべてのアプリケーションによって追加されたり削 除されたりされうる。 message-body がメッセージにおいてみとめられるようなルールはリクエストとレスポン スの違いではない。 リクエストにおける message-body の存在はリクエストの message-headerでの Content- Length や Transfer-Encoding ヘッダフィールドの抱合によって伝えられる。message-bo dy はリクエストメソッド (5.1.1 章) がentity-body を許可しているときのみリクエス トに含まれるであろう。 レスポンスメッセージに対して、message-body がメッセージに含まれているかどうかは リクエストメソッドとレスポンスステータスコード (6.1.1 章) の両方に依存する。HEAD リクエストメソッドのどんなレスポンスも、たとえentity-header フィールドがそうであ るように導いていたとしても、message-body を含んではならない。1xx (Information)、 204 (no content)、及び304 (not modified) レスポンスのどれも message-body を含ん ではならない。他のすべてのレスポンスは長さがゼロである以外は message-bodyを含む 。 4.4 メッセージの長さ message-body がメッセージに含まれるとき、このボディの長さは以下の一つで決定され る。 1. message-body を含んではいけない (1xx, 204, 304 レスポンスや HEAD リクエス トに対するすべてのレスポンス) すべてのレスポンスメッセージは entity-header フ ィールドがメッセージにおいて与えられるてもヘッダフィールドの後の最初の空行で常 に終了する。 2. もし Transfer-Encoding ヘッダフィールド (14.40 章) が与えられ、"chunked" 転送コーディングが適用されているようならば、長さは chunked エンコーディング (3 .6 章) によって定義される。 3. もし Content-Length ヘッダフィールド (14.14 章) が与えられるなら、そのバ イト値は message-body の長さを示す。 4. もしメッセージが自身で区切りを持つメディアタイプ "multipart/byteranges" を使うなら、これはその長さを定義する。このメディアタイプは、受取人が それを解 析できる事を送り側が知っている事無しに使用されてはならない。リクエストにおける マルチバイト幅指定子付きの Range ヘッダの存在は、クライアントが multipart/byte range レスポンスを解析できる事を暗黙的に意味する。 5. 接続を閉じるサーバによる。(接続を閉じる事はリクエストボディの終了を使用す るために使う事ができない。これはサーバがレスポンスを送り返す可能性がないであろ う為である。) HTTP/1.0 アプリケーションの互換性のため、message-body を含む HTTP/1.1リクエスト は、サーバが HTTP/1.1 に準じていると分かっている場合を除いて有効な Content-Lengt h ヘッダフィールドをを含まなければならない。もしmessage-body と Content-Length を含んでいるリクエストが与えられなければ、サーバはメッセージの長さが決定できない とき 400 (bad request) や有効な Content-Length を受信する事を要求するなら 411 (l ength required)を返すべきである。 エンティティを受け取るすべての HTTP/1.1 アプリケーションは "chunked"転送エンコー ディング (3.6 章) を受け入れなければ成らず、したがってメッセージ長が前もって決定 されていないときメッセージに対して使用されるこのメカニズムを認めなければならない 。 メッセージは Content-Length ヘッダフィールドと "chunked" 転送エンコーディングの 両方を含んではならない。もし両方が受信されたら、Content-Length が無視されなけれ ばならない。 Content-Length が、message-body が認められるメッセージにおいて与えられたとき、そ のフィールド値は message-body における 8 ビット文字の数と正確に一致しなければな らない。HTTP/1.1 ユーザエージェントは不正な長さが受信されたり検出されたとき通知 しなければならない。 4.5 一般ヘッダフィールド リクエストとレスポンスメッセージの両方のための一般的な適用性を持つ幾つかのヘッダ フィールドがあるが、これは転送されたエンティティには適用されない。これらのヘッダ フィールドは伝えられているメッセージに対してのみ適用される。 general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.19 | Pragma ; Section 14.32 | Transfer-Encoding ; Section 14.40 | Upgrade ; Section 14.41 | Via ; Section 14.44 一般ヘッダフィールド名はプロトコルバージョンにおける変換に伴う連動においてのみ確 実に拡張される事ができる。しかしながら、新しいヘッダフィールドや実験的なヘッダフ ィールドは、もしコミュニケーションにおけるすべてのパーティがそれらを一般ヘッダフ ィールドであると認識できるなら、一般的なヘッダフィールドのセマンティクスが与えら れるであろう。認識されないヘッダフィールドは entity-header フィールドとして扱わ れる。 5 リクエスト メッセージの最初の行内のクライアントからサーバへのリクエストメッセージはリソース に適用されるメソッド、リソースの識別子、使用されているプロトコルのバージョンを含 んでいる。 Request = Request-Line ; Section 5.1 *( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) ; Section 7.1 CRLF [ message-body ] ; Section 7.2 5.1 リクエスト行 Request-Line は Request-URI とプロトコルバージョンが後にく続メソッドトークンで開 始し CRLF で終了する。最後の CRLF シーケンス以外の CR もLF もみとめられない。 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 5.1.1 メソッド Method トークンは 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 | extension-method extension-method = token リソースにより認められるメソッドのリストは Allow ヘッダフィールド (14.7 章) で記 述される。レスポンスのリターンコードは、許されるメソッドのセットが動的に変化でき るため、メソッドが現在リソースに許されていてもいなくても常にクライアントに伝えら れる。もしサーバがメソッドを理解できても要求されたリソースに対して許されていなけ れば、サーバはステータスコード 405 (Method Not Allowed) を返すべきであり、もしサ ーバがそのメソッドを認識できなかったり実装されていない場合には 501 (NotImplement ed) を返すべきである。サーバが理解しているメソッドのリストは Public レスポンスヘ ッダフィールド (14.35 章) でリストされる。 GET と HEAD メソッドはすべての一般目的サーバによってサポートされなければならない 。他のすべてのメソッドはオプションである。しかしながら、もし上記のメソッドがイン プリメントされているなら、それらは 9 章で記述されているものと同じセマンティクス で実装されなければならない。 5.1.2 Request-URI Request-URI は Uniform Resource Identifier (3.2 章) であり、リクエストを適用する リソースを識別する。 Request-URI = "*" | absoluteURI | abs_path Request-URI に対する 3 つのオプションはリクエストの性質に依存する。アスタリスク "*" はリクエストが特有のリソースではなくサーバ自身に適用する意味を持ち、使われて いるメソッドがリソースに適用される必要がないときにのみ許される。一つの例は以下の ようになる。 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 形式を受け 入れなければならない。 Request-URI のもっとも一般的な形式はオリジンサーバやゲートウェイ上のリソースを識 別するために使用される事である。この場合 URI の絶対パスはRequest-URI として伝え られなければならなず (3.2.1 章, abs_path 参照)、URI のネットワークロケーション ( net_loc) は Host ヘッダフィールドにおいて転送されなければならない。たとえば、上 記のように元のサーバから直接回収する事を望むクライアントはホスト "www.w3.org" の ポート 80 にTCP 接続を確立し、Request の残りが後に続く以下の行を送信する: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org 絶対パスは空ではない事に注意。元の URI で何も与えられていなければ、"/"(サーバの ルート) を与えなければならない。 プロキシが Request-URI においてどんなパスも持たないリクエストを受け取り、記述さ れたメソッドがリクエストのアスタリスク形式をサポートできるなら、リクエスト連鎖の 最後のプロキシは最終的な Request-URI として "*" をつけたリクエストを転送しなけれ ばならない。たとえば、リクエスト OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 はプロキシによってホスト "www.ics.uci.edu" のポート 8001 に接続した後 OPTIONS * HTTP/1.1 Host: www.ics.uci.edu:8001 を転送するであろう。 Request-URI は 3.2.1 章で記述されるフォーマットで伝えられる。オリジンサーバはリ クエストを適切に解釈するためにその Request-URI をデコードしなければならない。サ ーバは不正な Request-URI に適切なステータスコードで答えるべきである。 転送されるリクエストにおいて、プロキシは上記の null abs_path を "*" に置き換える 以外、プロキシがその内部的な実装で行うどんな事でも、Request-URI の "abs_path" を 書き換えてはならない。 注意: オリジンサーバが予約された目的のための予約されていない URL 文字を不適当に 使用しているとき、"書き換え禁止" ルールはプロキシがリクエストの意味を変えないよ うにする。実装者は既に幾つかの以前の HTTP/1.1 プロキシが Request-URI を書き換え る事が知られていると言う事を知るべきである。 5.2 リクエストによるリソース識別 HTTP/1.1 オリジンサーバはインターネットリクエストにより識別された正確なリソース が Request-URI と Host ヘッダフィールドの両方で検査する事により決定されると言う 事を知るべきである。 リソースにリクエストされたホストによって異なる事を認めていないオリジンサーバは H ost ヘッダフィールド値を無視する事ができる。(ただしHTTP/1.1 での Host サポートの 別の要求のため 19.5.1章参照。) リクエストされたホストを元にしてリソースを区別する (しばしば仮想ホストや空虚なホ スト名として参照される) オリジンサーバは 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 リクエストヘッダフィールド request-header フィールドはクライアントにリクエストやクライアント自身に関する追 加的な情報をサーバに渡す事を可能にする。これらのフィールドはこれらはプログラミン グ言語のメソッド呪文と等価なセマンティクスを伴ってリクエスト修飾子として動作する 。 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 | From ; Section 14.22 | Host ; Section 14.23 | If-Modified-Since ; Section 14.24 | If-Match ; 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.36 | Referer ; Section 14.37 | User-Agent ; Section 14.42 request-header フィールド名はこのプロトコルバージョンにおける変更の関連において のみ正確に拡張する事ができる。しかしながら、もし通信においてすべてのパーティがそ れらを request-header フィールドと認識するならば、新しいものや実験的なヘッダフィ ールドは request-header フィールドのセマンティクスが与えられる可能性がある。認識 されないヘッダフィールドはentity-header フィールドとして扱われる。 6 レスポンス リクエストメッセージを受信して解釈した後、サーバは HTTP レスポンスメッセージを返 す。 Response = Status-Line ; Section 6.1 *( general-header ; Section 4.5 | response-header ; Section 6.2 | entity-header ) ; Section 7.1 CRLF [ message-body ] ; Section 7.2 6.1 Status-Line Response メッセージの最初の行はステータスコード番号とそれに関連したテキストフレ ーズが後に続くプロトコルバージョンからなる Status-Line であり、それぞれの要素は SP 文字によって区切られる。最後の CRLF シーケンス以外ではどんな CR も LF もみと められない。 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 6.1.1 Status-Code と Result-Phrase Status-Code 要素はリクエストを理解し満たした試みの 3 文字数字の結果コードである 。これらのコードは 10 章ですべて定義されている。Response-Phrase は Status-Code の短いテキスト記述を与える目的を持つ。Status-Code は自動処理によって使う事を目的 とし Reason-Phrase は人間のユーザのためである。クライアントは Reason-Phrase を調 べたり表示したりする事を必要とされない。 Status-Code の最初の数字はレスポンスの分類である。最後の二つの数字はどんな分類ル ールも持たない。最初の数字には 5 つの値がある: * 1xx: Informational - リクエストは受け入れられ、処理を続けている * 2xx: Success - 動作は正常に受信され、理解され、受け入れられた * 3xx: Redirection - リクエストを完了するためさらにそれ以上の動作を行わなけれ ばならない * 4xx: Client Error - リクエストは間違った構文か果たす事のできないものを含ん でいる * 5xx: Server Error - サーバは明白に正当なリクエストを果たすのに失敗した HTTP/1.1 で定義された個々のステータスコード数値及びそれに相当するResason-Phrase のセットの例の値は以下に示される。ここでリストされたreason phrase は勧められるだ けである これらはプロトコルに影響がない範囲でローカルに相当するものに置き換える 事ができる。 Status-Code = "100" ; Continue | "101" ; Switching Protocols | "200" ; OK | "201" ; Created | "202" ; Accepted | "203" ; Non-Authoritative Information | "204" ; No Content | "205" ; Reset Content | "206" ; Partial Content | "300" ; Multiple Choices | "301" ; Moved Permanently | "302" ; Moved Temporarily | "303" ; See Other | "304" ; Not Modified | "305" ; Use Proxy | "400" ; Bad Request | "401" ; Unauthorized | "402" ; Payment Required | "403" ; Forbidden | "404" ; Not Found | "405" ; Method Not Allowed | "406" ; Not Acceptable | "407" ; Proxy Authentication Required | "408" ; Request Time-out | "409" ; Conflict | "410" ; Gone | "411" ; Length Required | "412" ; Precondition Failed | "413" ; Request Entity Too Large | "414" ; Request-URI Too Large | "415" ; Unsupported Media Type | "500" ; Internal Server Error | "501" ; Not Implemented | "502" ; Bad Gateway | "503" ; Service Unavailable | "504" ; Gateway Time-out | "505" ; HTTP Version not supported | extension-code extension-code = 3DIGIT Reason-Phrase = * HTTP ステータスコードは拡張可能である。HTTP アプリケーションは、すべての登録され たステータスコードの理解が明らかに望ましいが、それらすべての意味を理解する必要は ない。しかしながら、アプリケーションは最初の数字によって示されるような、どんなス テータスコードの分類も理解しなければならなず、認識されないレスポンスがキャッシュ されてはならないという例外を除いて、すべての認識されないレスポンスをそのクラスの x00 ステータスコードに相当するようなものとして扱わなければならない。たとえば、43 1 の認識されないステータスコードがクライアントに受信されたなら、そのリクエストに 何か不備があると言う安全な推測が行え、それが 400 ステータスコードを受信したかの ようにレスポンスを扱える。このような場合、このエンティティがこの異常なステータス を説明しているであろう人間が読める情報をたぶん含んでいるため、ユーザエージェント はレスポンスで返されたエンティティをユーザに示すべきである。 6.2 レスポンスヘッダフィールド レスポンスヘッダフィールドはサーバが Status-Line に置けないレスポンスに関する追 加的な情報を渡す事を可能にする。これらのヘッダフィールドはサーバとさらにそれ以上 の Request-URI によって識別されたリソースへのアクセスに関する情報を与える。 response-header = Age ; Section 14.6 | Location ; Section 14.30 | Proxy-Authenticate ; Section 14.33 | Public ; Section 14.35 | Retry-After ; Section 14.38 | Server ; Section 14.39 | Vary ; Section 14.43 | Warning ; Section 14.45 | WWW-Authenticate ; Section 14.46 response-header フィールド名は確かにこのプロトコルのバージョンにおける変更に関連 で拡張される事ができる。しかしながら、もし通信におけるすべてのパーティがそれらを response-header フィールドであると認識するなら、新しいものや実験的なヘッダフィー ルドは response-header フィールドのセマンティクスを与えられる可能性がある。 7 エンティティ リクエストメソッドやレスポンスステータスによって特に妨げられていないなら、リクエ ストとレスポンスメッセージはエンティティを転送する事ができる。幾つかのレスポンス は entity-header だけを含むだろうが、一つのエンティティは entity-header フィール ドと entity-body から成る。 この章において、送り側と受け側の両方がクライアントとサーバのどちらかを表し、エン ティティを送信するものと受信するものに依存する。 7.1 エンティティヘッダフィールド entity-header フィールドは entity-body や、もしボディが与えられないならリクエス トによって識別されたリソースに関するオプション的な情報を定義する。 entity-header = Allow ; Section 14.7 | Content-Base ; Section 14.11 | Content-Encoding ; Section 14.12 | Content-Language ; Section 14.13 | Content-Length ; Section 14.14 | Content-Location ; Section 14.15 | Content-MD5 ; Section 14.16 | Content-Range ; Section 14.17 | Content-Type ; Section 14.18 | ETag ; Section 14.20 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header extension-header メカニズムは追加的な entity-header フィールドがプロトコルを変更 する事なしに定義されるようにしているが、これらのフィールドは受け取り側によって認 識可能であると仮定される。認識されないヘッダフィールドは受け取り側によって無視さ れプロキシによって転送されるべきである。 7.2 エンティティボディ HTTP リクエストやレスポンスで送られる entity-body (もしあれば) はentity-header フィールドによって定義されるフォーマットとなりエンコーディングされている。 entity-body = *OCTET entity-body は 4.3 章で表されるように、message-body が示されたときにのみメッセー ジにおいて示される。entity-body はメッセージの安全性と妥当性を保証するために適用 されるであろうすべての Transfer-Encoding をデコードする事によって message-body から得られる。 7.2.1 タイプ 一つの entity-body がメッセージに含まれるとき、このボディのデータタイプは Conten t-Type と Content-Encoding ヘッダフィールド経由で決定される。これらは命令された エンコーディング 2 層モデルを定義する: entity-body := Content-Encoding( Content-Type( data ) ) Content-Type は根本的なデータのメディアタイプを詳述する。Content-Encoding は、た いていデータ圧縮の目的のため、要求されたリソースの特性であるデータに適用されたど んな追加的な内容コーディングをも示すために使用される事ができる。デフォルトのエン コーディングはない。 entity-body を含むどんな HTTP/1.1 もそのボディのメディアタイプを定義するための C ontent-Type ヘッダフィールドを含むべきである。もしメディアタイプが Content-Type ヘッダによって与えられないなら、そしてそのような場合に限り、受け取り側は内容と/ もしくはリソースを識別するために使用されている URL の名前拡張子の調査によってメ ディアタイプを推測する事を試みる事ができる。もしメディアタイプが分からないままな ら、受け取り側はそれをタイプ "application/octet-stream" として扱うべきである。 7.2.2 長さ entity-body の長さはすべての転送エンコーディングが取り除かれた後のmessage-body の長さである。4.4 章はどのように message-body の長さが決定されるかを定義している 。 8 接続 8.1 永続的な接続 8.1.1 目的 永続的な接続以前、別々の TCP 接続はそれぞれの URL を回収するため HTTPサーバのロ ードを増加しインターネットの混雑を引き起こすに確立されていた。インラインイメージ や別の関連したデータの使用はしばしばクライアントが短時間に同じサーバへ複数のリク エストを行うような必要性を生じさせる。これらの実行問題の分析は [30][27] で利用可 能である。プロトタイプインプリメンテーションからの分析と結果は [26] である。 永続的な HTTP 接続は幾つかの利点を持つ。 * より少ない TCP コネクションのオープンやクローズにより、CPU 時間を節約し T CP プロトコルコントロールブロックのために使用されるメモリも節約する。 * HTTP リクエストとレスポンスは接続上でパイプラインされる事ができる。パイプラ イン化はクライアントにそれぞれのレスポンスを待つ事なしに複数のリクエストを行う 事を可能にし、より少ない経過時間のより効果的に使用される単一の TCP 接続を可能 にする。 * ネットワーク混雑は TCP オープンや、TCP sufficient time にネットワークの混雑 状況を決定するのをまかせることによって引き起こされるパケットの数の減少によって 減少させられる。 * エラーは TCP 接続を閉じる罰則なしに報告される事ができるため、HTTP はより上 品に発展する。HTTP の将来のバージョンを使用するクライアントは楽天的に新しい機 能を試みるであろうが、もし古いサーバと通信するなら、エラーの後の古いセマンティ クスが伴う再試行も報告される。 HTTP インプリメンテーションは永続的な接続を実装すべきである。 8.1.2 全体の操作 HTTP/1.1 とそれ以前の HTTP バージョンの間の重要な違いは永続的な接続がすべての HT TP 接続のデフォルトの動作であると言う事である。これは、別の方法で示されない限り 、クライアントはサーバが永続的な接続を維持するだろうと言う事を仮定するであろう。 永続的な接続はクライアントとサーバが TCP 接続のクローズの合図を行えることによる メカニズムを提供する。この合図は Connection ヘッダフィールドを使用するところで使 う。ひとたびクローズが合図されたら、クライアントはその接続にそれ以上のリクエスト を送ってはならない。 8.1.2.1 ネゴシエーション HTTP/1.1 サーバは HTTP/1.1 クライアントが connection-token "close" を含んでいる Connection ヘッダがリクエストにおいて送られなければ永続的な接続を維持するつもり である事を想定する事ができる。もしサーバがレスポンスを送信した後にすぐに接続をク ローズする事を選んだら、connection-token close を含んでいる Connection ヘッダを 送信するべきである。 HTTP/1.1 クライアントは接続がオープンしたままである事を期待する事ができる。しか しサーバからのレスポンスが connection-token close を伴うConnection ヘッダを含ん でいるかどうかに基づいてそのオープンを維持するかを決めるだろう。クライアントがそ のリクエスト以上に接続を維持する事を望まない場合、connection-token close を含ん でいる Connection ヘッダを送るべきである。 もしクライアントとサーバのどちらかが Connection ヘッダで close トークンを送った なら、そのリクエストは接続に対する最後のものとなる。 それが明確に合図された以外は、クライアントとサーバは永続的な接続が 1.1よりも低い HTTP バージョンに対して維持されている事を仮定すべきではない。 HTTP/1.0 クライア ントとの下位互換性のより多くの情報のため 19.7.1章参照。 永続性を維持するため、接続上のすべてのメッセージは 4.4 章で定義されているように 、(それが接続の閉鎖によって定義されないような) 自身で定義されたメッセージの長さ を持たなければならない。 8.1.2.2 パイプライン化 永続的な接続をサポートするクライアントはそのリクエストを (それぞれのレスポンスを 待つことなしに複数のリクエストを送る) "パイプライン" する事ができる。サーバはリ クエストが受信されたのと同じ順番でそれらのリクエストのレスポンスを返さなければな らない。 永続的な接続を想定し接続確立のすぐ後にパイプラインを行うクライアントは、もし最初 のパイプラインされた試行が失敗したならそれらの接続を再試行するための準備をすべき である。もしクライアントがそのような再試行を行わならば、その接続が永続的であると 分かる前にパイプラインを行ってはならない。もしサーバがすべての通信のレスポンスを 返す前に接続をクローズするなら、クライアントはそれらのレスポンスを再送信するため の準備をしなければならない。 8.1.3 プロキシサーバ プロキシが 14.2.1 で示されている Connection ヘッダの特質を正確に実装する事は特に 重要である。 プロキシサーバはそれが接続しているクライアントとオリジンサーバ (または別のプロキ シサーバ) にそれぞれ永続的な接続の合図をしなければならない。それぞれの永続的な接 続は一つの転送リンクにのみ適用される。 プロキシサーバは HTTP/1.0 クライアントと永続的な接続を確立してはならない。 8.1.4 実際的な考察 サーバは常にそれらがもはや相互接続を維持しないあるタイムアウト値をもつであろう。 クライアントが同じサーバを経てより多くの接続を行おうとしているかもしれないため、 プロキシサーバはこれをより大きな値にすべきである。永続的な接続の使用はクライアン トとサーバのどちらかのためのこのタイムアウトの長さに必要性を置かない。 クライアントとサーバがタイムアウトを望むとき、それは転送接続上で上品なクローズを 発行すべきである。クライアントとサーバは両方とも他方の転送のクローズを絶えず監視 し、適切にそれに応じるべきである。もしクライアントかサーバが別の側のクローズを早 急に検出しなければ、ネットワーク上の不必要なリソース消耗を引き起こすかもしれない 。 クライアント、サーバもしくはプロキシはどんな時も転送接続をクローズする事ができる 。たとえば、クライアントはサーバが "idle" 接続をクローズしようとするのと同時に新 しいリクエストを送り始めるかもしれない。サーバの観点では、接続はそれがアイドルで ある間にクローズされているが、クライアントから見ればリクエストは進行中である。 これはクライアント、サーバやプロキシが非同期のクローズイベントから回復できなけれ ばならない事を意味する。クライアントソフトウェアは転送接続を再度オープンし、リク エストメソッドが idempotent (9.1.2 章参照) である限りユーザインタラクションなし に中止されたリクエストを再送信するべきである。他のメソッドは自動的に再試行されて はならない。とはいえ、ユーザエージェントは人間のオペレータにリクエストを再試行す る事の選択を申し出ることもできる。 しかしながら、この自動再試行はもし二回目のリクエストが失敗するなら繰り返すべきで はない。 もし全く可能なら、サーバは常に接続ごとに最低一つのリクエストを返すべきである。サ ーバはネットワークやクライアントの失敗に気づく以外、レスポンスの転送中に接続をク ローズすべきではない。 永続的な接続を使用するクライアントはそれらが与えられたサーバへ維持する同時接続の 数を制限すべきである。シングルサーバクライアントはどんなサーバやプロキシへも最大 で 2 接続を維持すべきである。プロキシは別のサーバやプロキシへの 2*N 接続以上を使 用すべきである。ここで Nは同時のアクティブユーザの数である。これらのガイドライン は HTTP レスポンスタイムを改善し、インターネットや他のネットワークの混雑を避ける 目的を持つ。 8.2 メッセージ転送要求 一般的な要求: * HTTP/1.1 サーバは永続的な接続を維持し、クライアントが再試行するだろうとい う期待を伴う接続の終了よりも、一時的な過負担を解決するための TCP フロー制御メ カニズムを使用すべきである。前者の技術はネットワーク混雑を悪化させる。 * message-body を送信する HTTP/1.1 (かそれ以降の) クライアントはそれがリク エストを送信している間、エラー状況のためにネットワーク接続を監視すべきである。 もしクライアントがエラー状況に会ったら、早急にボディの転送を中止すべきである。 もしボディが "chunked" エンコーディング (3.6 章) を使用して送られているなら、 ゼロの長さのチャンクと空のフッタがメッセージの終わりを早まってマークするために 使用されるであろう。もしボディが Content-Length によって先に述べられたなら、ク ライアントはクライアントは接続をクローズしなければならない。 * HTTP/1.1 (かそれ以降) クライアントは通常のレスポンスが後に続く 100 (Conti nue) を受け入れなければならない。 * HTTP/1.0 (かそれ以前) のクライアントからのリクエストを受信する HTTP/1.1 ( かそれ以降) のサーバは 100 (continue) レスポンスを伝えてはならない。通常に完了 されるためのリクエストを待つ (従って中間処理されたリクエストを避ける) か早まっ て接続をクローズすべきである。 HTTP/1.1 (かそれ以降の) クライアントからのこれらの要求に従うメソッドを受け取る上 で、HTTP/1.1 (かそれ以降の) サーバは 100 (Continue) ステータスで返答して入力スト リームからの読み込みを続けるか、エラーステータスを返すかどちらかを行わなければな らない。もしエラーステータスを返すなら、転送接続 (TCP) を閉じるかもしれないし読 み込みを続けてリクエストの残りを破棄するかもしれない。もしエラーステータスを返す ならリクエストされたメソッドを実行してはならない。 クライアントはサーバに使用された少なくとももっとも最近のバージョン番号を覚えてお くべきである。もし HTTP/1.1 クライアントがサーバからHTTP/1.1 かそれ以降のレスポ ンスを見つけ、サーバからどんなステータスをも受け取る前に接続がクローズしたことが 分かれば、クライアントはリクエストメソッドが idempotent (9.2.1 章参照) な限りユ ーザインタラクションなしにリクエストを再試行すべきである。他のメソッドは自動的に 再試行されてはならない。とはいえユーザエージェントはリクエストを再試行する選択を 人間のオペレータに申し出るかもしれない。もしクライアントがリクエストの再試行をす るのであれば、クライアントは * 最初にリクエストヘッダフィールドを送らなければならず、このとき * サーバがクライアントが続けるべき場合である、100 (Continue) レスポンスかエラ ーステータスを応答するまで待たなければならない。 もし HTTP/1.1 クライアントがサーバから HTTP/1.1 かそれ以降のレスポンスを確認しな いなら、サーバが HTTP/1.0 かそれ以前を実装しているとみなし、100 (Continue) レス ポンスは使われないだろう。もしクライアントがサーバからのどんなステータスをも受け 取る前に接続のクローズを確認した場合、クライアントはリクエストを再試行すべきであ る。もしクライアントがこのHTTP/1.0 サーバにリクエストを再試行したなら、確実なレ スポンスを得るのを確信させるため以下の "binary exponential backoff" アルゴリズム を使用すべきである。 1. サーバへの新しい接続を初期化する 2. request-header を転送する 3. サーバへの見積もられた round-trip time (その接続を確立するためにかかった時 間に基づくような)か、もし round-trip time が利用できなければ定数値5 秒で変数 R を初期化する。 4. T = R * (2**N) を計算、ここで N はこのリクエストの前の試行の回数である。 5. サーバからのエラーレスポンスまで、もしくは T 秒まで (どちらか先に来たほう) 待機 6. もし何もエラーが受信されなければ、T 秒後リクエストのボディを転送する。 7. もしクライアントがコネクションが早まってクローズされたのを確認したら、リク エストが受け入れるまでステップ 1 から繰り返し、エラーレスポンスが受け取られる か、ユーザが待てなくなって再試行プロセスを終了する。 どんなサーババージョンでも、もしエラーステータスが受信されたらクライアントは * 続けてはならず、 * もしメッセージの送信を完了していなければ接続をクローズしなければならない。 100 (Continue) を受け取った後だがどんな別のステータスも受信する前に接続がクロー ズしたという事を確認した HTTP/1.1 (かそれ以降の) クライアントはリクエストを再試 行すべきであり、100 (Continue) レスポンスを待つ必要がない (がもしこれがインプリ メンテーションを簡単にするならばそうするであろう)。 9 メソッド定義 HTTP/1.1 のための一般的なメソッドのセットは下に定義される。このセットは拡張可能 であるが、追加的なメソッドは別別に拡張されたクライアントとサーバに対して同じセマ ンティクスを割り当てていると仮定されない。 Host request-header フィールド (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 はこの特性を割り当てる。 9.2 OPTIONS OPTIONS メソッドは Request-URI によって識別されるリクエスト/レスポンス連鎖で利用 可能な通信オプションに関する情報のための要求を表している。このメソッドはクライア ントにリソース動作を暗に意味したりリソース回収を初期化する事なしに、リソースやサ ーバの能力に関連するオプションや/もしくは要求を決定する事を可能にする。 サーバのレスポンスがエラーでなければ、レスポンスは通信オプションとみなされるもの 以外のエンティティ情報 (Allow は適切であるが、Content-Typeはそうでない) を含んで はならない。このメソッドのレスポンスはキャッシュされない。 もし Request-URI がアスタリスク ("*") なら、OPTIONS リクエストは全体としてサーバ へ適用する目的をもつ。200 レスポンスは、一般もしくはレスポンスヘッダフィールドに 適用できるすべてのものに加えて、この仕様書によって定義されていないすべての拡張を 含む、サーバによって実装されているオプション的な機能 (Public のような) を示すど んなヘッダフィールドをも含むべきである。5.1.2 で表されるように、"OPTIONS *" リク エストはどんなパス情報もなしに目的のサーバを Request-URI において記述する事によ りプロキシを通して適用される。 もし Request-URI がアスタリスクでなければ、OPTIONS リクエストはそのリソースと通 信する時に利用可能なオプションのを申し込む。200 レスポンスは一般もしくは respons e-header フィールドに適用できるすべてのものに加えて、この仕様書で定義されていな いどんな拡張も含む、サーバによって実装されたオプション的な機能やそのリソースに適 用できる (Allow のような) オプション的な機能を示すどんなヘッダをも含むべきである 。もし OPTIONS リクエストがプロキシを通過するなら、プロキシはそのレスポンスをプ ロキシの能力に適用したりこのプロキシを通して有効でない事が分かっているこれらのオ プションを除外する編集を行ってはならない。 9.3 GET GET メソッドは Request-URI で識別される (エンティティの形式においての)情報ならな んでも回収する事を意味する。もし Request-URI が data-producing プロセスを参照し ているなら、それはリソースのエンティティとして返されるであろう作られたデータであ る。これはもしそのテキストがプロセスの出力で生じるのでなければ、プロセスのソース テキストではない。 もし If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Matchや If-Range ヘッダフィールドをリクエストメッセージが含んでいるなら、GET メソッドのセマンティ クスは "条件付き GET" に変わる。条件付き GETメソッドはエンティティがその条件付き ヘッダフィールドによって表される状況の元でのみ転送される事をリクエストする。条件 付き GET メソッドはキャッシュされるエンティティに複数のリクエストを必要としたり クライアントによってすでに保持されたデータを転送する事なしに再び新しくされる事を 可能にする事により、ネットワークの不必要な使用を減少する目的を持つ。 もしリクエストメッセージが Range ヘッダフィールドを含んでいるなら、GET メソッド のセマンティクスは "部分的 GET" に移行する。14.36 章で示されるように、部分的 GET は転送されるエンティティの一部のみを要求する。部分的 GET メソッドは partially-re trived エンティティにクライアントによって既に保持されているデータを転送する事な しに完全なものにするのを可能にするで、ネットワークの不必要な使用を減少する目的が ある。 もし 13 章で表される HTTP キャッシングのための要求につながるなら、そしてそのよう な場合にのみ、GET リクエストへのレスポンスはキャッシュ可能となる。 9.4 HEAD HEAD メソッドはサーバがレスポンスにおいて message-body を返してはならない事を除 いて GET と同一である。HEAD リクエストへのレスポンスにおいて HTTP ヘッダに含まれ るメタ情報は GET リクエストへのレスポンスで送られる情報と同一であるべきである。 このメソッドは entity-body 自身を転送する事なしにリクエストによって意味されるエ ンティティに付いてのメタ情報を得るために使用される。このメソッドはよくハイパーテ キストリンクの正当性、アクセス可能性、最近の修正をテストするために使用される。 HEAD リクエストへのレスポンスはレスポンスに含まれる情報がそのリソースからの前も ってキャッシュされたエンティティを更新するために使用できると言う意味でキャッシュ 可能である。もし新しいフィールド値がキャッシュされたエンティティが現在のエンティ ティと違う (Content-Length, Content-MD5,ETag や Last-Modified の変更を示すような ) 事を示しているなら、キャッシュはそのキャッシュエンティティを古くなったものとし て扱わなければならない。 9.5 POST POST メソッドは目的のサーバが Request-Line における Request-URI により識別される リソースの新しい従属として、リクエストにおいて同封されるエンティティを受け入れる 事を要求するために使用される。POST は一定の方法に以下の機能のカバーを可能にする ようにデザインされている * 既存リソースの注釈 * 告示板、ニュースグループ、メーリングリストや記事の類似グループへのメッセー ジの送信 * フォーム提出の結果のような、data-handling プロセスへのブロックデータの供給 * 操作の追加を経たデータベースの拡張 POST メソッドによって実行される実際の機能はサーバによって決定され、通常は Reques t-URI に依存する。ポストされたエンティティはファイルがそれを含むディレクトリに従 属し、ニュース記事がそれがポスとされたニュースグループに従属し、レコードがデータ ベースに従属しているのと同じ方法でそのURI に従属している。 POST メソッドによって実行される動作は URI によって識別されるリソースの結果ではな いかもしれない。この場合、200 (OK) か 204 (No Content) が適切なレスポンスステー タスであり、レスポンスが結果を表すエンティティを含んでいるかいないかに依存する。 もしリソースがオリジンサーバで既に制作されたなら、レスポンスは 201(Created) とな るべきであり、リクエストのステータスを表すエンティティを含んで新しいリソースと L ocation ヘッダ (14.30 章参照) を参照する。 もしそのレスポンスが適切な Cache-Control や Expires ヘッダフィールドを含んでいな いなら、このメソッドのレスポンスはキャッシュ可能ではない。しかしながら、303 (See Other) レスポンスはユーザエージェントにキャッシュ可能なリソースの検索を指示する ために使用される。 POST リクエストは 8.2 章のメッセージ転送要求セットに従わなければならない。 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 プロセス、ある別のプロトコルへのゲートウェ イ、または注釈を受け入る分割されたエンティティであろう。それに対して、 PUT リク エストにおける URI はリクエストとともに同封されたエンティティ ユーザエージェント はどんな URI が意図されているかを知っているが、サーバはある別のリソースへのリク エストを適用するのを仮定してはならない を識別する。もしサーバがそのリクエストが 別の URI に適用される事を望むなら、301 (Moved Permanently)レスポンスを返さなけれ ばならない。この時ユーザエージェントはリクエストをリダイレクトするかどうかに関し てそれ自身決定するかもしれない。 HTTP/1.1 はどのように PUT メソッドがオリジンサーバの状態に影響を及ぼすかを定義し ない。 PUT リクエストは 8.2 章でのメッセージ転送要求セットに従わなければならない。 9.7 DELETE DELETE メソッドはオリジンサーバが Request-URI により識別されるリソースを削除する 事を要求する。このメソッドはオリジンサーバで人の介入 (もしくは別の方法) によって 無効にさせられているかもしれない。たとえオリジンサーバから返されたステータスコー ドが動作がうまく完了したと言う事を示しているとしても、クライアントは操作が実行さ れた事を保証できない。しかしながら、もしリソースを削除したりアクセスできない場所 へ移動したりする事を目的としていないなら、レスポンスが与えられたときサーバは成功 を示すべきではない。 成功したレスポンスはもしレスポンスがステータスで表しているエンティティを含んでい るなら 220 (OK)、もし動作がまだ行われていないなら 202(Accepted)、もしくはもしレ スポンスが OK だがエンティティを含んでいないなら 204 (No Content) であるべきであ る。 もしリクエストがキャッシュを通過し Request-URI が一つ以上の現在キャッシュされて いるエンティティと同一なら、これらのエンティティは古くなったものとして扱われるべ きである。このメソッドのレスポンスはキャッシュできない。 9.8 TRACE TRACE メソッドはメッセージのリモート、application-layer loop-back を実施するため に使用される。リクエストの最後の受取人は 200 (OK) レスポンスの entity-body とし てクライアントに受け取られるメッセージを反映すべきである。最後の受取人はリクエス トでゼロ (0) の Max-Forwards 値 (14.31章参照) を受け取るオリジンサーバか最初のプ ロキシもしくはゲートウェイのどちらかである。TRACE リクエストはエンティティを含ん ではならない。 TRACE はクライアントになにがリクエスト連鎖の別の端で受け取られているかを見ること や、テストのためのデータや情報の診断を使用することを可能にする。リクエスト連鎖の トレースとしてそれが動作するため、Via ヘッダフィールド (14.44 章) の値が特に重要 である。Max-Forwards ヘッダフィールドはクライアントにリクエスト連鎖の大きさに制 限を与える事を可能にし、これは無限ループのメッセージ転送のプロキシ連鎖をテストす るために有用である。 もし成功したなら、レスポンスは entity-body に "message/http" のContent-Type を伴 うリクエストメッセージの全体を含むべきである。このメソッドのレスポンスはキャッシ ュされてはならない。 10 ステータスコード定義 それぞれの Status-Code は後に続くメソッドの記述とレスポンスにおいて必要とされる すべてのメタ情報を含んで以下に表される。 10.1 Informational 1xx このステータスコードは暫定的なレスポンスを示し、空行で終了するStatus-Line とオプ ション的なヘッダからのみなる。HTTP/1.0 がどんな 1xxステータスコードも定義されて いないため、サーバは実験的な状況下以外でHTTP/1.0 クライアントに 1xx レスポンスを 送ってはならない。 10.1.1 100 Continue クライアントはそのリクエストを続ける。この仮のレスポンスはリクエストの最初の部分 が受け取られ、サーバによってまだ受け付けられていない事をクライアントに伝えるため に使用される。クライアントはリクエストの残りを送る事でつづけるか、もし既にリクエ ストが完了していれば、このレスポンスを無視すべきである。サーバはリクエストが完了 した後に最終的なレスポンスを送らなければならない。 10.1.2 101 Switching Protocols サーバは理解し、Upgrade メッセージヘッダフィールド (14.41 章) 経由で、この接続で 使用されているアプリケーションプロトコルにおいて移行するためクライアントのリクエ ストに応じようとしている。サーバは 101 レスポンスを終了する空行をのあと、すぐに レスポンスの Upgrade ヘッダフィールドによって定義されたそれらのプロトコルをスイ ッチするだろう。 プロトコルはそうすべき事ほうが都合が良いときにのみスイッチされるだろう。たとえば 、HTTP のより新しいバージョンにスイッチする事はより古いバージョン以上に都合が良 いし、real-time にスイッチする事は同期のプロトコルがそのような機能を使うリソース を配布するときに都合が良いだろう。 10.2 Successful 2xx このステータスコードの分類はクライアントのリクエストがうまく受信され、理解され、 そして受け入れられた事をしめす。 10.2.1 200 OK リクエストは成功している。レスポンスに伴って返された情報はリクエストに使用された メソッドに依存する。たとえば: GET リクエストされたリソースに相当するエンティティがレスポンスとして送 られた。 HEAD リクエストされたリソースに相当する entity-header フィールドが message-body を伴わないでレスポンスとして送信された。 POST 動作の結果を記述もしくは含んでいるエンティティ TRACE 端末サーバによって受信されたリクエストメッセージを含んでいるエン ティティ 10.2.2 201 Created リクエストは果たされ、制作された新しいリソースが結果として生じた。新たに作り出さ れたリソースは Location ヘッダにより与えられるリソースに対する具体的な最高の URL を伴って、レスポンスのエンティティにおいて返された URI によって参照される。オリ ジンサーバは 201 ステータスコードを返す前にリソースを制作しなければならない。も し動作が動作がすぐに実行されなければ、サーバは代わりに 202 (Accepted) レスポンス を返信すべきである。 10.2.3 202 Accepted リクエストは処理のために受け入れられたが、処理は完全になされていない。処理が実際 に起こるとき拒否されるかもしれないので、リクエストが最終的に動作されるかどうかは 不明である。このような非同期操作からステータスコードを再送信するための機構は存在 しない。 202 レスポンスは意図的に non-committal である。この目的はユーザエージェントのサ ーバへの接続がプロセスが完了されるまで持続することなしに、ある別のプロセス (多分 一日に一度しか実行されない batch-oriented プロセス)のためのリクエストをサーバが 受け入れるのを可能にするためである。このレスポンスによって返されるエンティティは リクエストの現在の状態の指示と、状態モニタへのポインタかユーザがリクエストを失敗 していると予期できるある評価のどちらかを含むべきである。 10.2.4 203 Non-Authoritative Information entity-header において返されたメタ情報が、オリジンサーバから利用できるような決定 的なセットではなく、ローカルもしくはサードパーティコピーから集められたものである 。示されたセットは元のバージョンのサブセットかスーパーセットであろう。たとえば、 リソースに関するローカルな注釈情報を含む事はオリジンサーバによって知らされるメタ 情報のスーパーセットとなるかもしれない。このレスポンスコードの使用は必要でなく、 レスポンスが200 (OK) とは別であろう時にのみ適切である。 10.2.5 204 No Content サーバはリクエストを実行したが、送り返すための新しい情報が存在しない。もしクライ アントがユーザエージェントなら、リクエストの送信を行ったところからそのドキュメン トのビューを変えるべきではない。このレスポンスは主に、ユーザエージェントのアクテ ィブドキュメントビューを変える事なしに、アクションに対するインプットを起こせるよ うにするのを目的とする。レスポンスは entity-body の形式に新しいメタ情報を含むか もしれない。これはユーザエージェントのアクティブビューにおいて現在のドキュメント に適用されるべきである。 204 レスポンスは message-body を含まなければならず、従って常にヘッダフィールドの 後の最初の空行で終了する。 10.2.6 205 Reset Content サーバはリクエストを実行し、ユーザエージェントは送信されたリクエストをもたらした ドキュメントビューをリセットすべきである。このレスポンスは主にアクションに対する 入力が、ユーザが別の入力動作を簡単にできるように、与えられた入力におけるフォーム のクリアが続く、ユーザ入力を経由して起こせるようにする目的を持つ。レスポンスはエ ンティティを含んではならない。 10.2.7 206 Partial Content サーバはリソースに対する部分的 GET リクエストを実行した。リクエストはRange ヘッ ダフィールド (14.36 章) を含まなければならない。レスポンスはこのレスポンスに含ま れるレンジを示す Content-Range ヘッダフィールド(14.17 章) か、それぞれの部分に C ontent-Range フィールドを含むmultipart/byteranges Content-Type のどちらかを返さ なければならない。もし multipart/byteranges が使用されなければ、レスポンスにおけ るContent-Length ヘッダフィールドは message-body で転送される 8 ビットバイトの実 際の数と一致しなければならない。 Range や Content-Range ヘッダをサポートしないキャッシュは 206 (Partial)レスポン スをキャッシュしてはならない。 10.3 Redirection 3xx このステータスコードの分類はそれ以上の動作がリクエストを実行するためにユーザエー ジェントによって行われる必要のある事を示す。もし二番目のリクエストで使用されてい るメソッドが GET か HEAD なら、そしてその場合にのみ、ユーザへの影響なしにユーザ エージェントによって実行されるであろう。ユーザエージェントはそのようなリダイレク ションがたいてい無限ループを示すため、自動的に 5 回以上リダイレクトすべきではな い。 10.3.1 300 Multiple Choices それぞれがその具体的なロケーションを伴う表現セットのすべてのに相当する要求された リソースや、agent-driven ネゴシエーション情報 (12 章) がユーザ (もしくはユーザエ ージェント) が提案された表現を選択でき、そのロケーションにリクエストをリダイレク トできるように供給されている。[訳注: 要求されたリソースに該当するものが複数存在 する。] もしそれが HEAD リクエストでなければ、レスポンスはリソース特性のリストを含むエン ティティや、ユーザやユーザエージェントがもっとも適切なもの選ぶ事のできるロケーシ ョンを加えるべきである。エンティティフォーマットは Content-Type ヘッダフィールド で与えられるメディアタイプによって表される。データフォーマットやユーザエージェン トの能力に依存する事から、もっとも適切な選択が自動的に行われるかもしれない。しか しながらこの仕様書はそのような自動選択に対してどのような標準も定義しない。 もしサーバが表現の実行された選択を持っているなら、それは Locationフィールドにお ける表現に対する具体的な URL を含むべきである。このレスポンスはもし別のものを示 していなければキャッシュする事ができる。 10.3.2 301 Moved Permanently リクエストされたリソースは新しい恒久的な URI に割り当てられ、以降そのリソースへ の参照は返された URI の一つを使用すべきである。リンク編集機能を持つクライアント は、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照す るように自動的な再リンクすべきである。このレスポンスはもし別のものを示していなけ ればキャッシュ可能である。 もし新しい URI がロケーションならば、その URL はレスポンスにおいてLocation フィ ールドによって与えられるべきである。リクエストメソッドが HEAD でなければ、レスポ ンスのエンティティは新しい URI へのハイパーリンクを書き留める短いハイパーテキス トを含むべきである。 もし 301 ステータスコードが HEAD や GET 以外のリクエストのレスポンスとして受信さ れたら、レスポンスが配布されたもとの条件が変わっているかもしれないため、ユーザエ ージェントはユーザによって確認される事なくリクエストのリダイレクトを自動的に行っ てはならない。 注意: 301 ステータスコードを受信した後 POST リクエストを自動的にリダイレクトする とき、幾つかの既存の HTTP/1.0 ユーザエージェントは誤ってそれを GET リクエストに 変える。 10.3.3 302 Moved Temporarily リクエストされたリソースは一時的に別の URL で存在している。このリダイレクション は場合によって変更されるかもしれないため、クライアントは後のリクエストにその Req uest-URI を使いつづけるべきである。このレスポンスは Cache-Control か Expires ヘ ッダフィールドによって示されている場合にのみキャッシュ可能である。 もし新しい URI がロケーションであれば、その URL はレスポンス内のLocation ヘッダ によって与えられる。リクエストメソッドが HEAD でなければ、レスポンスのエンティテ ィは新しい URI へのハイパーリンクの書き留めてある短いハイパーテキストを返すべき である。 もし 302 ステータスコードが GET や HEAD 以外のリクエストのレスポンスで受信された ら、リクエストが配信された状況と異なるかもしれないため、ユーザエージェントはユー ザの確認なしにリクエストのリダイレクトを自動的に行ってはならない。 注意: 302 ステータスコードを受信した後の POST リクエストを自動的にリダイレクトす るとき、ある既存の HTTP/1.0 ユーザエージェントは間違ってGET リクエストに変えてし まう。 10.3.4 303 See Other リクエストに対するこのレスポンスは別の URI の形で発見され、このリソースを GET メ ソッドを使用して回収すべきである。このメソッドは主にPOST-activated スクリプトの 出力がユーザエージェントを選択されたリソースへリダイレクトするのを可能にするため に存在する。新しい URI は元々リクエストされたリソースに対する参照ではない。303 レスポンスはキャッシュ可能でないが、二番目の (リダイレクトされた) リクエストへの レスポンスはキャッシュ可能である。 もし新しい URI がロケーションであれば、その URL はレスポンスの Locationフィール ドによって与えられるべきである。リクエストメソッドが HEADでなければ、レスポンス のエンティティは新しい URI へのハイパーリンクが書き留めてある短いハイパーテキス トを含んでいるべきである。 10.3.5 304 Not Modified クライアントが条件付き GET リクエストを実行し、アクセスが許可されたが、そのドキ ュメントは更新されていなかったときに、サーバはこのステータスコードで応答すべきで ある。レスポンスは message-body を含んではならない。 レスポンスは以下のヘッダフィールドを含まなければならない: * Date * もしヘッダが同じリクエストに対して既に 200 レスポンスで送られているようなら ば、ETag と/もしくは Content-Location。 * もし field-value が同じバリアントに対する直前のレスポンスで送られたものと異 なるのであれば、Expires, Cache-Control, と/もしくは Vary。 もし条件付き GET が耐久性のあるキャッシュ認証マネージャ (13.3.3 章参照)を使った なら、レスポンスは別の entity-header を含むべきではない。別の点で (条件付き GET が強固でない認証マネージャを使ったような場合)、レスポンスは別の entity-header を 含んではならない。これはキャッシュされた entity-body と更新されたヘッダの間での 不一致を防ぐためである。 もし 304 レスポンスが現在キャッシュされていないエンティティを示すなら、キャッシ ュはレスポンスを無視し、条件なしのリクエストを反復しなければならない。 もしキャッシュがキャッシュエンティティを更新するために受信された 304レスポンスを 使用するなら、キャッシュはレスポンスで与えられたどんな新しいフィールド値をも反映 させるため、エンティティを更新しなければならない。 304 レスポンスは message-body を含んではならないし、従って常にヘッダフィールドに 続く最初の空行で終了する。 10.3.6 305 Use Proxy リクエストされたリソースは Location フィールドによって与えられるプロキシを通して アクセスされなければならない。Location フィールドはプロキシの URL を与える。受け 取り側はプロキシ経由でリクエストを再送信すると思われる。 10.4 Client Error 4xx ステータスコードの 4xx クラスはクライアントが間違えてたようであるという場合を目 的とする。HEAD リクエストの応答以外は、サーバはエラー状況が一時的なものでも恒久 的なものでも、その説明を含んでいるエンティティを加えるべきである。これらのステー タスコードはすべてのリクエストメソッドに適用されうる。ユーザエージェントはユーザ に、加えられたエンティティすべてを表示すべきである。 注意: もしクライアントがデータを送信しているなら、TCP を使用しているサーバインプ リメンテーションは、サーバが入力接続をクローズする前に、クライアントがレスポンス を含んでいるパケットの受領を知らせるのを保証するように気をつけるべきである。もし クライアントがクローズ後にデータを送信しつづければ、サーバの TCP スタックはクラ イアントにリセットパケットを送るだろう。これはクライアントの HTTP アプリケーショ ンがリクエストを読み出して中間処理する前に、それが知らせられなかった入力バッファ を消去するだろう。 10.4.1 400 Bad Request 不正な構文のリクエストのためサーバは理解できなかった。クライアントは修正しないま まそのリクエストを再送信すべきではない。 10.4.2 401 Unauthorized リクエストはユーザ認証を必要とする。レスポンスはリクエストされたリソースに適用で きる誰何を含む WWW-Authenticate ヘッダフィールド (14.46 章)を含まなければならな い。クライアントは適当な Authorization ヘッダフィールド (14.8 章) を伴うリクエス トを反復する事ができる。もしリクエストがすでに Authorization 証明を含んでいるの であれば、この 401 レスポンスは、認証がそれらの証明に対して拒否された事を示す。 もし 401 レスポンスが前のレスポンスと同じ誰何を含み、ユーザエージェントが既に最 低一回認証を試みているなら、そのエンティティが関連した診断情報を含んでいるであろ うため、ユーザエージェントはレスポンスで与えられたエンティティを表示するべきであ る。HTTP アクセス認証は 11 章において説明されている。 10.4.3 402 Payment Required このコードは将来の使用のため予約されている。 10.4.4 403 Forbidden サーバはリクエストを理解したが、それを実行する事を拒絶した。Authorizationは役に 立たないだろうし、リクエストは繰り返されるべきではない。もしリクエストメソッドが HEAD でなく、サーバがなぜリクエストが実行されなかったかを公にするなら、エンティ ティにおいて拒絶の理由を述べるべきである。このステータスコードは一般に、サーバが なぜリクエストが拒絶されたかを正確に示す事を望まないときや、別のレスポンスが適用 できない時に使用される。 10.4.5 404 Not Found サーバが Request-URI に一致するものを見つけられなかった。その状態が一時的なもの でも恒久的なものでも与えられる指示はない。 もしサーバがこの情報をクライアントに利用させたくなければ、代わりにステータスコー ド 403 (Forbidden) を使用する事ができる。ある内部的にコンフィギュレーション可能 なメカニズムによって、古いリソースが恒久的に利用できなかったり、それが転送アドレ スを持たない事をサーバが知っているなら、410 (Gone) ステータスコードが使用される べきである。 10.4.6 405 Method Not Allowed Request-Line に記述されたメソッドは Request-URI によって識別されるリソースに許可 されていない。レスポンスはリクエストされたリソースへの正当なメソッドのリストを含 む Allow ヘッダを含まなければならない。 10.4.7 406 Not Acceptable リクエストによって識別されるリソースは、リクエストで送られた accept ヘッダによれ ば受け入れられず、内容の特性を持つ生成したレスポンスエンティティのみが行える。 HEAD リクエストでなければ、レスポンスは利用できるエンティティの特性やユーザやユ ーザエージェントがもっとも適切なものを選べるロケーションのリストを含んでいるエン ティティを含むべきである。エンティティフォーマットは Content-Type ヘッダフィール ドで与えられるメディアタイプによって示されている。フォーマットやユーザエージェン トの能力に依存するため、もっとも適切な選択は自動的に実行されるだろう。しかしなが ら、この仕様書ではそのような自動選択のどんな標準をも定義しない。 注意: HTTP/1.1 サーバは、リクエストで送られた accept ヘッダにより受け入れできな いレスポンスを返す事が許されている。いくつかの場合、これは 406 レスポンスを送る 事が望ましいだろう。もし受け入れられるなら、ユーザエージェントは決定するため送ら れてきたレスポンスのヘッダを詳しく調べる事が推奨される。もしレスポンスが受け入れ られないなら、ユーザエージェントはそれ以上のデータの受信を一時的に停止し、それ以 降の動作の決定のためユーザにたずねるべきである。 10.4.8 407 Proxy Authentication Required このコードは 401 (Unauthorized) と似ているが、クライアントがプロキシに最初に認証 されなければならない事を示す。プロキシはリクエストされたリソースに対してプロキシ が適用できる誰何を含む、Proxy-Authenticate ヘッダ (14.33 章) を返さなければなら ない。クライアントは適当なProxy-Authorization ヘッダフィールド (14.34 章) を伴う リクエストを繰り返す事ができる。HTTP アクセス認証は 11 章で説明されている。 10.4.9 408 Request Timeout クライアントはサーバの待ち時間内にリクエストをもたらさなかった。クライアントはそ の後に修正しないでリクエストを繰り返す事ができる。 10.4.10 409 Conflict リクエストはリソースの現在の状態との矛盾のため完了されなかった。このコードはユー ザが矛盾を解決し、リクエストを再提出できる事が期待される状況のみに許される。レス ポンスボディはユーザが矛盾したリソースを認識するための十分な情報を含まなければな らない。理論的には、このレスポンスエンティティはユーザやユーザエージェントが問題 を修正するための十分な情報であろう。しかしながら、それは不可能だろうしその必要も ない。 矛盾は PUT リクエストへのレスポンスにおいてもっとも発生しがちである。もしバージ ョン処理が使用され、PUT のエンティティが初期の (サードパーティ) リクエストによっ て作られたそれらと矛盾しているリソースの試行を含んでいるならば、サーバはリクエス トが完了できなかった事を示す 409レスポンスを使用するできる。この場合、レスポンス エンティティはContent-Type レスポンスによって定義されるフォーマットで二つのバー ジョンの違いのリストを含むべきである。 10.4.11 410 Gone リクエストされたリソースがサーバにおいてもはや有功ではなく、転送先のアドレスも分 かっていない。この状況は恒久的なものとみなされるべきである。リンク編集機能を持つ クライアントはユーザに確認した後 Request-URI の参照を削除すべきである。もしサー バが、その状況が恒久的なものかどうか知らないか決定するための機能を持っていなけれ ば、代わりにステータスコード 404 (Not Found) が使用されるべきである。別の方法で 示されなければこのレスポンスはキャッシュできる。 主に 410 レスポンスは、リソースが故意に利用不可能であったり、サーバのオーナーが 削除されたリソースへのリモートリンクを望んでいる事を受取側に通知する事により、ウ ェブメンテナンスの作業を補助する目的を持つ。そのような出来事は、限られた期間の宣 伝サービスや、もはや動作していない個々のサーバに関連するリソースに対して一般的で ある。"過ぎ去った" ような恒久的に利用できないすべてのリソースをマークしたり、ど んな期間の長さ これはサーバオーナーの自由な許可である までもマークを維持しておく 必要はない。 10.4.12 411 Length Required サーバは定義された Content-Length なしにリクエストを受け入れる事を拒絶した。もし message-body の長さを含んでいる正当な Content-Length ヘッダフィールドをリクエス トメッセージに追加するなら、クライアントはリクエストを繰り返す事ができる。 10.4.13 412 Precondition Failed request-header フィールドの一つ以上で与えられた前提条件は、それがサーバでテスト されたときに偽であると評価された。このレスポンスコードはクライアントが前提条件を 現在のリソースのメタ情報 (ヘッダフィールドデータ)に置いたり、従ってリクエストさ れたメソッドを示されたリソース以外のものに適用させないようにするためのものである 。 10.4.14 413 Request Entity Too Large リクエストエンティティがサーバが想定ているかもしくは処理できる以上の長さのため、 サーバはリクエストを処理する事を拒絶している。サーバはクライアントにリクエストを 続けさせないため接続を閉じるかもしれない。 もし状態が一時的なら、サーバはそれが一時的でありクライアントが再試行できる経過時 間を示す Retry-After ヘッダフィールドを含むべきである。 10.4.15 414 Request-URI Too Long サーバ中間処理するために想定している以上に Request-URI が長いため、サーバはリク エストをサービスする事を拒絶している。このまれな状態は、クライアントが不適当に長 いクエリー情報を伴った POST リクエストを GETリクエストに変換したか、クライアント がリダイレクションの URL "ブラックホール" に陥ったか、サーバがクライアントにより Request-URI を読み出したり操作したりするための固定長バッファを使用しているいくつ かのサーバに存在するセキュリティホールを利用していると思われるアタックを受けてい る時にのみ起こる傾向がある。 10.4.16 415 Unsupported Media Type リクエストのエンティティは、リクエストされたメソッドに対してリクエストされたリソ ースがサポートしていないフォーマットであるため、サーバはリクエストのサービスを拒 絶している。 10.5 Server Error 5xx 数字 "5" から始まるレスポンスステータスコードは、サーバがエラー状態にあるか、リ クエストを実行する能力がないのに気づいた場合を示す。HEAD リクエストに相当する場 合以外、サーバはエラー状況とそれが一時的なものか恒久的なものかの説明を含むエンテ ィティを追加すべきである。ユーザエージェントはユーザに追加されたすべてのエンティ ティを表示すべきである。これらのレスポンスコードはどんなリクエストメソッドにも適 用できる。 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 サーバは一時的な過負荷やサーバのメンテナンスため現在リクエストを扱えない。これは ある遅延の後に軽減されるであろう一時的な状態も含む。もし分かるなら、遅延時間の長 さを Retry-After ヘッダで示す事ができる。もしRetry-After が与えられなければ、ク ライアントはそれを 500 レスポンスと同様に処理すべきである。 注意: 503 ステータスコードの存在は、サーバが過負荷状態になったときにそれを使わな ければならないと言う事を暗黙的に意味している。いくつかのサーバは単純に接続拒否を 望む事ができる。 10.5.5 504 Gateway Timeout ゲートウェイやプロキシとして動作するサーバは、リクエストを完了するためにアクセス した上層のサーバから適時のレスポンスを受信しなかった。 10.5.6 505 HTTP Version Not Supported サーバはリクエストメッセージで使用された HTTP プロトコルのバージョンをサポートし ていない、もしくはサポートを拒否している。3.1 章で表されるように、サーバはクライ アントと同じメジャーバージョンを使用してリクエストを完了できないか意図的にしない 事をこのエラーメッセージのほかに示している。レスポンスは、なぜこのバージョンがサ ポートされていないか、どんな別のプロトコルがこのサーバによってサポートされている かを記述したエンティティを含むべきである。 11 アクセス認証 HTTP は、サーバがクライアントにリクエストを促すためや、クライアントが認証情報を 提供するために使うことができる簡単な challenge-response認証メカニズムを提供する 。これは、認証スキームを確認するため、拡張可能な大文字小文字を区別しないトークン に続く、そのスキームの認証をなすために必要なパラメータを含むコンマで区切られた属 性値ペアのリストを使用する。 auth-scheme = token auth-param = token "=" quoted-string 401 (Unauthorized) レスポンスメッセージはオリジンサーバによりユーザエージェント の認証を促すために使用される。このレスポンスはリクエストされたリソースに適用され る最低一つの誰何を含む WWW-Authenticate ヘッダフィールドを含まなければならない。 challenge = auth-scheme 1*SP realm *( "," auth-param ) realm = "realm" "=" realm-value realm-value = quoted-string realm 属性 (大文字小文字を区別しない) は誰何を発行するすべての認証スキームに対し て要求される。アクセスされているサーバの公式ルート URL(5.1.2 章参照) との連帯動 作において、realm 値 (大文字小文字を区別する)は保護された領域を定義する。これら の realm はサーバ上の保護されたリソースが、それぞれ自身の認証スキームと/もしくは データベース認証を伴う保護された領域のセットに分割されるようにする。realm 値は、 一般的にオリジンサーバによって割り当てられている、認証スキームに特有の追加的なセ マンティクスを持つ文字列である。 サーバへ自身の認証を望む 常に 401 や 411 レスポンスを受信した後、必ずではないが ユーザエージェントはリクエストに Authorization ヘッダフィールドを加える事でそれ を行う事ができる。Authorization フィールド値はリクエストされたリソースの realm に対するユーザエージェントの認証情報を含む信用証明からなる。[訳注: 信用証明=cred ential] credentials = basic-credentials | auth-scheme #auth-param ユーザエージェントによって自動的に信用証明が適用される領域は、保護された領域によ り決定される。もし直前のリクエストが認証されているなら、同じ信用証明は認証スキー ム、パラメータ、そして/もしくはユーザ設定により決定された期間の間、その保護され た領域の中での別のすべてのリクエストに対して再使用できる。もし別のものが認証スキ ームによって定義されていなければ、単一の保護領域はそのサーバの範囲外まで及ぶ事は できない。 もしサーバがリクエストで送られる信用証明を受け入れたくなければ、401(Unauthorized ) レスポンスを返すべきである。レスポンスはリクエストされたリソースに適用できる ( 多分新しい) 誰何を含んでいる WWW-Authenticateヘッダフィールドと、拒絶を説明する エンティティを加えなければならない。 HTTP プロトコルはアプリケーションをアクセス認証のためのこの簡単なchallenege-resp onse メカニズムに制限しない。転送レベルにおける暗号化やメッセージのカプセル化な どのように、認証情報を詳述するための追加的なヘッダフィールドを伴う追加的なメカニ ズムを使用する事ができる。しかしながら、これらの追加的メカニズムはこの仕様書では 定義されない。 プロキシはユーザエージェント認証に関して完全に透明でなければならない。それらは W WW-Authenticate と Auhtorization ヘッダに手を付けないで転送し、14.8 章で見つけら れるルールに従わなければならない。 HTTP/1.1 はクライアントが Proxy-Authenticate と Proxy-Auhorization でプロキシか ら、そしてプロキシへ認証情報を渡せるようにしている。 11.1 Basic 認証スキーム "basic" 認証スキームは、ユーザエージェントがそれぞれの realm に自身のユーザ ID とパスワードを伴って認証されなければいけないモデルをもとにしている。realm 値はそ のサーバ上の別の realm との同一性のためにだけ比較される非空白文字列だとみなされ るべきである。サーバは、保護されたRequest-URI の領域に対してユーザ ID とパスワー ドが正しいと証明できるときのみリクエストをサービスするだろう。オプション的な認証 パラメータは存在しない。 保護領域内の URI に対して認証されていないリクエストの受領の上で、サーバは以下の ような誰何を返す事ができる。 WWW-Authenticate: Basic realm="WallyWorld" ここで "WallyWorld" は Request-URI の保護領域を識別するため、サーバによって割り 当てられた文字列である。 認証を受けるため、クライアントは信用証明において base64 エンコードが行われた文字 列のなかで、単一のコロン (":") 文字で区切られたユーザ ID とパスワードを送信する 。 basic-credentials = "Basic" SP basic-cookie basic-cookie = user-pass = userid ":" password userid = * password = *TEXT ユーザ ID は大文字と小文字を区別するだろう。 もしユーザエージェントがユーザ ID "Aladdin" とパスワード "open sesame"を送りたけ れば、それは以下のヘッダフィールドを使用するだろう: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Basic 認証に関連するセキュリティ考察のため 15 章参照。 11.2 認証スキームの要約 HTTP のための digest 認証は RFC 2069 [32] において詳述されている。 12 内容ネゴシエーション ほとんどの HTTP レスポンスは人間のユーザによる解釈のための情報を含んでいるエンテ ィティを追加するだろう。もちろん、リクエストと一致する "もっとも利用可能な" エン ティティをユーザに供給するのが望ましい。あいにく、サーバやキャッシュに対してすべ てのユーザが "best" であるような同じ設定を行っているわけではないし、すべてのユー ザエージェントがすべてのエンティティタイプを等しく表現できるわけではない。この理 由により、HTTP は"内容ネゴシエーション" 複数の利用可能な表現がある時、与えられた レスポンスに対して最も良い表現を選択するための処理 に対する幾つかのメカニズムの 機能を持つ。 注意: 互いの表現が同じメディアタイプを示すが、異なる言語などそのタイプの別の潜在 性を使用するため、これは "フォーマットネゴシエーション" と呼ばれない。 entity-body を含むどのようなレスポンス (エラーレスポンスを含む) もネゴシエーショ ンを受けさせる事ができる。 HTTP で可能な server-driven と agent-driven の二種類の内容ネゴシエーションが存在 する。二種類のネゴシエーションは直交し、したがって別々にもしくは条件により使用す る事ができる。率直なネゴシエーションと呼ばれる組み合わせの一つの方法は、キャッシ ュが続くリクエストに対するserver-driven ネゴシエーションを提供するため、オリジン サーバにより供給される agent-driven ネゴシエーション情報を使用するときに発生する 。 12.1 Server-driven ネゴシエーション もしレスポンスのための最良な表現の選択がサーバに設けられたアルゴリズムによって行 われたなら、これは server-driven ネゴシエーションと呼ばれる。選択は、リクエスト の利用可能な表現 (それが変化できる次元; 言語,content-coding など)や、リクエスト メッセージの特有なヘッダフィールドの内容、もしくはリクエストに適する別の情報 (ク ライアントのネットワークアドレスなど)に基づいている。 server-driven ネゴシエーションは、利用可能な表現の中から選択するためのアルゴリズ ムがユーザエージェントに説明するのが難しいときや、サーバが最初のレスポンスといっ しょにクライアントにその "最良の推測" を送るのを望むとき (もし "最良の推測" がユ ーザにとって十分によいなら、次のリクエストの round-trip delay を避けたいため) に 有利である。サーバの推測を改善するため、ユーザエージェントはそのようなレスポンス のためのその設定を記述するヘッダフィールド (Accept, Acctpt-Length, Accept-Encodi ng など)を加える事ができる。 server-driven ネゴシエーションは以下の不都合を持つ: 1. ユーザエージェントの能力とレスポンスの使用目的 (ユーザはスクリーンに表示 させたいのか紙に印刷したいのか?) の両方の完全な情報が必要なため、サーバがすべ てのユーザに "最良" であるものを正確に決定するのは不可能である。 2. リクエストごとにユーザエージェントにその能力を記述させるのは非常に能率が 悪く (レスポンスが複数の表現を持っている確率は少ないため)、ユーザプライバシー の潜在的な違反となりうる。 3. リクエストへのレスポンス生成のため、オリジンサーバのインプリメンテーショ ンとアルゴリズムを複雑にする。 4. 複数のユーザリクエストに同じレスポンスを使う公開キャッシュの能力を制限す るかもしれない。 HTTP/1.1 は、ユーザエージェントの能力とユーザ設定の記述を通してserver-driven ネ ゴシエーションを可能にするための、以下のリクエストヘッダフィールドを含んでいる: Accept (14.1 章), Accept-Charset (14.2 章),Accept-Encoding (14.3 章), Accept-Len gth(14.4 章) そして User-Agent(14.42 章)。しかしながら、オリジンサーバはそれらの 次元に限定されていないし、リクエストヘッダフィールドの外部やこの仕様書で定義され ていない拡張ヘッダフィールド内部の情報を含め、リクエストのすべての状況に基づいて レスポンスを変える事ができる。 HTTp/1.1 オリジンサーバは server-driven ネゴシエーションに基づくすべてのキャッシ ュ可能なレスポンスで適切な Vary ヘッダフィールド (14.43 章)を追加しなければなら ない。この Vary ヘッダフィールドはレスポンスが異なる (オリジンサーバが複数の表現 からその "最良の推測" レスポンスを取り出す次元) かもしれない次元を記述する。 HTTP/1.1 公開キャッシュは Vary ヘッダフィールドがレスポンスに含まれているときそ れを認識し、キャッシングと内容ネゴシエーション間の相互作用に付いて述べている 13. 6 章で言及されてる要求に従わなければならない。 12.2 Agent-driven ネゴシエーション agent-driven ネゴシエーションの場合、レスポンスのための最良の表現の選択は、オリ ジンサーバからの初期レスポンスを受信した後にユーザエージェントによって実行される 。選択は、最初のレスポンスのヘッダフィールド (付録19.6.2.1 で述べられているよう に、この仕様書ではフィールド名 Alterenatesを予約する) や entity-body の中に含ま れる、利用可能なレスポンスの表現のリストに基づき、それぞれ自身の URI によって区 別される。その表現のなかからの選択は自動的 (もしユーザエージェントがそうする能力 があれば)、もしくは生成されたメニュー (多分ハイパーテキスト) からのユーザ選択に よる手動で行われるだろう。 agent-driven ネゴシエーションは、レスポンスが一般的に使用されている次元 (タイプ 、言語、エンコーディングのような) と異るとき、オリジンサーバがリクエストの評価か らユーザエージェントの能力を決定できないとき、一般的には、公開キャッシュがサーバ の負荷を分散し、ネットワークの使用を減らすために使用されているときに有利である。 agent-driven ネゴシエーションは、複数のうち最良な表現を得るために次のリクエスト が必要となる不都合に苦しむ。次のリクエストはキャッシングが使用されている時にのみ 効率的である。さらに、自動選択をサポートするどんなメカニズムも拡張として発展した り HTTP/1.1 で使用したりを禁止しないが、この仕様書ではそれらのメカニズムを定義し ない。 HTTP/1.1 はサーバが決定しなかったり server-driven ネゴシエーションで使用する異な るレスポンスを供給できないとき、agent-driven ネゴシエーションを可能にするため、3 00 (Multiple Choices) と 406 (Not Acceptable)ステータスコードを定義する。 12.3 率直なネゴシエーション 率直なネゴシエーションは server-driven と agent-driven ネゴシエーションの両方の 組み合わせである。(agent-driven ネゴシエーションとして)キャッシュがリソースの利 用可能な表現のリストの形式を供給され、キャッシュによって相違の次元が完全に理解で きたとき、キャッシュはそのリソースの次のリクエストに対するオリジンサーバに代わっ て server-driven ネゴシエーションを実行する能力を持つようになる。 率直なネゴシエーションは、オリジンサーバに別の方法で要求されるネゴシエーション作 業の分散と、キャッシュが正しいレスポンスを正しく推測する事ができるとき agent-dri ven ネゴシエーションの次のリクエストによる後れを省略するという利点を持つ。 この仕様書ではそのようなどんなメカニズムの拡張としての発展や HTTP/1.1での使用を も禁止しないが、率直なネゴシエーションのためのどんなメカニズムも定義しない。もし すべての HTTP/1.1 クライアントで正しい中間操作を保証するためキャッシュ可能なら、 率直なネゴシエーションを実行する HTTP/1.1キャッシュはレスポンスに (その相違の次 元を定義する) Vary ヘッダフィールドを追加しなければならない。オリジンサーバによ って供給されるagent-driven ネゴシエーション情報は率直にネゴシエーションされたレ スポンスを加えられるべきである。 13 HTTP におけるキャッシング [訳注: この章は曖昧な表現や難解な表現がたくさん含まれていたので、詳細に付いては 原文を参照してください。] HTTP は典型的な情報配布のために使用される。ここでパフォーマンスはレスポンスキャ ッシュの使用により改善する事ができる。HTTP/1.1 プロトコルは可能な限りキャッシン グ作業を行う目的の幾つかの要素を含んでいる。これらの要素はプロトコルの別の局面で 込み入り、それらは相互に作用するため、メソッド、ヘッダ、レスポンスコードなどの詳 細な記述とは別に HTTP の基本的なキャッシングデザインを説明する事は有用である。 もし非常にパフォーマンスを高めなかったらキャッシングは役に立たないだろう。HTTP/1 .1 におけるキャッシングの到達点は、多くの場合においてリクエストを送る必要を除去 し、そして別の多くの場合において全レスポンスを送る必要を除去する。前者は多くの操 作に対して必要とされるネットワークround-trip の幾つかを減少する。われわれはこの 目的のため "満期" メカニズム (13.2 章参照) を使用する。後者は必要なネットワーク バンド幅を減らす。われわれはこの目的のため "確証" メカニズム (13.3 章参照) を使 用する。 パフォーマンス、有効性、そして分離した操作のための要求は、われわれにセマンティク ス透過性の到達点を緩めることを要求する。HTTP/1.1 プロトコルはオリジンサーバ、キ ャッシュ、クライアントが必要なときに透過性を明白に減らせるようにする。しかしなが ら、非透過な操作は非エキスパートユーザを混乱させ、あるサーバアプリケーション (商 品の注文用などの) と適合性がないため、プロトコルは: * クライアントやオリジンサーバによってゆるめられたとき、明白なプロトコルレ ベルリクエストによってのみ * キャッシュやクライアントによって緩められたとき、エンドユーザに明白な警告を 伴うのみ 透過性が緩められている事を必要とする。しかしながら、HTTP/1.1 プロトコルはこれら の重要な要素を備えている: 1. すべてのパーティによって要求される全セマンティクス透過性を供給するプロト コル機構。 2. オリジンサーバやユーザエージェントが明白に非透過操作をリクエストし、制御で きるようにするプロトコル機構。 3. キャッシュがリクエストされたセマンティクス透過性の概略を保存しないレスポン スに警告を付け加えられるようにするための機能。 基本原理はクライアントがセマンティクス透過性のどんな潜在的な緩和も検出可能でなけ ればならないと言う事である。 注意: サーバ、キャッシュもしくはクライアント実装者はこの仕様書において明確に論議 されないデザイン決定に直面するだろう。もし決定がセマンティクス透過性に影響するな ら、注意深く完全な分析が透過性の破壊で重要な恩恵を表す以外、実装者は透過性を維持 する本題から離れた間違いを犯している。 [訳注: セマンティクス透過性 意味的な透過性 とは、たとえばクライアントがプロキシ 経由でサーバにリクエストを送り、あたかもプロキシが存在しないようなレスポンスを受 け取るという事である。この時プロキシは意味的に"透過" である。もちろんサーバが本 来返すべきレスポンスと異なるレスポンスをプロキシが返せば "非透過" となる。つまり セマンティクス透過性とは "まるで存在していないかのような" という意味になる。] 13.1.1 キャッシュの正当性 正当なキャッシュはリクエストに、以下の状況の一つに合うリクエスト(13.2.5, 13.2.6, 13.12 章参照) にふさわしい、キャッシュによって保たれたもっとも最新のレスポンスで 答えなければならない: 1. オリジンサーバがレスポンスの正当性再確証によってオリジンサーバで返された ものの等価性が確認されている。 2. "十分新鮮" (13.2 章参照) である。デフォルトの場合、これはクライアント、サー バ、キャッシュの最低の限定的な新鮮さ要求に合う事を意味する (14.9 章参照)。もし オリジンサーバがそう指定するなら、オリジンサーバ単独の新鮮さ要求である。 3. もしクライアントやオリジンサーバに対する新鮮さ要求が違反されるならそれは警 告を含む (13.1.5 と 14.45 章参照)。 4. 適切な 3.4 (Not Modified), 305 (Proxy Redirect) やエラー (4xx か 5xx)レスポ ンスメッセージである。 もしキャッシュがオリジンサーバと通信できないなら、正しいキャッシュはレスポンスが キャッシュから正しく対応できているなら上記のものを返すべきである。もしそうでなけ れば、通信失敗があった事を示すエラーか警告を返さなければならない。 もしキャッシュが、リクエストしているクライアントに普通に転送するレスポンス (レス ポンス全体か 304 (Not Modified) レスポンスのどちらか) を受け取るか、受け取ったレ スポンスがもはや新鮮でなければ、キャッシュはそれを新しい Warning を追加する事な しに (存在するどんな Warning ヘッダも削除する事なく) リクエストしているクライア ントに転送すべきである。レスポンスが転送において古くなっているかもしれないため、 キャッシュは単純にそのレスポンスの再評価を試みるべきではない。これは無限ループを 引き起こすかもしれない。Warning の伴わない古くなったレスポンスを受け取ったユーザ エージェントはユーザに示す警告を表示できる。 13.1.2 警告 キャッシュが直接的でも "十分新鮮" でもないレスポンスを返すとき (13.1.1 章での 2 つの状態の意味において)、Warning レスポンスヘッダを使用して、警告をその影響に結 び付けなければならない。この警告はクライアントが適切な動作を行えるようにする。 警告は cache-related と別のものの両方の、別の目的で使用されるかもしれない。エラ ーステータスコードではなく、警告の使用は真の失敗とこれらのレスポンスを区別する。 警告が決してレスポンスの等価性を弱めないため、それらは常にキャッシュ可能である。 これは警告が危険を伴わない HTTP/1.0 キャッシュを通過する事ができる事を意味する。 そのようなキャッシュはレスポンスにおける entity-header として単純にその警告を通 過するだろう。 警告は 0 から 99 までの番号が割り当てられる。この仕様書は、クライアントやキャッ シュが幾つかの (すべてではない) 場合において自動的な動作を行えるように、現在警告 に割り当てられているそれぞれのコード番号と意味を定義する。 警告は警告テキストも含んでいる。このテキストは適切な自然言語 (多分クライアントの Accept ヘッダに基づいた) におけるものであり、どんな文字セットが使用されているか のオプション的な指示を含んでいる。 同じコードの複数の警告を含む、複数の警告は (オリジンサーバかキャッシュのどちらか によって) レスポンスに付随される。たとえば、サーバが英語とバスク語の両方でテキス トの同じ警告を供給できる。 複数の警告がレスポンスに付随するとき、ユーザにそれらすべてを表示するのは実用的で も合理的でもない。HTTP のこのバージョンは表示するための警告と順位示すための厳密 な優先ルールを詳述しないが、幾つかの発見的方法を提案する。 Warning ヘッダと現在定義されている警告は 14.45 章において述べられている。 13.1.3 キャッシュ制御メカニズム HTTP/1.1 における基本的なキャッシュアルゴリズム (server-specified 満期期間と確認 動作をするもの) はキャッシュするという蓄積的な命令である。いくつかの場合、サーバ もしくはクライアントは HTTP キャッシュに明白な命令を提供する必要があるかもしれな い。われわれはこの目的のため Cache-Controlヘッダを使用する。 Cache-Control ヘッダは、クライアントもしくはサーバがそれぞれのリクエストやレスポ ンスにおける命令の多様性を伝えられるようにする。これらの命令は典型的にデフォルト キャッシングアルゴリズムを無効にする。一般的なルールとして、もしヘッダ値の間に明 白な矛盾が存在するなら、ほとんどの限定的な解釈が適用されるべきである (これは、セ マンティクス等価性を維持するような物である)。しかしながら、いくつかの場合におい て、Cache-Control 命令は、セマンティクス等価性の概略を弱めるように明白に詳述され る (たとえば、"max-stale" や "public")。 Cache-Control 命令は 14.9 章において詳細に記述されている。 13.1.4 明白なユーザエージェント警告 多くのユーザエージェントは、ユーザに基本的なキャッシングメカニズムを置き換える事 ができるようにさせている。たとえば、ユーザエージェントはユーザにキャッシュされた エンティティ (明らかに古くなっている) が決して認証されていない事をしていできるよ うにするだろう。もしくは、ユーザエージェントはリクエストごとに "Cache-Control: m ax-stale=3600" をいつも追加するかもしれない。ユーザは非透過性動作もしくは通常で ない無効なキャッシングになる動作のどちらかを明らかに要請しなければならない。 もしユーザが基本的なキャッシングメカニズムを無効にするなら、ユーザエージェントは 、サーバの透過的要求に合っていないという情報の表示となるたびに (特に、もし表示さ れたエンティティが古くなっていると分かっているなら)明らかにユーザに示すべきであ る。プロトコルは、ユーザエージェントがレスポンスが古くなっているかどうかを決定で きるようにしているため、この指示はそれが実際に起こったときにのみ表示される必要が ある。この指示はダイアログボックスである必要はない。これはアイコン (たとえば、腐 った魚の絵)や別の仮想標識であっても良い。 もしユーザがキャッシュの有効性を以上に減少する方法のキャッシングメカニズムを設定 しているなら、ユーザが不注意に余分なリソースを消費したり過度の待ち時間に苦しまな いように、ユーザエージェントは続けて指示を表示 (たとえば、炎の中の通貨の絵) する べきである。 13.1.5 ルールと警告の例外 いくつかの場合、キャッシュのオペレータはクライアントにより要求されないとき、古く なったレスポンスを返すように設定する事を選ぶ事もできる。この決定は気軽に行われる べきではなく、有効性やパフォーマンスの理由、特にキャッシュがオリジンサーバに不十 分に接続されてしまう時に必要であろう。キャッシュが古くなったレスポンスを返す時、 (Warnign ヘッダを使用して)そのようにマークしなければならない。これはクライアント ソフトウェアが潜在的な問題があるかもしれないと言う事をユーザに警告できるようにす る。 ユーザエージェントが直接的もしくは新鮮なレスポンスを得ると言う処理を行う事もでき る。この理由により、もし技術的もしくはポリシー的な理由のため応ずる事が不可能でな ければ、クライアントが直接的もしくは新鮮なレスポンスを明らかに要請しているなら、 キャッシュは古くなったレスポンスを返すべきではない。 13.1.6 Client-controlled 動作 オリジンサーバ (とレスポンスの年齢へのそれらの寄与によるより少ない範囲、中間のキ ャッシュに) が満期情報のプライマリリソースである間、いくつかの場合クライアントは 、キャッシュされたレスポンスを返すかどうかを確認しないで、それに関してのキャッシ ュの決定を制御する必要があるかもしれない。クライアントは Cache-Control ヘッダの いくつかの命令を使ってこれを行う。 クライアントのリクエストは、正当性を確認しないでレスポンスを受け取るのを意図して 最大年齢を記述する事ができる。ゼロの値の記述する事は強制的にキャッシュにすべての レスポンスの正当性を再確認させる。クライアントはまたレスポンスが満期になる前に残 される最小期間を記述する事ができる。これらのオプションの両方はキャッシュの動作へ の制約を増加し、キャッシュのセマンティクス透過性の概略をそれ以上緩める事ができな い。 クライアントは古くなったレスポンスを受け入れる意図で、最大でもある古さの最大量ま で記述する事もできる。これはキャッシュの制約を緩め、オリジンサーバの記述されたセ マンティクス透過性の制約に違反するかもしれないが、接続が切れた操作や貧弱な接続面 における高い有効性をサポートする必要があるかもしれない。 13.2 満期モデル 13.2.1 Server-Specified 満期 HTTP キャッシングは、キャッシュがオリジンサーバにリクエストを送るのを完全に避け られるとき最良に動作する。リクエストを避ける第一のメカニズムは、レスポンスが次の リクエストを満足させるために使用される事も含めて、オリジンサーバが将来における明 確な満期期間を提供する事である。言いかえれば、キャッシュがサーバに先に接続する事 なしに新鮮なレスポンスを返せる。 われわれの期待は、満期期間に達する前にエンティティが変更されそうにない 意味的に 重要な意義を持つ方法で という確信において、サーバがリソースに将来的に明白な満期 期間を割り当てているだろう事である。これは普通、サーバの満期期間が注意深く選ばれ ている限り、セマンティクス透過性を維持する。 満期メカニズムは、リクエストしているクライアントに中間的に転送された直接的レスポ ンスにではなく、キャッシュから取得したレスポンスのみに適用する。 もしオリジンサーバが強制的に、意味的に透過なキャッシュをそれぞれのリクエストで正 当性を確認するよう望むなら、過去における明白な満期期間が割り当てられるだろう。こ れはレスポンスが既に古く、キャッシュは次のリクエストでそれを使用する前にその正当 性を確認すべきであると言う事を意味する。強制的に正当性を再確認するためのより限定 的な方法は 14.9.5 章参照。 どのように設定されているかに関わらず、もしオリジンサーバが強制的にすべての HTTP/ 1.1 キャッシュをリクエストごとに正当性の確認をさせるように望むなら、"must-revali date" Cache-Control 命令 (14.9 章参照) を使用すべきである。 サーバは Expires ヘッダか Cache-Control ヘッダの max-age 命令のどちらかを使用し て明確な満期期間を記述する。 満期期間は強制的にユーザエージェントの表示を更新したり、リソースを再ロードしたり させるために使用する事はできない。そのセマンティクスはキャッシングメカニズムにの み適用され、そしてそのようなメカニズムは、そのリソースに対する新しいリクエストが 始められたときのリソース満期ステータスのみをチェックする必要がある。キャッシュと 履歴メカニズムの違いの説明のための 13.13 章参照。 13.2.2 発見的な満期 オリジンサーバが常に明確な満期期間を提供するわけではないため、典型的にHTTP キャ ッシュは、本当の満期期間を判断するため別のヘッダ値(Last-Modified 時間のような) を使うアルゴリズムを使用する、発見的な満期期間を割り当てる。HTTP/1.1 仕様書は具 体的なアルゴリズムを提供しないが、別の結果への最悪の場合の制約を課す。発見的な満 期期間がセマンティクス透過性を損なうため、それらは慎重に使用されるべきであり、わ れわれはオリジンサーバが可能な限り明白な満期期間を提供する事を推奨する。 13.2.3 年齢計算 キャッシュされたエンティティが新鮮かどうか知るため、キャッシュはその年齢がその新 鮮さ持続期間を超えているかどうかを知る必要がある。われわれは後者がそのように計算 されるかを 13.2.4 章において論議する。この章はどのようにレスポンスやキャッシュエ ンティティの年齢を計算するかを記述する。 この論議では、われわれは "now" と言う言葉を "計算が行われているホストの現在の時 刻" という意味で使用する。HTTP を使用しているホスト、ただし、特にオリジンサーバ とキャッシュを実行しているホストはそれらのクロックを世界的に正確な標準時刻に同期 させるため NTP [28] やそれに似たプロトコルを使用すべきである。 HTTP/1.1 はオリジンサーバがレスポンスごとに、レスポンスが生成された時間を与える Date ヘッダを送る必要がある事に注意。われわれは自動操作のための適切な形式におい て "date_value" と言う言葉を Date ヘッダの値を示すものとして使用する。 HTTP/1.1 はキャッシュ間の年齢情報を伝える補助のための Age レスポンスヘッダを使用 する。Age ヘッダ値はオリジンサーバでレスポンスが制作されてからの時間量の送り側の 見積もりである。オリジンサーバに正当性が再確認された、キャッシュされたレスポンス の場合、Age 値は元のレスポンスではなく、正当性の再確認の時間に基づいている。 本質的に Age 値は、オリジンサーバからの経路に沿って存在するキャッシュのそれぞれ でレスポンスが存在する時間と、ネットワーク経路に沿う転送にかかった時間の合計であ る。 われわれは自動操作のための適切な形式で、"age_value" という言葉を Ageヘッダの値を 示すために使用する。 レスポンスの年齢は二つの勧善に独立した方法で計算する事ができる。 1. もしローカルクロックがオリジナルサーバのクロックと合理的に同期しているな ら、now から date_value を引く。もし結果が負となれば、ゼロに置き換える。 2. もしレスポンス経路上のすべてのキャッシュが HTTP/1.1 を実装しているなら age_ value。 われわれはレスポンスの年齢計算のための二つの独立な方法に、いつそれが受信されたか を与える事で、これらを corrected_received_age = max(now - date_value, age_value) として組み合わせる事ができ、おおよそ同期しているクロックかすべてがHTTP/1.1 経路 のどちらかを持つならば信頼できる (保守的な) 結果を得る。 もし経路内に HTTP/1.0 キャッシュが存在するなら、受信しているキャッシュのクロック がほぼ同調している限り正しい受信年齢が計算されているため、この補正は経路上の HTT P/1.1 キャッシュそれぞれに適用される事に注意。われわれは両端末のクロック同期をは かる必要がなく (それが良い方法だが)、明確にクロック同期をはかる処置は存在しない 。 ネットワークに課される遅延のため、ある重要な間隔が、サーバがレスポンスを生成する 時間と、次の外部行きのキャッシュやクライアントに受け取られる時間から経過するかも しれない。もし訂正されなければ、これの遅延は不適当に低い年齢をもたらす事ができる 。 返された Age 値をもたらしたリクエストは、その Age 値の生成より前に開始されていな ければならないため、そのリクエストが開始された時間を記録する事により、ネットワー クによって課された遅延を訂正する事ができる。Age 値が受信されたとき、レスポンスが 受信された時間ではなくリクエストが開始された時間との相対値と解釈しなければならな い。このアルゴリズムはどれくらいの遅延が発生したかに関わらず保守的な動作に帰着す る。それで、われわれは: corrected_initial_age = corrected_received_age + (now - request_time) ここで "request_time" はこのレスポンスを引き起こしたリクエストが送信されたときの 時間 (ローカルクロックによる) である。 キャッシュがレスポンスを受け取ったときの年齢計算アルゴリズムの要約は: /* * age_value * is the value of Age: header received by the cache with * this response. * date_value * is the value of the origin server's Date: header * request_time * is the (local) time when the cache made the request * that resulted in this cached response * response_time * is the (local) time when the cache received the * response * now * is the current (local) time */ apparent_age = max(0, response_time - date_value); corrected_received_age = max(apparent_age, age_value); response_delay = response_time - request_time; corrected_initial_age = corrected_received_age + response_delay; resident_time = now - response_time; current_age = corrected_initial_age + resident_time; キャッシュがレスポンスを送信するとき、レスポンスがローカルに居座っていた時間を c orrected_initial_age に加えなければならない。Age ヘッダを使用して、次の受信キャ ッシュにこのトータル年齢を転送しなければならない。 クライアントはレスポンスが直接的である事を確実に知らせる事ができない事に注意。し かし Age ヘッダの存在はレスポンスが明確に直接的でない事を示している。もしレスポ ンスの Date はクライアントのローカルなリクエスト時間より早いなら、多分 (深刻なク ロックのずれがなければ)レスポンスは直接的ではない。 13.2.4 満期計算 レスポンスが新鮮かどうかを決定するため、その新鮮さ持続時間と年齢を比較する必要が ある。年齢は 13.2.3 章で記述されているように計算される。この章はどのように新鮮さ 持続時間を計算するかと、どのようにレスポンスの期限が切れているかを判断するかを記 述する。以下の論議において、値は数値計算に対する適当な形式において表される。 われわれは "expires_value" を Expires ヘッダの値を示すものとして使用する。また " max_age_value" をレスポンスにおける Cache-Control ヘッダ(14.10 章参照) の max-ag e 命令によって伝えられた秒数の適切な値を示すものとして使用する。 max-age 命令は Expires より優先され、もし max-age がレスポンスにおいて与えられて いるなら計算は簡単である: freshness_lifetime = max_age_value さもなければ、もし Expires がレスポンスで与えられているなら、計算は: freshness_lifetime = expires_value - date_value それらの情報すべてがオリジンサーバからのものであるため、これらの計算のどちらもク ロックのずれに影響されない事に注意。 もしレスポンスに Expires も Cache-Control: max-age も現れなく、レスポンスがキャ ッシングの別の制限を含んでいなければ、キャッシュは発見的な方法を使って新鮮さ持続 時間を計算できる。もし値が 24 時間よりも大きいなら、もし Warning 13 警告がまだ追 加されていなければ、キャッシュは年齢が 24 時間以上のすべてのレスポンスにその警告 を追加しなければならない。 もしレスポンスが Last-Modified 時間を持っているなら、発見的な満期値は多くてもそ の時間からの間隔のある分数にすべきである。この分数の典型的な設定は 10% であろう 。 レスポンスの期限が切れたかどうかを決定する計算は全く簡単である: response_is_fresh = (freshness_lifetime > current_age) 13.2.5 満期値を曖昧にしないこと 満期値が楽天的に割り当てられるため、二つのキャッシュ要素が同じリソースに対する異 なる新鮮さ値を含む事が可能である。 もし回収を実行しているクライアントが自身のキャッシュにおいて既に新鮮であるリクエ ストに対して直接的でないレスポンスを受け取り、キャッシュに存在するエンティティの Date ヘッダが新しいレスポンスでの Date ヘッダより新しいなら、クライアントはレス ポンスを無視する事ができる。もしそうであれば、オリジンサーバに強制的にチェックす るため、"Cache-Control:max-age=0" 命令を伴うリクエストを再試行できる。 もしキャッシュが異なる正当性確認子を持つ同じ表現の二つの新鮮なレスポンスを持つな ら、より最近の Date ヘッダを持つものを使用しなければならない。この状況は、キャッ シュが別のキャッシュとレスポンスを共有するためや、クライアントが明白に新鮮なキャ ッシュエンティティの再ロードや正当性の再評価を行う事を要求したため生じるかもしれ ない。 13.2.6 複数のレスポンスを曖昧にしないこと クライアントが複数の経路でレスポンスを受け取る事ができるので、いくつかのレスポン スがあるキャッシュのセットを通って流れ、別のレスポンスが別のキャッシュのセットを 通って流れる事から、クライアントはオリジンサーバがレスポンスを送ったのと異なる順 番でレスポンスを受け取るかもしれない。もし古いレスポンスがまだ明白に新鮮であれば 、クライアントはもっとも最近生成されたレスポンスを使用する事が望まれる。 後のレスポンスがより早い満期期間を故意に運ぶことができるため、エンティティタグも 満期値も順序付けをレスポンスに課すことができない。しかしながら、HTTP/1.1 仕様書 はレスポンスごとに Date ヘッダの伝達を要求し、Date値は一つの秒の粒状性を定める。 クライアントがキャッシュエンティティの正当性再確認を試行し、受信したレスポンスが 既存のエンティティに対する Date ヘッダよりも古い Date ヘッダを含んでいるとき、ク ライアントすべての中間キャッシュにオリジンサーバへそれらのコピーの正当性確認を行 わせるため、 Cache-Control: max-age=0 を加えるかすべての中間キャッシュにオリジンサーバからの新しいコピーを得させるため 、 Cache-Control: no-cache を加えたリクエストを無条件に繰り返すべきである。 もし Date 値が等しいなら、クライアントはレスポンスのどちらかを使う事ができる (も しくはそれが極端に打算的なら、新しいレスポンスを要求できる)。それらの満期期間が 重複しているなら、同じ秒の間に生成されたレスポンスの決定的な選択ができるクライア ントにサーバは依存してはならない。 13.3 確証モデル キャッシュがクライアントのリクエストへのレスポンスとして使えそうな、古くなったエ ンティティを持っているとき、そのキャッシュされたエンティティがまだ使用可能かどう かを確かめるため、最初にオリジンサーバ (ひょっとすると新鮮なレスポンスを持ってい る中間キャッシュ) へチェックしなければならない。キャッシュされたエンティティで良 いなら全レスポンスの再転送のオーバーヘッドを受けなければならない事を望まないため 、そしてキャッシュされたエンティティが正当でないなら余分な round trip のオーバー ヘッドを受けなければならない事を望まないため、HTTP/1.1 プロトコルは条件付きメソ ッドの使用をサポートしている。[訳注: 正当性確証子 validator] 条件付きメソッドをサポートするための重要なプロトコル機構は "キャッシュ正当性確証 子" に関係するものである。オリジンサーバがレスポンス全体を生成するとき、それにキ ャッシュエンティティに保存されるある種の正当性確証子を付ける。クライアント (ユー ザエージェントやプロキシキャッシュ) がキャッシュエンティティを持つ物に対してリソ ースのための条件付きリクエストを作るとき、リクエストにおいて関連する正当性確証子 を追加する。 この時サーバはその正当性確証子とエンティティに対する現在の正当性確証子とを調べ、 それらがもし一致するなら、エンティティボディを伴わない特別なレスポンスコード (通 常は 304 (Not Modified)) を返す。従って、もし正当性確証子が一致するならレスポン スすべてを転送する事を避け、一致しないなら余分な round trip を避ける。 注意: 正当性確証子が一致しているかどうかを決定するために使用される比較機能は 13. 3.3 章に定義されている。 HTTP/1.1 において、メソッド (通常は GET) を暗に条件付きにする特別なヘッダ (正当 性確証子を含んでいるもの) を含む事を除いて、条件付きリクエストは同じリソースに対 する通常のリクエストと正確に同じに見える。 プロトコルはキャッシュ正当性確認条件の肯定的意図と否定的意図の両方を含んでいる。 これは、正当性確証子が一致するなら、そして正当性確証子が一致しないならメソッドが 実行されるということのどちらかを要求する事が可能である。 注意: もしこれが Cache-Control 命令によって明白に禁止されていなければ、正当性確 証子が欠落しているレスポンスはその期限が切れるまでキャッシュにキャッシュされ、保 存されるだろう。しかしながら、もしそれがエンティティに対する正当性確証子を持って いないならキャッシュは条件付き回収を行う事ができなく、これはその期限が切れた後も 再び新しくできないだろうと言う事を意味する。 13.3.1 Last-modified 日時 Last-Modified エンティティヘッダフィールド値はキャッシュ正当性確証子としてしばし ば使用される。簡単な条件では、キャッシュエンティティはエンティティが Last-Modifi ed 値から更新されていないなら正当であるとみなす事ができる。 13.3.2 エンティティタグキャッシュ確証子 ETag エンティティヘッダフィールド値、エンティティタグは "曖昧な" キャッシュ正当 性確証子を可能にする。これは、修正日時を保存する事が不都合な状況、HTTP 日付値の 秒解像度が十分でない状況、オリジンサーバが修正日時の使用から起こるであろう特定の 矛盾を避ける事を望む状況でより信頼できる確証を可能にするだろう。 エンティティタグは 3.11 章で記述される。エンティティタグと使用されるヘッダは 14. 20, 14.25, 14.26, 14.43 章で記述される。 13.3.3 弱い確証子と強い確証子 オリジンサーバとキャッシュの両方は同じエンティティを表すかどうかを決定するために 二つの確証子を比較するだろう。このためエンティティ (エンティティボディかエンティ ティヘッダ) が何らかの方法で変わっているなら通常は除外されるだろう。このとき関連 される確証子はその上で変更しているだろう。もしこれが真ならば、われわれはこの確証 子を "強い確証子" と呼ぶ。 しかしながら、サーバがエンティティ変更の重要でない局面はなく意味的に重要な変更で のみ確証子を変更する事を好む場合がありうる。リソースを変更するとき常に変更される わけではない確証子は "弱い確証子" である。 エンティティタグは通常 "強い確証子" であるが、このプロトコルは "弱い"ようなエン ティティタグにマークを付けるためのメカニズムを備えている。弱い値はエンティティの 意味が変更するとき変わるが、エンティティの小片が変更するときに変わるものは強い確 証子と考える事ができる。または、弱い確証子は意味的に等しいエンティティのセットに 対する識別子の一部であるが、具体的なエンティティに対する識別子の一部であるものは 強い確証子とみなす事ができる。 注意: 強い確証子の一つの例は安定した記憶装置においてエンティティが変更されるたび 毎回増加する整数である。 リソースを一秒間以内に二度更新することは可能なため、エンティティの更 新時間は、 もしそれが秒解像度に相当するなら弱い確証子である。 弱い確証子のサポートはオプションである。しかしながら、弱い確証子は同 等のオブジ ェクトのより効果的なキャッシング考慮に入れている。たとえば、 もしあるサイトのヒ ットカウントが日や週ごとでほとんど更新されないなら、 多分それは十分に良く、その 期間内のすべての値は多分 "十分に良く" 等し い。 確証子の "使用" は、クライアントがリクエストを生成し正当性確証ヘッダ フィールド に確証子が含むときか、サーバが二つの確証子を比較するときの どちらかである。 強い確証子はどんな状況にも使う事もできる。弱い確証子はエンティティの正確な等価性 に依存しない状況においてのみ使用可能である。たとえば、どちらかの種類がエンティテ ィ全体の条件付き GET のために使用可能である。しかしながら、クライアントが内部的 に矛盾するエンティティになってしまうため、強い確証子のみがサブレンジ回収のために 使用する事ができる。 HTTP/1.1 プロトコルが確証子に定義している機能は比較のみである。比較状況が弱い確 証子の使用を許すかどうかに依存する、二つの比較機能がある。 * 強い比較機能: 等しさを検討するため、両方の確証子はあらゆる方法で同一でな ければならなく、両方の確証子は共に弱くない。 * 弱い比較機能: 等しさを検討するため、両方の確証子はあらゆる方法で同一でなけ ればならない。ただし、これらのどちらかもしくは両方は結果に影響することなく "弱 い" とマークされている。 弱い比較機能は単純な (非サブレンジ) GET リクエストに使用する事ができる。強い比較 機能は別のすべての場合に使用されなければならない。 明確に弱いとマークされていなければエンティティタグは強い。3.11 章はエンティティ タグのための構文を与えている。 Last-Modified 時間がリクエストにおいて確証子として使用されているとき、以下のルー ルを使ってそれが強いと推定できなければ絶対的に弱い: * 確証子はオリジンサーバによってエンティティに対する実際の現在の確証子と比 較され、 * オリジンサーバが、関連したエンティティが与えられた確証子が及ぶ秒の間に二度 変更していない事を確かに知っている。 もしくは * クライアントが関連するエンティティに対するキャッシュエンティティを持って いるため、確証子が If-Modified-Since か If-Unmodified-Since ヘッダでクライアン トによって使用されようとしているところであり、 * キャッシュエンティティが、オリジンサーバが元のレスポンスを送ったときの時刻 を与える Date 値を含み、 * 表された Last-Modified 時刻は Date 値から最低 60 秒前である。 もしくは * 確証子が中間キャッシュによってエンティティに対するそのキャッシュエンティ ティに保存されている確証子と比較され、 * このキャッシュエンティティが、オリジンサーバが元のレスポンスを送ったときの 時刻を与える Date 値を含み、 * 表された Last-Modified 時刻は Date 値から最低 60 秒前である。 この方法は、二つの異なるレスポンスが同じ秒にオリジンサーバから送られ、両方は同じ Last-Modified 時刻を持っていたなら、これらのレスポンスの少なくとも一つはその Las t-Modified 時刻と同じ Date 値を持っているであろうという事実を当てにしている。独 断的な 60 秒制限は Date と Last-Modified 値が別のクロックからやレスポンスの準備 の間の幾分異なる時間に生成されたと言う可能性を警戒している。もしインプリメンテー ションが 60秒はとても短いと信じるなら 60 秒より大きい値を使用できる。 もしクライアントが Last-Modified 時刻のみを持ち曖昧な確証子を持たない値のサブレ ンジ回収を実行したければ、Last-Modified 時刻がここで記述された意図において強い場 合のみこれを行う事ができる。 全ボディ GET リクエスト以外のキャッシュ条件付きリクエストを受信しているキャッシ ュやオリジンサーバは条件を評価するために強い比較機能を使わなければならない。 このルールは HTTP/1.1 キャッシュとクライアントが HTTP/1.0 サーバから得られている 値のサブレンジ回収を安全に実行できるようにする。 13.3.4 いつエンティティタグと Last-Modified 時刻を使うかのルール われわれはさまざまな確証子タイプがいつ何の目的で使用されるべきかに関する、オリジ ンサーバ、クライアント、キャッシュのためのルールと推薦のセットを指定する。 HTTP/1.1 オリジンサーバは: * それを生成するのを実行可能ならエンティティタグ確証子を送るべきである。 * パフォーマンス考慮が弱いエンティティタグの使用を支持しているか、強いエンテ ィティタグを送るのを実行不可能なら、強いエンティティタグの代わりに弱いエンティ ティタグを送る事ができる。 * Last-Modified 値を送るのが実行可能で、If-Modified-Since ヘッダにおいてこの 日付の使用から結果として生じる、セマンティクス透過性における故障の危険が深刻な 問題を引き起さなければ、Last-Modified 値を送るべきである。 言いかえれば、HTTP/1.1 オリジンサーバに対してより望まれる動作は強いエンティティ タグと Last-Modified 値の両方を送る事である。 合法的であるため、強いエンティティタグは関連するエンティティ値が変わるどんな点で も変わらなければならない。弱いエンティティタグは関連するエンティティタグが意味上 で重要な点において変わるとき変わるべきである。 注意: 意味的に透過なキャッシングを供給するため、オリジンサーバは二つの異なるエン ティティに対する特定の強いエンティティタグ値の再使用、もしくは二つの意味的に異な るエンティティに対する特定の弱いエンティティタグ値の再使用を避けなければならない 。キャッシュエンティティは満期期間に関係なく任意な長期間持続するかもしれない。そ れで、キャッシュが過去のある点で得られた確証子を使用するエンティティの正当性を確 認することを再び試みないだろうという事を期待するのは不適当であろう。 HTTP/1.1 クライアントは: * もしオリジンサーバによってエンティティタグが供給されているなら、あらゆる キャッシュ条件付きリクエスト (If-Match か If-None-Match) でこのエンティティタ グを使わなければならない。 * もしオリジンサーバによって Last-Modified 値のみが提供されているなら、非サブ レンジキャッシュ条件付きリクエスト (If-Modified-Since を使った) においてこの値 を使用すべきである。 * もし HTTP/1.0 サーバによって Last-Modified 値のみが提供されるなら、サブレン ジキャッシュ条件付きリクエスト (If-Unmodified-Since を使った) においてこの値を 使用する事ができる。ユーザエージェントは難しい場合、これを無効にする方法を供給 すべきである。 * もしオリジンサーバによってエンティティタグと Last-Modified 値の両方が供給さ れれば、キャッシュ条件付きリクエストにおいて両方の確証子を使うべきである。これ は HTTP/1.0 と HTTP/1.1 キャッシュが適切に応答できるようにする。 リクエストを受信した上で、クライアントのキャッシュエンティティがキャッシュ自身の キャッシュエンティティと一致しているかどうかを決定するとき、HTTP/1.1 キャッシュ はもっとも限定的な確証子を使用しなければならない。これはリクエストがエンティティ タグと最終更新時刻確証子 (If-Modified-Since か If-Unmodified-Since) の両方を含ん でいるときにのみ問題となる。 正当性の注意: これらのルールの後の一般的な原理は、HTTP/1.1 サーバと クライアント はそれらのレスポンスやリクエストで利用可能であるような余 分でない情報と同量の転 送を行うべきである。この情報を受信している HTTP/1.1 はそれらが受信する確証子に関 してもっとも保守的な推測を行う だろう。 HTTP/1.0 クライアントとキャッシュはエンティティタグを無視するだろう。一般的に、 これらのシステムによって受信され使用される Last-Modified 値は透過的で効果的なキ ャッシングをサポートするだろう。そして HTTP/1.1 オリジンサーバは Last-Modified 値を供給すべきである。HTTP/1.0 システムによって確証子として Last-Modified 値の使 用が深刻な問題を引き起こすというまれな場合、HTTP/1.1 オリジンサーバはこれを供給 すべきではない。 13.3.5 Non-validating Conditionals エンティティタグ後の原則は、サービスの著者のみがリソースのセマンティクスが適切な キャッシュ確証メカニズムを選択するのに十分であると知り、バイト等価よりも複雑な確 証子識別機能のどんな物の仕様書も虫の缶を開けるだろう。従って、別のヘッダの比較 ( HTTP/1.0 互換性のための Last-Modified を除く) はキャッシュエンティティの正当性確 証の目的で決して使用されない。 13.4 レスポンスのキャッシュ可能性 Cache-Control (14.9 章) 命令で特に強いられていないなら、キャッシュシステムはキャ ッシュエンティティとして成功したレスポンス (13.8 章参照) を常に保存でき、それが 新鮮なら正当性確証なしにそれを返す事ができ、正当性確証の後それを返す事ができる。 もしレスポンスに関連するキャッシュ確証子も明白な満期期間もなければ、われわれはキ ャッシュされる事を期待しないが、特定のキャッシュはこの期待に違反する事ができる ( たとえば、ほとんどもしくは全くネットワーク接続が利用できないとき)。クライアント は、Date ヘッダと現在時刻を比較する事によってそのようなレスポンスがキャッシュか ら取られた事をたいてい検出できる。 いくつかの HTTP/1.0 キャッシュはどんな Warning も示さないでこの期待に違反する事 で知られる事に注意。 しかしながら、いくつかの場合キャッシュがエンティティを保持し、続くリクエストへの レスポンスとしてそれを返すことは不適切かもしれない。これは絶対的なセマンティクス 透過性がサービスの著者によって必要であると思われるため、もしくはセキュリティやプ ライバシーの配慮のためであろう。それゆえ、サーバが、あるリソースエンティティやそ れについての部分がそれらの配慮にかまわずキャッシュされるかもしれないと言う事を示 す事ができるようにCache-Control 命令は供給される 14.8 章では、共有されているキャッシュが普通、そのリクエストがAuthorization ヘッ ダを含んでいたなら、以前のクエストへのレスポンスを保存したり返したりできない事に 注意。 200, 203, 206, 300, 301, 410 のステータスコードを伴って受信されたレスポンスは、C ache-Control 命令がキャッシングを禁止していなければ、キャッシュによって保存され 、満期メカニズムにしたがって、引き続くリクエストへの応答において使用されるだろう 。しかしながら、Range と Content-Rangeヘッダをサポートしていないキャッシュは 206 (Partial Content) レスポンスをキャッシュしてはならない。 それら以外のステータスコードを伴うって受信されたレスポンスは、明らかにそれを認め る Cache-Control 命令や別のヘッダが存在しなければ、引き続くリクエストへの応答と して返されてはならない。たとえば、これらは以下を含んでいる: Expires ヘッダ (14.2 1 章); "max-age", "must-revalidate","proxy-revalidate" もしくは "public" Cache-C ontrol 命令 (14.9 章)。 13.5 キャッシュからのレスポンス構築 HTTP キャッシュの目的は、将来的なリクエストへの応答での使用のため、リクエストへ のレスポンスで受信された情報を保存する事である。多くの場合、キャッシュはリクエス トへのレスポンスの適切な一部を単純に返す。しかし、もしキャッシュが以前のレスポン スに基づくキャッシュエンティティを持っているなら、新しいレスポンスの部分をキャッ シュエンティティで持っているものとを結び付ける事ができる。 13.5.1 End-to-end と Hop-by-hop ヘッダ キャッシュや非キャッシュプロキシの動作を定義する目的のため、われわれはHTTP ヘッ ダを二つのカテゴリに分ける: * リクエストやレスポンスの最後の受取人に転送されなければならないend-to-end ヘッダ。レスポンスでの end-to-end ヘッダはキャッシュエンティティの一部として保 存されなければならず、キャッシュエンティティから形成されたあらゆるレスポンスで 転送されなければならない。 * 一つの転送レベル接続に対してのみ意味を持ち、キャッシュによって保存されたり プロキシによって転送されたりしない hop-by-hop ヘッダ。 以下の HTTP/1.1 ヘッダは hop-by-hop ヘッダである: * Connection * Keep-Alive * Public * Proxy-Authenticate * Transfer-Encoding * Upgrade HTTP/1.1 で定義されている他のすべてのヘッダは end-to-end ヘッダである。 HTTP の将来のバージョンにおいて導入される hop-by-hop ヘッダは 14.10 章で記述され るように、Connection ヘッダにおいてリストされなければならない。 13.5.2 修正されないヘッダ Digest Authentication のような、HTTP/1.1 プロトコルのいくつかの機能は特定の end- to-end ヘッダの値に依存する。キャッシュや非キャッシュプロキシは、このヘッダの定 義がそれを必要としたり特にそれが許されている以外は、end-to-end ヘッダを修正すべ きではない。 キャッシュや非キャッシュプロキシはリクエストやレスポンスにおいて以下のフィールド のどんな物も修正してはならないし、まだ存在していなければこれらのどれも追加できな い: * Content-Location * ETag * Expires * Last-Modified キャッシュや非プロキシサーバは、あらゆるリクエストにおいてやno-transform Cache-C ontrol 命令を含んでいるリクエストにおいて、以下のフィールドのどれも修正したり追 加してはならない: * Content-Encoding * Content-Length * Content-Range * Content-Type キャッシュや非キャッシュプロキシは no-transform を含まないレスポンスにおいてこれ らのフィールドを修正したり追加したりできるが、もしそうするなら、レスポンスでまだ それが現れていなければ Warnign 14(Transformation applied) を追加しなければならな い。 警告: もしより強固な認証メカニズムが将来の HTTP バージョンで導入されるなら、end- to-end ヘッダの不必要な修正は認証失敗を引きを超すかもしれない。このような認証メ カニズムはここでリストされないヘッダフィールドの値を当てにするだろう。 13.5.3 ヘッダの連結 キャッシュがサーバに正当性確証リクエストを送り、サーバが 304 (NotModified) レス ポンスを示したとき、キャッシュはリクエストに返すレスポンスを構築しなければならな い。キャッシュはこの出て行くレスポンスのエンティティボディとしてキャッシュエンテ ィティに保存されたエンティティボディを使う。もしキャッシュがキャッシュエンティテ ィを削除しようと決めなければ、キャッシュエンティティに伴って保存された end-to-en d ヘッダを入ってきたレスポンスで受け取った相当するヘッダと置き換えなければならな い。 言いかえれば、入ってきたレスポンスで受けた end-to-end ヘッダのセットはキャッシュ エンティティに伴って保存されているすべての相当する end-to-endヘッダを置き換える 。キャッシュはこのセットに Warning ヘッダ (14.45 章参照) を追加できる。 もし入ってきたレスポンスのヘッダフィールド名がキャッシュエンティティ内の一つ以上 のヘッダに相当するなら、それらすべてのヘッダは置き換えられる。 注意: このルールはオリジンサーバがあるエンティティに対する以前のレスポンスに関連 するすべてのヘッダを更新するため 304 (Not Modified) レスポンスを使えるようにする が、それが常に意味を持ったり常に正しくそうされるとは限らない。 13.5.4 バイトレンジの組み合わせ リクエストが一つ以上の Range 詳述を含んだり、接続が早まって切断されたりするため 、レスポンスはエンティティボディのバイトのサブレンジのみを転送できる。そのような いくつかの転送の後、キャッシュは同じエンティティボディのいくつかの範囲を受信する 事ができる。 もしキャッシュがエンティティに対するサブレンジの保存された空でないセットを持ち、 入ってきたレスポンスが別のサブレンジを転送するなら、キャッシュは以下の両方の条件 が合う場合に新しいサブレンジを既存のセットと結合できる: * 入ってきたレスポンスとキャッシュエンティティの両方はキャッシュ確証子を持 たなければならない。 * 二つのキャッシュ確証子は強い比較機能を使って一致しなければならない (13.3.3 章参照)。 もし要求のどちらかが合わなければ、キャッシュはもっとも最近の部分的なレスポンス ( レスポンスごとに転送された Date 値に基づかれる、これらの値が等しいか欠けているな ら入ってきたレスポンス) のみを使用しなければならず、別の部分的な情報を破棄しなけ ればならない。 13.6 キャッシングネゴシエーションされたレスポンス レスポンスにおける Vary ヘッダフィールドの存在によって示されるような、server-dri ven 内容ネゴシエーション (12 章) の使用は、キャッシュが引き続くリクエストのため にそのレスポンスを使える事によりその条件と手続きを変更する。 キャッシュにどんなヘッダフィールドの次元がキャッシュ可能なレスポンスの複数の表現 の一つを選択するために使用されるかを知らせるため、サーバはVary ヘッダフィールド (14.43 章) を使わなければならない。キャッシュは、引き続くリクエストが Vary レス ポンスヘッダにおいて詳述されたすべてのヘッダフィールドに対する同じか同等の値を持 つ時のみ、そのリソース上の引き続くリクエストに返すための選択された表現 (その特有 のレスポンスに含まれるエンティティ) を使う事ができる。これらのヘッダフィールドの 一つ以上に対して異なる値を持つリクエストはオリジンサーバに転送されるであろう。 もしエンティティタグが表現に割り当てられていたなら、転送されたリクエストは条件付 きであり、Request-URI に対するそのすべてのキャッシュエンティティから If-None-Mat ch ヘッダフィールドのエンティティタグを含むべきである。もしキャッシュが現在保存 しているエンティティのどれかがリクエストされたエンティティと一致するなら、サーバ はキャッシュにエンティティが適切である事を伝えるため 304 (Not Modified) レスポン スにおいて ETagヘッダを使う事ができ、それによりこれはサーバにキャッシュが現在保 存しているエンティティのセットを伝える。もし新しいレスポンスのエンティティタグが 既存のエンティティのそれと一致するなら、新しいレスポンスは既存のエンティティのヘ ッダフィールドを更新するために使用されるべきであり、その結果はクライアントに返さ れなければならない。 Vary ヘッダフィールドはキャッシュにその表現がリクエストヘッダに束縛されない基準 を使用して選ばれた事を知らせる事もできる。この場合、キャッシュが条件付きリクエス トでサーバへ新しいリクエストを送らないか、サーバがエンティティが使用されるべきで ある事を示すエンティティタグや Content-Length を含む 304 (Not Modified) を伴って 応答しないなら、キャッシュは引き続くリクエストの応答においてレスポンスを使用して はならない。 もし既存のキャッシュエンティティのいかなる物も関連するエンティティに対する部分的 な内容のみを含むなら、リクエストがそのエンティティによる完全に満たされた範囲に対 するものでなければそのエンティティタグは If-None-Match ヘッダに含まれてるべきで はない。 もし Content-Location フィールドが同じ Request-URI に対する既存のキャッシュエン ティティのそれと一致し、エンティティタグが既存のエンティティのそれと異なり、Date が既存のそれよりも最近のものである成功したレスポンスをキャッシュが受信したなら、 既存のエンティティは将来的なリクエストへのレスポンスで返されるべきではなく、キャ ッシュから削除されるべきである。 13.7 共有されたキャッシュと共有されていないキャッシュ セキュリティやプライバシーの理由のため、"共有された" キャッシュと "共有されてい ない" キャッシュの区別を付ける事が必要である。共有されていないキャッシュは単一の ユーザによってのみ利用可能なものである。この場合のアクセス可能性は適切なセキュリ ティメカニズムによって施行されるべきである。他のすべてのキャッシュは "共有された " キャッシュとみなされる。この仕様書の別の章はプライバシーの損失やアクセス制御の 失敗を防止するため、共有されたキャッシュの操作へのある制約を置いている。 13.8 エラーや不完全なレスポンスのキャッシュ動作 不完全なレスポンス (たとえば、Content-Length ヘッダで記述されたものより少ないデ ータのバイトを伴うもの) を受信するキャッシュはレスポンスを保存する事ができる。し かしながら、キャッシュは部分的なレスポンスとしてこれを扱わなければならない。部分 的なレスポンスは 13.5.4 章で定義されているように結合する事ができる。その結果は完 全なレスポンスかもしれないしまだ部分的かもしれない。206 (Partial Content) を使用 して明確にそのように示す以外は、キャッシュはクライアントに部分的なレスポンスを返 してはならない。 もしエンティティの正当性再確証を試みるときキャッシュが 5xx レスポンスを受信した ら、リクエストしているクライアントにこのレスポンスを転送するか、サーバが応答に失 敗したかのように動作するかどちらかを行う事ができる。後者の場合、キャッシュされた エンティティが "must-revalidate" Cache-Control 命令 (14.9 章参照) を含んでいない なら、以前に受信したレスポンスを返す事ができる。 13.9 GET と HEAD の副作用 オリジンサーバがそれらのレスポンスのキャッシングを明白に禁止していなければ、どん なリソースへの GET や HEAD メソッドの適用もそれらのレスポンスがキャッシュから取 り出されたなら、誤った動作につながる副作用をもたらすべきではない。これらは副作用 をもたらす事ができるが、キャッシュはそのキャッシング決定においてそのような副作用 を検討する事を必要とされていない。キャッシュは常にキャッシングにおいてオリジンサ ーバの明確な制限を観察する事を期待される。 われわれはこのルールのある例外を言及する: いくつかのアプリケーションが重要な副作 用を伴う操作を実行するためにクエリー URL (これらは rel_path部分に "?" を含む) を 伴う GET や HEAD を伝統的に使用しているため、キャッシュはサーバが明白な満期期間 を与えなければ、そのような URL へのレスポンスを新鮮であるように扱ってはならない 。これはそのような URI に対する HTTP/1.0 サーバからのレスポンスがキャッシュから 取り出されるべきではないと言う事を特に意味している。関係する情報のため 9.1.1 章 参照。 13.10 更新や削除後の無効化 オリジンサーバへのあるメソッドの影響は一つ以上の既存のキャッシュエントリを無効な 非透過にさせるかもしれない。これは、それらは "新鮮で" あり続けるかもしれないが、 それらはオリジンサーバが新しいリクエストに対して返すであろうものに正確に反映され ていないと言う事である。 そのようなキャッシュエントリすべてが無効であると示す事を保証するためのHTTP プロ トコルのためのどんな方法も存在しない。たとえば、オリジンサーバに変更を引き起こす リクエストはキャッシュエントリが保存されているプロキシを通り抜けていないかもしれ ない。しかしながら、いくつかのルールは間違った動作の可能性を減らす補助をする。 この章では、フレーズ "エンティティを無効にする" は、キャッシュがその保存媒体から そのエンティティのすべてのインスタンスを削除すべきであるか、"無効" としてそれら をマークすべきでありそれらが引き続くリクエストへのレスポンスにおいて返される前に 義務的に正当性の再確証を行う必要があると言う事のどちらかを行うと言う意味である。 いくつかの HTTP メソッドはエンティティを無効にする事ができる。これはRequest-URI によって参照されるエンティティか、Location や Content-Location レスポンスフィー ルド (もし存在するなら) によって参照されるエンティティのどちらかである。これらの メソッドは: * DELETE * POST サービスアタック拒否を防ぐため、Location もしくは Content-Location ヘッダでの UR I に基づく無効化はホスト部分が Request-URI におけるものと同じである場合にのみ実 行されなければならない。 13.11 義務的な Write-Through 修正をオリジンサーバのリソースにもたらす事を期待されるすべてのメソッドは、オリジ ンサーバへ通されて書かれなければならない。これは現在 GETと HEAD 以外のすべてのメ ソッドを含んでいる。キャッシュは向かうサーバへのリクエストを転送し、向かうサーバ から相当するレスポンスを受け取る前にクライアントからのそのようなリクエストに応じ てはならない。キャッシュが向かうサーバが応答する前に 100 (Continue) レスポンスを おくるのは妨げない。 一貫した更新を提供する事の困難や、write-back 以前のサーバ、キャッシュ、ネットワ ークの失敗から生じる問題のため、("write-back" や "copy-back"として知られる) 代わ りは HTTP/1.1 において認められていない。 13.12 キャッシュの交替 もし同じリソースに対するすべての既存のレスポンスがキャッシュされている一方で、新 しいキャッシュ可能な (14.9.2, 13.2.5, 13.2.6, 13.8 章参照) レスポンスがリソース から受信されたなら、キャッシュは現在のリクエストへの応答に新しいレスポンスを使用 すべきである。それをキャッシュ保存媒体に挿入する事ができ、もし他のすべての要求に 合うなら、前もって古いレスポンスを返させるようにさせる将来的なリクエストへの応答 のため使用する事ができる。キャッシュ保存媒体に新しいレスポンスを挿入するなら、13 .5.3 章のルールに従うべきである。 注意: 既存のキャッシュされたレスポンスより古い Date ヘッダ値を持つ新レスポンスは キャッシュ可能ではない。 13.13 履歴リスト ユーザエージェントはしばしば "Back" ボタンと履歴リストのような履歴メカニズムをも ち、セッションにおいて以前に回収されたエンティティを再表示するために使う事ができ る。 履歴メカニズムとキャッシュは異なる。特に履歴システムはリソースの現在の状態の意味 的に透過なビューを表示する事を試行すべきではない。むしろ、履歴システムはリソース が回収されたときにユーザが見たものを正確に表示する事が意味される。 デフォルトにより、満期期間は履歴メカニズムに適用しない。もしそのエンティティがま だ保存されているなら、ユーザが特にエージェントを期限切れの履歴ドキュメントをリフ レッシュするように設定していなければ、履歴メカニズムはエンティティの期限が切れて いてもそれを表示すべきである。 これは、履歴システムがユーザにビューが古くなっている事を知らせる事を禁止すると解 釈されるべきではない。 注意: もし履歴リストメカニズムがユーザに古くなったリソースの表示を不必要に禁止す るなら、サービスの著者が別の方法を望むとき、HTTP 満期制御とキャッシュ制御を強制 的に使用させない傾向があるだろう。ユーザが前もって回収したリソースを見るためのナ ビゲーション制御 (BACK のような) を使うとき、サービスの著者はエラーメッセージや 警告メッセージがこのユーザにもたらされない事を重要だと考慮するかもしれない。たと え時々そのようなリソースがキャッシュされるべきではなく、早急に期限が切れるべきだ としても、履歴メカニズムとして不適当に機能していることの影響で苦しまないため、ユ ーザインターフェース考慮はサービス著者をキャッシングを妨げる別の方法 (例: "once- only" URL) に強制的に頼らせることができる。 14 ヘッダフィールド定義 この章ではすべての標準 HTTP/1.1 ヘッダの構文とセマンティクスを定義する。エンティ ティヘッダフィールドに対して、エンティティを誰が送信し誰が受信するかに依存して、 送り側と受け取り側の両方はクライアントかサーバのどちらかを参照する。 14.1 Accept Accept リクエストヘッダフィールドはレスポンスのために許容できるあるメディアタイ プを詳述するために使用される。Accept ヘッダはインラインイメージのためのリクエス トの場合のように、リクエストが希望されるタイプの小さなセットに特に制限されている 事を示すために使用されうる。 Accept = "Accept" ":" #( media-range [ accept-params ] ) media-range = ( "*/*" | ( type "/" "*" ) | ( type "/" subtype ) ) *( ";" parameter ) accept-params = ";" "q" "=" qvalue *( accept-extension ) accept-extension = ";" token [ "=" ( token | quoted-string ) ] "*/*" がすべてのメディアタイプを示し、"type/*" がそのタイプのすべてのサブタイプ を示すように、アスタリスク "*" 文字は範囲内のグループメディアに使用される。media -range はその範囲に適用できるメディアタイプパラメータを含む事ができる。 それぞれの media-range は、相対的なクオリティ因子を示すための "q" で始まるパラメ ータである、一つ以上の accept-params を続ける事ができる。最初の "q" パラメータは media-range パラメータを accept-params に分割する。クオリティ因子は 0 から 1 ス ケールの qvalue を使用してユーザやユーザエージェントがその media-range に対する 優先度の相対的な度合いを示せるようにする。デフォルトの値は q=1 である。 注意: メディアタイプパラメータを Accept 拡張パラメータと分けるための"q" パラメー タ名の使用は歴史的な慣例によるものである。これは "q" でら始まるメディアタイプパ ラメータ名すべてを media-range として使用する邪魔になる。そのような出来事は IANA メディアタイプ登録機構で "q" パラメータの欠如と、Accept ですべてのメディアタイプ パラメータのまれな使用を与えられそうにないと信じられている。将来的なメディアタイ プは "q" と名前が付けられたすべてのパラメータを登録する事を思いとどまらせるべき である。 例 Accept: audio/*; q=0.2, audio/basic は "audio/basic が好まれるが、もしクオリティで 80% を上回って利用可能なら audio タイプのどんな物でも送ってほしい" と解釈すべきである。 もし Accept ヘッダフィールドがないなら、クライアントはすべてのメディアタイプを受 け入れるとみなされる。もし Accept ヘッダがあり、サーバが関連した Accept フィール ド値に従って適用できるレスポンスを送信できないなら、サーバは 406 (Not Acceptable ) レスポンスを返すべきである。 より複雑な例は: Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c これは言葉で言うと "text/html と text/x-c が望むメディアタイプであるが、もしそれ らが存在しないなら text/x-div エンティティを送り、もしそれも存在しないなら text- plain エンティティを送ってほしい" と解釈されるだろう。 メディアレンジはより具体的なメディアレンジや具体的なメディアタイプで置き換えられ る。もし複数のメディアレンジが与えられたタイプに当てはまるなら、もっとも具体的な 参照が優先する。たとえば、 Accept: text/*, text/html, text/html;level=1, */* は以下のように優先される: 1.) text/html;level=1 2.) text/html 3.) text/* 4.) */* 与えられたタイプに関連するメディアタイプクオリティ因子は、そのタイプに一致する最 高の優先権を伴うメディアレンジを見つける事により決定される。たとえば、 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5 は関連する以下の値をもたらす: text/html;level=1 = 1 text/html = 0.7 text/plain = 0.3 image/jpeg = 0.5 text/html;level=2 = 0.4 text/html;level=3 = 0.7 注意: ユーザエージェントはあるメディアレンジのためのクオリティ値のデフォルトセッ トを備え付けているかもしれない。しかしながら、ユーザエージェントが別のレンダリン グエージェントと互いに影響し合わないような閉鎖的なシステムでなければ、このデフォ ルトセットはユーザによって設定できるようにすべきである。 14.2 Accept-Charset Accept-Charset リクエストヘッダフィールドはどのような文字セットがレスポンスに適 用できるかを示すために使用される。このフィールドは、より包括的もしくは特別な目的 の文字セットを理解する能力があるクライアントが、それらの文字セットでドキュメント を表す能力のあるサーバにその性能を合図できるようにしている。ISO-8859-1 文字セッ トはすべてのユーザエージェントに適用できると想定される。 Accept-Charset = "Accept-Charset" ":" 1#( charset [ ";" "q" "=" qvalue ] ) 文字セット値は 3.4 章で記述される。それぞれの文字セットは文字セットに対するユー ザの優先度を表す関連するクオリティ値を与える事ができる。デフォルト値は q=1 であ る。例は以下のようになる。 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 もし Accept-Charset ヘッダが与えられていないなら、デフォルトはどんな文字も受け入 れると言う事である。Accept-Charset ヘッダが与えられ、サーバが Accept-Charset ヘ ッダに従って適用できるレスポンスを返す事ができなければ、サーバは 406 (Not Accept able) ステータスコードを伴うエラーレスポンスを送信するべきであるが、受け入れでで きないレスポンスの送信もみとめられる。 14.3 Accept-Encoding Accept-Encoding リクエストヘッダフィールドは Accept と似ているが、レスポンスにお いて受け入れが可能な内容コーディング値 (14.12 章) を制限する。 Accept-Encoding = "Accept-Encoding" ":" #( content-coding ) この使用の例は Accept-Encoding: compress, gzip もしリクエストで Accept-Encoding ヘッダが与えられていなければ、サーバはクライア ントがどんな内容コーディングも受け入れるであろうと言う事を仮定できる。Accept-Enc oding ヘッダが与えられ、サーバが Accept-Encodingに従って受け入れ可能なレスポンス を送る事ができなければ、サーバは 406(Not Acceptable) ステータスコードを伴うエラ ーレスポンスを送信すべきである。 空の Accept-Encoding 値は何も受け入れられない事を表している。 14.4 Accept-Language Accept-Language リクエストヘッダフィールド値は Accept と似ているが、リクエストに 対するレスポンスとしてより優先される自然言語のセットを制限する。 Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) それぞれの language-range は、そのレンジによって詳述される言語に対するユーザの優 先度の評価を制限する、関連するクオリティ値を与える事ができる。クオリティ値のデフ ォルトは "q=1" である。たとえば、 Accept-Language: da, en-gb;q=0.8, en;q=0.7 は "デンマーク語が優先されるが、イギリス英語と英語の別のタイプも受け入れるつもり がある" と言う事を意味する。もし言語タグと厳密に等価か、プレフィクスに続く最初の タグ文字が "-" であるようなそのタグのプレフィクスと厳密に等価であれば、language- range は言語タグと一致する。もしAccept-Language フィールドにおいて与えられるなら 、特別なレンジ "*" はAccept-Language フィールドで別のどんなレンジ表現にも一致し ないすべてのタグと一致する。 注意: このプレフィクス一致ルールの使用は、ユーザがあるタグの言語を理解するならこ のタグがプレフィクスであるようなタグが付くすべての言語も理解するだろうと言う事が 常に正しい方法において、言語タグが言語に割り当てられると言う事をを暗黙的に意味す る。このプレフィクスルールはもしそれがこれに当てはまるならプレフィクスタグの使用 を単純に認めている。 Accept-Language フィールドによって言語タグに割り当てられる言語クオリティ因子は、 言語タグと一致するフィールドでもっとも長い言語タグのクオリティ値である。もしフィ ールド内のどの language-range ともタグが一致しなければ、言語クオリティ因子は 0 に割り当てられる。もしリクエストで Accept-Language が与えられなければ、サーバは すべての言語が等しく受け入れ可能であるとみなすべきである。もし Accept-Language ヘッダが与えられるなら、0 以上のクオリティ因子を割り当てられたすべての言語が受け 入れられる。 リクエストごとにユーザの完全な言語上の優先を伴う Accept-Language を送ことは、ユ ーザのプライバシー期待に反するだろう。この問題の論議のため、15.7 章参照。 注意: 言語理解は個々のユーザに高く依存するため、クライアントアプリケーションはユ ーザに利用可能な言語上の優先度の選択ができるようにする事が勧められる。もしこの選 択が利用できるものとならなければ、Accept-Language はリクエストに与えられてはなら ない。 14.5 Accept-Ranges Accept-Ranges レスポンスヘッダフィールドはサーバがリソースに対するレンジリクエス トの受理を示せるようにしている: Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges acceptable-ranges = 1#range-unit | "none" byte-range リクエストを受け入れたオリジンサーバは以下を送る事ができるが: Accept-Ranges: bytes そうする必要はない。クライアントはリソースに伴われるこのヘッダを受け取っていなく ても byte-range リクエストを生成する事ができる。 あるリソースに対するどんなレンジのリクエストも受け入れないサーバはクライアントに レンジリクエストを想定していない事を知らせるため: Accept-Ranges: none を送る事ができる。 14.6 Age Age レスポンスヘッダフィールドは、オリジンサーバでレスポンス (もしくはその正当性 再確認) が生成されてからの時間のサーバ概算を知らせる。キャッシュされたレスポンス は、もしその年齢がその新鮮さ持続時間を超過していなければ "新鮮" である。Age 値は 13.2.3 章において詳述されるように計算される。 Age = "Age" ":" age-value age-value = delta-seconds Age 値は負でない 10 進整数値であり、秒を表している。 もしキャッシュが表現できる最大の正の整数よりも大きい値を受け取ったり、その年齢計 算のすべてがオーバーフローになれば、2147483648 (2^31) の値を伴う Age ヘッダを送 信しなければならない。HTTP/1.1 キャッシュはレスポンスごとに Age ヘッダを送らなけ ればならない。キャッシュは最低 31ビットレンジの算術型を使用すべきである。 14.7 Allow Allow エンティティヘッダは Request-URI によって識別されるリソースでサポートされ るメソッドのセットをリストする。このフィールドの目的は厳密に言えば受け取り側にリ ソースに関連する正当なメソッドを知らせる事である。Allow ヘッダフィールドは 405 ( Method Not Allowed) において必ず与えられなければならない。 Allow = "Allow" ":" 1#method 使用例: Allow: GET, HEAD, PUT このフィールドはクライアントに他のメソッドを試させないようにできる。しかしながら 、Allow ヘッダフィールド値によって与えられる指示はフォローされるべきである。許可 されたメソッドの実際のセットはオリジンサーバによってそれぞれのリクエストの時点で 定義される。 Allow ヘッダフィールドは新しいもしくは置き換えられたリソースによってサポートされ るメソッドを勧めるため PUT リクエストで供給される事ができる。サーバはこれらのメ ソッドをサポートする必要はなく、実際にサポートされているメソッドを与えるためレス ポンスに Allow ヘッダを加えるべきである。 ユーザエージェントがオリジンサーバとの通信の別の意味を持つ事ができるため、記述さ れたメソッドすべてが理解できなければプロキシは Allow ヘッダを修正してはならない 。 Allow ヘッダフィールドはどんなメソッドがサーバレベルで実装されているかを示さない 。サーバはサーバ全体としてどんなメソッドが実装されているかを記述するため Public レスポンスヘッダフィールド (14.35 章) を使用する事ができる。 14.8 Authorization サーバに自身を認証する事を望むユーザエージェント たいてい、但し必要ではないが、4 01 レスポンスを受け取った後 はリクエストに Authorizationリクエストヘッダフィール ドを加える事によってそうする事ができる。Authorization フィールド値はリクエストさ れているリソースの realm に対するユーザエージェントの認証情報を含む信用証明から なる。 Authorization = "Authorization" ":" credentials HTTP アクセス認証は 11 章で記述されている。リクエストが認証され realmが記述され ているなら、同じ信用証明はこの realm 内での別のすべてのリクエストに対して正当で あるべきである。 共有されているキャッシュ (13.7 章参照) が Authorization ヘッダを含むリクエストを 受け取ったら、以下に記述した例外の一つでなければ、他のすべてのリクエストの応答と して相当するレスポンスを返してはならない: 1. もしレスポンスが "proxy-revaliate" Cache-Control 命令を含んでいるなら、キ ャッシュはそのレスポンスを続くリクエストの応答に使用する事ができるが、プロキシ キャッシュは最初に、オリジンサーバが新しいリクエストを認証できるように、新しい リクエストのリクエストヘッダを使用して、それをオリジンサーバについて正当性の再 確認を行わなければならない。 2. もしレスポンスが "must-revalidate" Cache-Control 命令を含んでいる なら、キ ャッシュはそのレスポンスを続くリクエストの応答に使用する事ができるが、すべての キャッシュは最初に、オリジンサーバが新しいリクエストを認証できるように、新しい リクエストのリクエストヘッダを使用して、それをオリジンサーバについて正当性の再 確認を行わなければならない。 3. もしレスポンスが "public" Cache-Control 命令を含むなら、続くどんなリクエス トの応答にも返す事ができる。 14.9 Cache-Control Cache-Control 一般ヘッダは、リクエスト/レスポンス連鎖上のすべてのキャッシングメ カニズムが従わなければならない命令を詳述するために使用される。命令は、キャッシュ がリクエストやレスポンスを不利に妨害させないようにする事を目的とする動作を詳述す る。典型的にこれらの命令はデフォルトキャッシングアルゴリズムを無効にする。キャッ シュ命令はリクエストにおける命令のレスポンスが、同じ命令がレスポンスで与えられる べきであるという事を暗に意味しない事において単一指向性である。 HTTP/1.0 キャッシュは Cache-Control を実装していないかもしれなく、Pragma: no-cac he (14.32 章参照) のみを実装しているかもしれないと言う事に注意。 命令がリクエスト/レスポンス連鎖上のすべての受け取り人に適用できるため、そのアプ リケーションの重要性に関係なく、キャッシュ命令はプロキシやゲートウェイアプリケー ションを通り抜けなければならない。具体的なキャッシュのための cache-directive を 詳述するのは不可能である。 Cache-Control = "Cache-Control" ":" 1#cache-directive cache-directive = cache-request-directive | cache-response-directive cache-request-directive = "no-cache" [ "=" <"> 1#field-name <"> ] | "no-store" | "max-age" "=" delta-seconds | "max-stale" [ "=" delta-seconds ] | "min-fresh" "=" delta-seconds | "only-if-cached" | cache-extension cache-response-directive = "public" | "private" [ "=" <"> 1#field-name <"> ] | "no-cache" [ "=" <"> 1#field-name <"> ] | "no-store" | "no-transform" | "must-revalidate" | "proxy-revalidate" | "max-age" "=" delta-seconds | cache-extension cache-extension = token [ "=" ( token | quoted-string ) ] どんな 1#field-name パラメータもなしに命令が現れたら、命令はリクエストやレスポン ス全体に適用される。そのような命令が 1#field-name パラメータを伴って現れたら、指 定されたフィールド (複数かもしれない) のみに適用され、リクエストやレスポンスの残 りの部分には適用されない。このメカニズムは拡張可能である。HTTP プロトコルの将来 のバージョンのインプリメンテーションはこれらの命令を HTTP/1.1 で定義されていない ヘッダフィールドに適用する事ができる。 cache-control 命令はこれらの一般的なカテゴリに分類される。 * キャッシュ可能なものの制限; オリジンサーバのみがこれらを課す事ができる。 * キャッシュによって保存されるものの制限; オリジンサーバとユーザエージェント のどちらかによってこれらを課す事ができる。 * 基本的な満期メカニズムの変更; オリジンサーバとユーザエージェントのどちらか によってこれらを課す事ができる。 * キャッシュの正当性再確認と再読み込みの抑制; ユーザエージェントのみがこれら を課す事ができる。 * エンティティの変換の抑制。 * キャッシングシステムの拡張。 14.9.1 キャッシュ可能なもの もしリクエストメソッド、リクエストヘッダフィールド、レスポンスステータスがキャッ シュ可能であると示しているなら、デフォルトによりレスポンスはキャッシュ可能である 。13.4 章はキャッシュ可能性のためのこれらのデフォルトを要約している。以下の Cach e-Control レスポンス命令はオリジンサーバにレスポンスのデフォルトのキャッシュ可能 性を無効にできるようにする。 public たとえそれが通常はキャッシュ可能でなかったり、非共有キャッシュ内でのみキャッ シュ可能であったとしても、レスポンスがすべてのキャッシュによってキャッシュ可能で ある事を示す (追加の詳細のため Authorization, 14.8 章も参照)。 private レスポンスメッセージのすべてもしくは一部が単一のユーザのために用意された物で ある事を示し、供給されたキャッシュによってキャッシュされてはならない。これはオリ ジンサーバが、レスポンスの記述された部分があるユーザにのみ用意されたもので、別の ユーザによるリクエストのための正当なレスポンスではないことを言明できるようにする 。private (非共有) キャッシュはそのレスポンスをキャッシュできる。 注意: この private と言う命令の使用はレスポンスがキャッシュできるところのみを制 御し、メッセージ内容のプライバシーは保証できない。 no-cache レスポンスメッセージのすべてもしくは一部はどんな所でもキャッシュされてはなら ない。これは、オリジンサーバがクライアントリクエストに古くなったレスポンスを返す よう設定されているキャッシュによるキャッシングを行えないようにする。 注意: ほとんどの HTTP/1.0 キャッシュはこの命令を認識したりしたがったりす る事は ないだろう。 14.9.2 キャッシュによって保存できるもの 保存しない命令の目的は取り扱いが慎重な情報 (たとえばバックアップテープ上のもの) の不注意な漏洩や保留を防ぐ事である。保存しない命令はメッセージ全体に適用し、レス ポンスかリクエストのどちらかで送られる。もしリクエストで送られるなら、キャッシュ はこのリクエストかそれへのレスポンスのどちらかのどんな部分も保存してはならない。 それがレスポンスで送られるならキャッシュはこのレスポンスやそれを引き起こしたリク エストのどちらかを保存してはならない。この命令は非共有と共有キャッシュの両方に適 用する。この状況における "保存してはならない" は、キャッシュが不揮発性保存媒体に その情報を故意に保存してはならなく、それを転送した後可能な限り早急に揮発性保存媒 体から情報の削除を試みる最高の努力を行わなければならない。 さらにその命令がレスポンスに関連しているとき、ユーザはキャッシングシステムの外側 にそのようなレスポンスを明白に保存できる (例: "Save As" ダイアログを伴って)。履 歴バッファはこれらの通常操作の一部としてこのようなレスポンスを保存する事ができる 。 この命令の目的はキャッシュデータ構造への予期されないアクセス経由で情報の偶発的な 漏洩について心配されるあるユーザやサービスの著者の言明された要求に合うためである 。この命令の使用はいくつかの場合においてプライバシーを改善するだろうが、われわれ はプライバシーを保証するための信頼できるもしくは十分なメカニズムのどのような方法 におけるものでもない事を警告する。特に、悪意のあるキャッシュや妥協されたキャッシ ュはこの命令を認識したりしたがったりしないかもしれない。そして通信ネットワークは 盗聴に無防備であるかもしれない。 14.9.3 基本満期メカニズムの修正 エンティティの満期期間は Expires ヘッダ (14.21 章) を使ってオリジンサーバにより 詳述できる。あるいは、レスポンスで max-age 命令を使って記述する事もできる。 模試レスポンスが Expires ヘッダと max-age 命令の両方を含んでいるなら、たとえ Exp ires ヘッダがより限定的だとしても、max-age 命令は Expires ヘッダに取って代わる。 このルールは与えられたリクエストに対してオリジンサーバが HTTP/1.0 キャッシュより も HTTP/1.1 (とその上位) キャッシュに長い満期期間を供給できるようにする。これは 、もし多分同期していないクロックのため特定の HTTP/1.0 キャッシュが不適当に年齢や 満期期間の計算をする場合に有用であろう。 注意: 最も古いキャッシュ この仕様書に従っていない はどんな Cache-Control 命令も 実装していない。HTTP/1.1 に従うキャッシュによるキャッシングを制限するが妨げない Cache-Control 命令を使う事を望むオリジンサーバは、max-age 命令が Expires ヘッダ を置き換えるという条件を使用する事ができ、事実 HTTP/1.1 に従っていないキャッシュ は max-age 命令に注目していない。 他の命令はユーザやユーザエージェントが基本満期メカニズムを修正できるようにする。 これらの命令はリクエストにおいて記述できる: max-age クライアントが記述された秒時間よりも大きな年齢を持たないレスポンスを受け入れ ようと思っている事を示す。max-stale 命令が含まれていないならクライアントは古くな ったレスポンスを受け入れようと思っていない。 min-fresh クライアントは新鮮さ持続期間が少なくとも秒においてその現在の年齢プラス記述さ れた時間であるレスポンスを受け入れようと思っている事を示す。これは、クライアント が少なくとも記述された秒数に対してまだ新鮮であるレスポンスを望んでいると言う事で ある。 max-stale クライアントはその満期期間を超えているレスポンスを受け入れようと思っている事 を示す。もし max-stale が値を割り当てられているなら、クライアントは多くても記述 された秒数によってその満期期間をすでに超えているレスポンスを受け入れようと思って いる。もし max-stale に値が割り当てられていないなら、クライアントはどんな年齢の 古くなったレスポンスも受け入れようと思っている。 リクエストの max-stale 命令かキャッシュがレスポンスの満期期間を置き換えるように 構成されているかのどちらかにより、もしキャッシュが古くなったレスポンスを返すなら 、キャッシュは Warning 10 (Response is stale) を使って古くなったレスポンスに War ning ヘッダを追加しなければならない。 14.9.4 キャッシュの正当性再確証と再ロード制御 時々ユーザエージェントは、キャッシュがオリジンサーバ (オリジンサーバへの経路上の 次のキャッシュではなく) にキャッシュエンティティの再確証を行ったり、オリジンサー バからそのキャッシュエンティティの再ロードを要求する事を望み要求するかもしれない 。end-to-end 正当性再確証はキャッシュとオリジンサーバのどちらかがキャッシュされ たレスポンスの満期期間を過大評価している場合に必要であろう。end-to-end 再ロード はキャッシュエンティティがある理由のため古くなっている場合に必要であろう。 end-to-end 正当性再確証は、クライアントが自身のローカルにキャッシュされたコピー を持っていないとき われわれはこの場合を "詳述されない end-to-end 正当性再確証" と呼ぶ や、クライアントがローカルにキャッシュされたコピーを持っているとき われわ れはこの場合を "詳述された end-to-end 正当性再確証" と呼ぶ のどちらかで必要とさ れるだろう。 クライアントは Cache-Control リクエスト命令を使用してこれらの三種類の動作を詳述 する事ができる: End-to-end reload リクエストが "no-cache" Cache-Control 命令や HTTP/1.0 クライアントの互換性の ための "Pragma: no-cache" を含んでいる。リクエストにおいて no-cache 命令に伴うど んなフィールド名も含まれない。サーバはそのようなリクエストに応答するときキャッシ ュされたコピーを使ってはならない。 Specific end-to-end revalidation リクエストは "max-age=0" Cache-Control 命令を含み、これは強制的にオリジンサー バへの経路上のそれぞれのキャッシュに次のキャッシュやサーバに対してそのエンティテ ィを正当性再確証させる。最初のリクエストはクライアントの現在の確証子を伴うキャッ シュ正当性確証条件を含んでいる。 Unspecified end-to-end revalidation リクエストが "max-age=0" Cache-Control 命令を含み、これは強制的にオリジンサー バへの経路上のそれぞれのキャッシュに次のキャッシュやサーバに対してそのエンティテ ィの正当性再確証させる。最初のリクエストはキャッシュ正当性確証条件を含んでいない 。そのリソースに対するキャッシュエンティティを持っている経路上の最初のキャッシュ (もしあれば) はその現在の確証子を伴うキャッシュ正当性確認条件を追加する。 中間キャッシュが max-age=0 によって強制的にそのキャッシュエンティティの正当性再 評価を行い、クライアントはリクエストに自身の確証子を供給するとき、供給された確証 子はキャッシュエンティティに現在保存されている確証子と異なるかもしれない。この場 合、キャッシュはセマンティクス透過性へ影響する事なくそれ自身のリクエストを作る事 においてどちらかの確証子を使う事ができる。 しかしながら、確証子の選択はパフォーマンスに影響するかもしれない。最良のアプロー チは中間キャッシュがそのリクエストを作るとき自身の確証子を使う事である。もしサー バが 304 (Not Modified) を返すならキャッシュはクライアントに 200 (OK) レスポンス とその新しく正当性が確証されたコピーを返すべきである。しかしながら、もしサーバが 新しいエンティティとキャッシュ確証子をかえすなら、中間キャッシュは強い比較機能を 使用して返された確証子とクライアントのリクエストにおいて与えられたそれとを比較す べきである。もしクライアントの確証子がオリジンサーバのものと等しいなら、中間キャ ッシュは単純に 304 (Not Modified) を返す。もしそうでなければ、200 (OK)レスポンス を伴う新しいエンティティを返す。 もしリクエストが no-cache 命令を含んでいるなら、min-fresh, max-stale,max-age を 含むべきではない。 ネットワーク接続が極端に貧弱ないくつかの場合、クライアントはキャッシュが現在すで に保存しているそれらのレスポンスのみを返し、オリジンサーバに再ロードや正当性再確 証を行わない事を望むだろう。これを行うため、クライアントはリクエストにおいて onl y-if-cached 命令を含む事ができる。もしこの命令を受信したら、キャッシュはリクエス トの別の制約と一致するキャッシュされたエンティティを使用して返すか、504 (Gateway Timeout) ステータス付きで返すかどちらかを行うべきである。しかしながら、もしキャ ッシュのグループが良好な内部接続を伴う統合されているシステムとして操作されている なら、そのようなリクエストはキャッシュのそのグループ内に転送できる。 キャッシュがサーバの詳述した満期期間を無視するように構成できるため、そしてクライ アントリクエストは max-stale 命令 (これは類似した影響を持つ)を含む事ができるため 、プロトコルはどのような続く使用でもオリジンサーバにキャッシュエンティティの正当 性再確証を要求するためのメカニズムを含む。must-revalidate 命令がキャッシュによっ て受信されたレスポンスに存在する時、そのキャッシュは最初にオリジンサーバにそれを 正当性再確証する以外は引き続くリクエストに応答するため古くなった後のエンティティ を使ってはならない (例: キャッシュは毎回 end-to-end 再確証をしなければならず、も し、単にオリジンサーバの Expires か max-age 値に基づいているなら、キャッシュされ たレスポンスは古くなっている)。 must-revalidate 命令はあるプロトコル機構のための信頼できる操作をサポートするため に必要である。すべの状況において HTTP/1.1 キャッシュは must-revalidate 命令に従 わなければならない。特に、もしキャッシュが何らかの理由でオリジンサーバに達せない なら、504 (Gateway Timeout) レスポンスを生成しなければならない。 黙って実行されない財務的処理のように、エンティティのリクエストを再確証する事の失 敗が不適当な操作と言う結果になる場合、かつその場合に限り、サーバは must-revalida te 命令を送るべきである。受け取り側はこの命令に違反するどんな自動動作も行っては ならず、もし再確証が失敗するならエンティティの確証が行われていないコピーを自動的 に供給してはならない。 これは奨励されないが、ひどい接続制約の元で操作しているユーザエージェントはこの命 令に違反する事ができるが、もしそうするなら、確証されていないレスポンスが供給され た事をユーザに明確に警告しなければならない。この警告は確証されていないアクセスそ れぞれに供給されなければならず、ユーザの明確な確認を必要とすべきである。 proxy-revalidate 命令が非共有ユーザエージェントキャッシュに適用されない事を除い て、proxy-revalidate 命令は must-revalidate 命令と同じ意味を持つ。多くのユーザに サービスしているプロキシは毎回再確証することを必要とする (それぞれのユーザが認証 されている事を保証するため) 一方で、これはユーザのキャッシュに保存される事を許可 する認証されたリクエストへのレスポンスに使用され、後にそれの再確証を必要としない でレスポンスを返す事ができる (それがこのユーザによって既に一度認証されているため )。このような認証されたレスポンスはそれらがすべてキャッシュされるようにするためp ublic キャッシュ制御命令を必要とする事に注意。 14.9.5 非変換命令 中間キャッシュ (プロキシ) の実装者はあるエンティティボディのメディアタイプを変換 する事が有用である事に気づいている。たとえば、プロキシはキャッシュスペースを節約 するためや遅い通信上のトラフィックの量を減らすため画像フォーマットの変換を行う事 ができる。HTTP は今日までこれらの変換に付いて語らない。 しかしながら、これらの変換がある種のアプリケーションのために意図されたエンティテ ィボディに適用されるときに深刻な操作上の問題が既に起きている。たとえば、医学上の 映像のためのアプリケーション、科学的なデータ分析、end-to-end 認証にそれらを使う もの、元のエンティティボディと全く同一のビット対ビットのエンティティボディの受信 に依存するすべてである。 それゆえ、もしレスポンスが非変換命令を含んでいるなら、中間キャッシュやプロキシは 非変換命令に従うものとして 13.5.2 章でリストされているそれらのヘッダを変更しては ならない。これはキャッシュやプロキシがこれらのヘッダによって詳述されたエンティテ ィボディのどのような局面も変更してはならない事を意味している。 14.9.6 キャッシュ制御拡張 Cache-Control ヘッダフィールドはそれぞれにオプション的に割り当てられた値を伴う一 つ以上のキャッシュ拡張トークンを使用する事で拡張可能である。情報的拡張 (キャッシ ュ動作で変更を必要としないもの) は他の命令のセマンティクスを変えないで追加できる 。動作的拡張命令は既存の基本キャッシュ命令への修飾子として動作する事により機能す るために設計されている。新しい命令を理解しないアプリケーションが標準命令によって 詳述される動作をデフォルトとし、新しい命令を理解するそれらは標準命令に関係する必 要性を置き換えるようにそれを認識するように、新しい命令と標準命令の両方は適用され る。この方法において、Cache-Control 命令の拡張はその基本プロトコルの変更を要求す る事なく作る事ができる。 この拡張メカニズムは、それに特有の HTTP バージョンによって定義されるすべての cac he-control 命令に従い、特有の拡張に従い、理解できない命令をすべて無視する HTTP キャッシュに依存する。 たとえば、仮に "private" 命令の修飾子として動作する "community" と呼ばれる新しい レスポンス命令を考える。われわれはこの新しい命令を、この値で名前付けされた集団の メンバによって共有されるすべてのキャッシュ、さらに非共有キャッシュのみがレスポン スをキャッシュできると言う意味に定義する。"UCI" 集団がそれらの共有されたキャッシ ュでプライベートレスポンスとは別に使用できるように望むサーバは、以下を含む事でそ れを行える。 Cache-Control: private, community="UCI" キャッシュが "community" キャッシュ拡張を理解しないなら、それが "private"命令を 確かめて理解し、従ってデフォルトの安全な動作を行うため、このヘッダフィールドを確 かめたキャッシュは正しく動作するだろう。 認識できないキャッシュ命令は無視されなければならない。キャッシュ動作がキャッシュ が拡張を理解しないなら最小限正しいままであるであろうように、HTTP/1.1 キャッシュ により認識されないようなすべてのキャッシュ命令は標準命令 (やレスポンスのデフォル トキャッシュ可能性) と結合するだろう。 14.10 Connection Connection 一般ヘッダフィールドは、送り側がその固有の接続を望まれるオプションを 詳述できるようにし、その先の接続でプロキシによって通信されてはならない。 Connection ヘッダは以下の文法を持つ: Connection-header = "Connection" ":" 1#(connection-token) connection-token = token HTTP/1.1 プロキシはメッセージが転送される前に Connection ヘッダフィールドを解析 し、このフィールドのそれぞれの connection-token に対して、どんなヘッダも connect ion-token と同じ名前が付随するメッセージから取り除かなければならない。追加的なヘ ッダフィールドはもしこの接続オプションに関連するパラメータが存在しなければ送られ ないかもしれないため、追加的なヘッダフィールドに相当するどんな物によってでもなく 、接続オプションは Connection ヘッダフィールドの connection-token の存在によって 合図される。HTTP/1.1 は、送り側が接続がレスポンスの完了後にクローズされるであろ う事を合図するため "close" 接続オプションを定義する。たとえば、リクエストかレス ポンスヘッダフィールドのどちらかにおける Connection: close は、現在のリクエスト/レスポンスの完了後に接続が `永続的' (8.1 章) とみなすべきで はないと言う事を示している。 永続的な接続をサポートしていない HTTP/1.1 アプリケーションは、それぞれのメッセー ジに "close" 接続オプションを加えなければならない。 14.11 Content-Base Content-Base エンティティヘッダフィールドはエンティティにおける相対的な URL を解 決するためのベース URI を記述するために使用される。このヘッダフィールドは RFC 18 08 において Base として記述され、これは改訂されると思われる。 Content-Base = "Content-Base" ":" absoluteURI もし Content-Base フィールドが与えられなければ、エンティティのベースURI はその C ontent-Location (もし Content-Location URI が絶対 URI なら)かリクエストを始める ために使用された URI のどちらかによって、この順番の優先度で定義される。しかしな がら、エンティティボディ内の内容のベースURI はエンティティボディの中で再定義され ているかもしれないと言う事に注意。 14.12 Content-Encoding Content-Encoding エンティティヘッダフィールドはメディアタイプの修飾子として使用 される。これが与えられるとき、その値はどんな付加されたコーディングがエンティティ ボディに適用されているか、従って Content-Typeヘッダフィールドによって参照される メディアタイプを得るために、どんなコーディングメカニズムを適用しなければならない かを示している。Content-Encoding は第一に、ドキュメントがその根本的なメディアタ イプの個性を失わないで圧縮できるように使用されている。 Content-Encoding = "Content-Encoding" ":" 1#content-coding 内容コーディングは 3.5 章で定義されている。その使用例は以下のようになる。 Content-Encoding: gzip Content-Encoding は Request-URI によって識別されるエンティティの特質である。典型 的には、エンティティボディはこのエンコーディングを伴って保存され、レンダリングや 類似した使用前にのみデコードされる。 もし複数のエンコーディングがエンティティに適用されているなら、内容コーディングは それらが適用された順番でリストされなければならない。 エンコーディングパラメータに関する付加的な情報は、この仕様書で定義されていない別 のエンティティヘッダフィールドによって供給する事ができる。 14.13 Content-Language Content-Length エンティティヘッダフィールドは同封されたエンティティのために用意 された視聴者の自然言語を記述する。これがエンティティボディ内に使用されているすべ ての言語と等しいわけではないと言う事に注意。 Content-Language = "Content-Language" ":" 1#language-tag 言語タグは 3.10 章で定義されている。Content-Language の第一の目的は、ユーザがユ ーザの提案した言語に従うエンティティを見分け、識別できるようにするためである。従 って、もし本体の内容がデンマーク語を読める視聴者に対してのみ用意されているのであ れば、適切なフィールドは以下のようになる。 Content-Language: da もし Content-Language が記述されていなければ、デフォルトは内容がすべての言語の視 聴者のために用意されているものである。これは、送り側がそれをどんな自然言語に特有 のものかを考慮しない、もしくは送り側が用意されている言語に関して知らないと言う事 を意味する事ができる。 複数の言語は複数の視聴者のために用意された内容に対してリストされる事ができる。た とえば、オリジナルのマオリ語と英語バージョンで同時に与えられる "Treaty of Waitan gi" の解釈は、以下のように呼ばれる。 Content-Language: mi, en しかしながら、複数の言語が一つのエンティティ内で与えられるという理由で複数の言語 の視聴者のために用意されていると言う事を意味するわけではない。"A First lesson in Latin" のような初心者の言語入門書が良い例であり、これは明らかに英語を読める視聴 者によって使用される事を目的としている。この場合、Content-Language は "en" のみ を含むべきである。 Content-Language はどのようなメディアタイプにも適用できる これはテキストドキュメ ントにのみ限定されていない。 14.14 Content-Length Content-Length エンティティヘッダフィールドは 8 ビットバイトの 10 進数値で受信側 に送られるメッセージボディのサイズ、もしくは HEAD メソッドの場合には GET リクエ ストのときに送られるであろうエンティティボディのサイズを示している。 Content-Length = "Content-Length" ":" 1*DIGIT 例は以下のようになる。 Content-Length: 3495 アプリケーションはエンティティのメディアタイプに関係なく、転送されるメッセージボ ディのサイズを示すためにこの値を使用すべきである。たとえばリクエストが正当な Con tent-Length を持ち、Transfer-Encoding:chunked かマルチパートボディを使用するため 、エンティティボディを含んでいる HTTP/1.1 リクエストの終端を受け取り側が確実に決 定できなければならない。 0 以上のどんな Content-Length も正当な値である。404 章は Content-Lengthが与えら れないときのメッセージボディの長さをどのように決定するかを記述している。 注意: "message/external-body" の内容タイプ内で使用されているオプション的なフィー ルドだと言う部分で、このフィールドの意味は MIME で定義されているものと非常に異な る。HTTP では、メッセージの長さが転送される前に決定できるときに送るべきである。 14.15 Content-Location Content-Location エンティティヘッダフィールドはメッセージに同封されたエンティテ ィに対するリソースロケーションを供給するために使用される。リソースがそれに関連す る複数のエンティティを持ち、それらが個別にアクセスされるような場合、サーバは返さ れる固有のバリアントに対して Content-Location を提供すべきである。それに加え、サ ーバはリソースエンティティに相当するリソースへの Content-Location を提供すべきで ある。 Content-Location = "Content-Location" ":" ( absoluteURI | relativeURI ) もし Content-Base ヘッダフィールドが与えられなければ、Content-Locationの値はエン ティティに対するベース URL を定義する (14.11 章参照)。 Content-Location 値はリクエストされた元の URI への代用ではない。リクエストの時点 でこの固有なエンティティに相当するリソースのロケーションのステートメントのみであ る。もし要請がその固有なエンティティのソースを識別する事なら、将来的なリクエスト は Content-Location URI を使用する事ができる。 キャッシュは、エンティティを回収するために使用された URI と異なるContent-Locatio n を伴うものが、その Content-Location URI の後のリクエストに応じるために使用でき ると言う事を仮定できない。しかしながら、Content-Location は 13.6 章で述べられて いるように、単一のリクエストされたリソースから回収される複数のエンティティを区別 するために使用する事ができる。 もし Content-Location が相対的な URI なら、その URI はレスポンスにおいて供給され るすべての Content-Base URI と相対的であると解釈される。もしContent-Base が与え られていなければ、相対的 URI は Request-URI と相対的であると解釈される。 14.16 Content-MD5 RFC 1864 [23] で定義されているように、Content-MD5 エンティティヘッダフィールドは エンティティボディの end-to-end メッセージ完全チェック(MIC: Message Integrity Ch eck) を供給のする目的の、エンティティボディの MD5 要約である。(注意: MIC は転送 においてエンティティボディの偶発的変更を検知するのに優れているが、悪意のあるアタ ックに対して試験済みではない。) Content-MD5 = "Content-MD5" ":" md5-digest md5-digest = Content-MD5 ヘッダフィールドはエンティティボディの完全チェックとして機能するため オリジンサーバによって生成される。オリジンサーバのみがContent-MD5 ヘッダフィール ドを生成する事ができる。プロキシやゲートウェイは、end-to-en 完全チェックとしての その値を無効にするためこれを生成してはならない。ゲートウェイやプロキシを含むすべ てのエンティティボディ受信者は、このヘッダフィールドの要約値が受信したエンティテ ィボディのものと一致するかをチェックする事ができる。 MD5 要約は、適用されているすべての Content-Encoding ただしメッセージボディに適用 されているどんな Transfer-Encoding も含まない を含むエンティティボディの内容に基 づいて計算されている。もしメッセージがTransfer-Encoding を伴って受信されたら、そ のエンコーディングはContent-MD5 値をチェックする前に取り除かれていなければならな い。 もし Transfer-Encoding が適用されていなければ、要約はエンティティボディが送られ るであろう物として、そしてその順に、エンティティボディの 8 ビットバイトで厳密に 計算されると言う結果を持つ。 HTTP は、この要約が MIME 合成式メディアタイプ (たとえば multipart/* とmessage/rf c822) に対して計算される事を許すため RFC 1864 を拡張するが、前述のパラグラフで定 義されているように、これは要約がどのように計算されるかの変更ではない。 注意: これのいくつかの影響が存在する。合成式タイプに対するエンティティボディは、 それぞれが自身の MIME と HTTP ヘッダ (Content-MD5, Content-Transfer-Encoding, Co ntent-ENcoding ヘッダを含む) を伴うたくさんのボディパートを含む事ができる。もし ボディパートが Content-Transfer-Encoding や Content-Encoding ヘッダを持つなら、 ボディパートの内容は適用されたエンコードを受け、ボディパートにはそのように 例え ばエンコード適用の後 Content-MD5 要約が加えられる。Transfer-Encoding ヘッダはボ ディパートの中に認められていない。 注意: Content-MD5 の定義が HTTP に対して MIME エンティティボディのための RFC 186 4 におけるものと正確に同じである間、HTTP エンティティボディへの Content-MD5 の適 用がその MIME エンティティボディへの適用と異なるいくつかの方法が存在する。MIME と違い、ある物は HTTP が Content-Transfer-Encoding を使用してなく、Transfer-Enco ding と Content-Encoding を使用していることである。別のものは HTTP が MIME より も頻繁にバイナリ内容を使用しているという事であり、そのような場合、要約を計算する ために使用されているバイト順序がタイプに対して定義された転送バイト順序であるとい う事を注意する価値がある。最後に、HTTP はいくつかの行末慣習のどんな物でも、そし て CRLF を使用する本当の公式形式ではないテキストタイプでの転送を認めている。CRLF へすべての行末の変換は要約を計算したりチェックしたりする前に行われるべきではない 。実際に転送されたテキストで使用されている行末変換は要約の計算を行っているときに 変更されないままにしておくべきである。 14.17 Content-Range Content-Range エンティティヘッダは、全エンティティボディにおいて部分的なボディが 挿入されるべき所の、記述された部分的なエンティティボディを伴って送信される。これ は全エンティティボディの総計サイズも示している。サーバがクライアントに部分的なレ スポンスを返すとき、レスポンスによって補われたレンジの程度とエンティティボディ全 体の長さの両方を記述しなければならない。 Content-Range = "Content-Range" ":" content-range-spec content-range-spec = byte-content-range-spec byte-content-range-spec = bytes-unit SP first-byte-pos "-" last-byte-pos "/" entity-length entity-length = 1*DIGIT byte-ranges-specifier 値と違い、byte-content-range-spec は一つのレンジのみを詳述 し、そしてレンジの最初と最後のバイトの両方に対する完全なバイト位置を含まなければ ならない。 last-byte-pos 値がその first-byte-pos 値よりも小さいか、entity-length値が last-b yte-pos 値以下の byte-content-range-spec は不正である。不正な byte-content-range -spec を受け取った受け取り側は、それとそれに伴って転送されたすべての内容を無視し なければならない。 以下はエンティティが全 1234 バイトを含んでいる事を仮定した byte-content-range-sp ec 値の例である。 * 最初の 500 バイト: bytes 0-499/1234 * 次の 500 バイト: bytes 500-999/1234 * 最初の 500 バイト以外のすべて: bytes 500-1233/1234 * 最後の 500 バイト: bytes 734-1233/1234 HTTP メッセージが単一のレンジの内容を含んでいるとき (例えば、単一のレンジに対す るリクエストや、重複しているが全く隙間がないレンジのセットに対するリクエストのレ スポンス)、この内容は実際に転送されたバイトの数を示している Content-Range ヘッダ と Content-Length ヘッダを伴って送られる。例えば、 HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif HTTP メッセージが複数のレンジの内容を含んでいるとき (例えば、複数の重複していな いレンジに対するリクエストのレスポンス)、これらはマルチパート MIME メッセージと して送られる。この目的で使用されるマルチパートMIME 内容タイプはこの仕様書で "mul tipart/byteranges" と定義されている。その定義に対しては付録 19.2 章参照。 MIME multipart/byteranges メッセージをデコードできないクライアントは、単一のリク エストで複数のバイトレンジを求めるべきではない。 クライアントが一つのリクエストで複数のバイトレンジを要求するとき、サーバはリクエ ストにおいて現れる順番でそれらを返すべきである。 もし byte-range-spec が不正なためサーバがそれを無視するなら、サーバは不正な Cont ent-Range ヘッダフィールドが存在していなかったかのようにリクエストを扱うべきであ る (通常、これはすべてのエンティティを含んでいる 200 レスポンスを返す意味となる) 。この理由は、クライアントがそのような不正なリクエストを作るであろう場合は、エン ティティが直前のリクエストによって回収されたエンティティよりも小さいときのみと言 うことである。 14.18 Content-Type Content-Type エンティティヘッダフィールドは受信側に送られたエンティティボディの メディアタイプ、もしくは HTED メソッドの場合、GET のリクエストで送られるメディア タイプを示している。 Content-Type = "Content-Type" ":" media-type メディアタイプは 3.7 章で定義されている。このフィールドの例は以下のようになる。 Content-Type: text/html; charset=ISO-8859-4 エンティティのメディアタイプを区別するための方法のさらなる論議は 7.2.1 章で供給 される。 14.19 Date Date 一般ヘッダフィールドはメッセージがもたらされた日付と時間に相当し、RFC 822 における orig-date と同じセマンティクスを持つ。フィールド値はHTTP-date であり、 これは 3.3.1 章で記述されている。 Date = "Date" ":" HTTP-date この例は以下のようになる。 Date: Tue, 15 Nov 1994 08:12:31 GMT もしメッセージがユーザエージェント (リクエストの場合) もしくはオリジンサーバ (レ スポンスの場合) への直接接続で受け取られたものなら、日付は受信した端末での現在時 刻であるとみなす事ができる。しかしながら、日付 それが発生したものが信じているよ うな はキャッシュされたレスポンスを評価するために重要である。クライアントは PUT や POST リクエストの場合のように、エンティティボディを含んでいるメッセージ内での み Date ヘッダフィールドを送るべきであり、その場合でもオプションである。Date ヘ ッダフィールドを含まない受信されたメッセージは、もしメッセージが受け取り側によっ てキャッシュされていたり Date を必要とするプロトコル経由でゲートウェイされている なら、受け取り側によってそれを割り当てるべきである。 理論上では、日付はエンティティが生み出されたちょうど瞬間を表すべきである。事実上 、日付はそのセマンティクス値に影響する事のない、メッセージ発生の間のあらゆる時間 に生成されうる。 Date のフォーマットは 3.3 章で HTTP-date として定義されているような完全な日付と 時間である。それは RFC1223 [8] 日付フォーマットで送られなければならない。 14.20 ETag ETag エンティティヘッダフィールドは関連するエンティティに対するエンティティタグ を定義する。エンティティタグに使用されているヘッダは 14.20, 14.25, 14.43 章で記 述される。エンティティタグは同じリソースの別のエンティティと比較のために使用する 事ができる (13.3.2 章参照)。 ETag = "ETag" ":" entity-tag 例: ETag: "xyzzy" ETag: W/"xyzzy" ETag: "" 14.21 Expires Expires エンティティヘッダフィールドはレスポンスが古くなったとみなされる経過時間 の日付/時間を与える。古くなったキャッシュエンティティは、もしオリジンサーバに ( もしくはエンティティの新鮮なコピーを持っている中間キャッシュに) 最初に正当性を確 認されたのでなければ、通常はキャッシュ(プロキシキャッシュかユーザエージェントキ ャッシュのどちらか) によって返されないだろう。満期モデルの更なる論議は 13.2 章参 照。 Expires フィールドの存在は、元のリソースがその時間よりも前に、もしくはそれより後 に変更もしくは存在を終了だろうという事を暗黙的に意味する。 フォーマットは 3.3 章における HTTP-date によって定義されるような完全な日付と時刻 である。これは RFC1123 日付フォーマットでなければならない: Expires = "Expires" ":" HTTP-date この使用例は以下のようになる。 Expires: Thu, 01 Dec 1994 16:00:00 GMT 注意: もしレスポンスが max-age 命令を伴う Cache-Control を含んでいるなら、その命 令は Expires フィールドに置き換えられるであろう。 HTTP/1.1 クライアントとキャッシュは別の不正な日付フォーマット、特に値"0" を含む ものを、過去のものである (例えば "既に期限切れ") として扱わなければならない。 レスポンスを "既に期限切れ" としてマークするためには、オリジンサーバはDate ヘッ ダ値と等しい Expires 日付を使うべきである(13.2.4 章の満期計算のルール参照)。 レスポンスを "決して期限が切れない" としてマークするためには、オリジンサーバはレ スポンスが送られた時間からおおよそ一年の日付を使用すべきである。HTTP/1.1 サーバ は将来において一年以上の Expires 日付を送るべきではない。 デフォルトでキャッシュ可能でない以外のレスポンスの将来におけるある時間の日付値を 伴う Expires ヘッダフィールドの存在は、もし Cache-Controlヘッダフィールド (14.9 章) による別の方法が指定されていなければ、レスポンスがキャッシュ可能である事を示 している。 14.22 From もしそれが与えられるなら、From リクエストヘッダフィールドはリクエストしているユ ーザエージェントをコントロールする人間のユーザのインターネット E-mail アドレスを 含むべきである。このアドレスは RFC 822 (RFC 1123によって更新された) でのメールボ ックスによる定義として、マシンの利用に適しているべきである: From = "From" ":" mailbox この例は以下のようになる。 From: webmaster@w3.org このヘッダフィールドはログを取る目的と、不正なリクエストや望まれていないリクエス トの原因を識別するための意味として使用する事ができる。これはアクセス保護の安全で ない形式として使用されるべきではない。このフィールドの解釈はリクエストが与えられ た人の支持の上に実行されている事であり、その人は実行されるメソッドに対する責任を 負う。特に、ロボットエージェントは受信側で問題起きたときロボットの実行に責任のあ る人へ連絡できるようにするためこのヘッダを含めるべきである。 このフィールドにおけるインターネット E-mail アドレスはリクエストを発行するインタ ーネットホストと分離される事ができる。例えばリクエストがプロキシを通しているとき 、元の発行者のアドレスが使用されるべきである。 注意: クライアントはユーザのプライバシー利害やそれらのサイトのセキュリティポリシ ーと矛盾するため、ユーザの承認なしに From ヘッダフィールドを送るべきではない。ユ ーザが可能にしたりしなかったり、リクエストに先立ってどんな時でもこのフィールドの 値を修正できる事が強く推奨される。 14.23 Host Host リクエストヘッダフィールドはユーザや参照しているリソースによって与えられる オリジナル URL から得られるような (一般的には 3.2.2 章で記述されているような HTT P URL)、リクエストされているリソースのインターネットホストとポート番号を記述する 。Host フィールド値は元の URL によって与えられるオリジンサーバやゲートウェイのネ ットワークロケーションを表さなければならない。これはオリジンサーバやゲートウェイ に、同じ IP アドレス上の複数のホスト名のルート "/" URL のような、内部的にあいま いな URLを区別できるようにする。 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 どんなポート情報も後に続いていない "host" はリクエストされたサービスに対するデフ ォルトポート (例えば HTTP URL は "80") を暗黙的に意味する。例えば、 に対するオリジンサーバのリクエストは以下を含まなければならない。 GET /pub/WWW/ HTTP/1.1 Host: www.w3.org クライアントはインターネット上のすべての HTTP/1.1 リクエストメッセージ(例えば、 リクエストされたサービスに対するインターネットホストアドレスを含む URL に対する リクエストに相当するすべてのメッセージ上で) に Hostヘッダフィールドを含まなけれ ばならない。もし Host フィールドがまだ与えられていなければ、HTTP/1.1 プロキシは インターネット上でそれを転送する前にリクエストメッセージに Host フィールドを追加 しなければならない。すべてのインターネットベース HTTP/1.1 サーバは Host ヘッダフ ィールドが欠如したすべての HTTP/1.1 リクエストメッセージに 400 ステータスコード を返さなければならない。 Host に関連する別の要求に対して 5.2 と 19.5.1 章参照。 14.24 If-Modified-Since If-Modified-Since リクエストヘッダフィールドは GET メソッドを条件付きにさせるた めに使用される。もしリクエストされたバリアントがこのフィールドで記述された時間か ら更新されていなければ、エンティティはサーバから返されない。代わりに 304 (Not Mo dified) レスポンスがメッセージボディを伴わないで返されるだろう。 If-Modified-Since = "If-Modified-Since" ":" HTTP-date このフィールドの例は: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT Range ヘッダがなく If-Modified-Since ヘッダを伴う GET メソッドは、識別されたエン ティティが If-Modified-Since ヘッダによって与えられる日付から更新されている場合 のみ転送される。これを決定するアルゴリズムは以下の場合を含んでいる。 a) もしリクエストが通常は 200 (OK) 以外の何かを結果として生じるか、渡された If -Modified-Since 日付が不正であるなら、レスポンスは通常の GET と明らかに同じであ る。サーバの現在時刻より後の日付は不正である。 b) もしバリアントが If-Modified-Since 日付から更新されているなら、レスポンスは 通常の GET と明らかに同じである。 c) もしバリアントが正当な If-Modified-Since 日付から更新されていなければ、サー バは 304 (Not Modified) レスポンスを返さなければならない。 この機構の目的は最小のトランザクションオーバーヘッドでキャッシュされた情報の効果 的な更新を行えるようにすることである。 Range リクエストヘッダフィールドは If-Modified-Since の意味を訂正する事に注意 。全詳細は 14.36 章参照。 If-Modified-Since 時刻はサーバによって解釈され、そのクロックはクライアントとは 同期していないかもしれないと言う事に注意。 もしクライアントが同じリクエストに対して Last-Modified ヘッダから取り出される日 付の代わりに If-Modified-Since ヘッダの日付を独断的に使用するなら、この日付はサ ーバの理解できる時間で解釈されると言う事実を知るべきである事に注意。クライアント はクライアントとサーバの間の時間の異なる識別のため、クロックの非同期やその周りの 問題を考慮すべきである。これは、ドキュメントが最初のリクエストや続くリクエストの If-Modified-Since 日付の時間内に変更しているかどうかと言う時間経過条件の可能性と 、If-Modified-Since 日付がサーバのクロックに補正していないクライアントのクロック に由来するかどうかと言うクロックが相対的に異なる可能性を含んでいる。クライアント とサーバの間の時間基準の違いの補正はネットワーク潜在のため最良の近似である。 14.25 If-Match If-Match リクエストヘッダフィールドはメソッドを条件付きにさせるように使用される 。リソースから前もって得られた一つ以上のエンティティを持つクライアントは、If-Mat ch ヘッダフィールドにおいてそれらに関連したエンティティタグのリストを含める事に より、それらのエンティティの一つが最新である事を確かめる。この機構の目的は最小の トランザクションオーバーヘッドでキャッシュされた情報の効果的な更新を行なえるよう にする事である。更新リクエストに加えて、リソースを不適切なバージョンに不注意に修 正できないようにも使用される。特殊な場合として、値 "*" はリソースの現在のあらゆ るエンティティと一致する。 If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) もしリソースでの GET に類似したリクエストへのレスポンス (If-Modifiedヘッダを伴わ ない) において返されたエンティティタグのどれとも一致しなかったり、"*" が与えられ 最新のあらゆるエンティティがそのリソースに対して存在するなら、サーバは If-Match ヘッダフィールドが存在しないものとしてリクエストされたメソッドを実行できる。 サーバは If-Match のエンティティタグを比較するための強固な比較機能 (3.11 章参照) を使用しなければならない。 もしエンティティタグのどれとも一致しなかったり、"*" が与えられて最新のエンティテ ィが存在していなければ、サーバはリクエストされたメソッドを実行してはならず、412 (Precondition Failed) レスポンスを返さなければならない。この動作は PUT のように リソースを更新するメソッドが、クライアントが最後にそれを回収してから変更したリソ ースを置き換えさせない事をクライアントが望むときにもっとも有用である。 もし If-Match ヘッダフィールドを伴わないリクエストが 2xx ステータス以外の何かを 結果として生じるなら、If-Match ヘッダは無視されなければならない。 "If-Match: *" の意味は、メソッドがオリジンサーバによって (ひょっとすると Vary メ カニズムを使っているキャッシュによる、14.43 章参照) 選択された表現が存在するなら 実行されるべきであり、表現が存在しなければ実行されてはならない。 リソースを更新する目的のリクエスト (例えば PUT) は、リクエストメソッドが If-Matc h 値に相当するエンティティがもはやそのリソースの表現でないなら適用されてはならな い事を合図するため、If-Match ヘッダフィールドを含める事ができる。これはユーザが 、リソースが彼らの知らないうちに既に変更されているならリクエストを成功させたくな いことを示せるようにする。例えば: If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: * 14.26 If-None-Match If-None-Match リクエストヘッダフィールドは条件が付けられるメソッドを使用させる。 リソースから前もって得られた一つ以上のエンティティを持っているクライアントが、If -None-Match ヘッダフィールドでそれらに関連するエンティティタグのリストを追加する 事により、それらのエンティティのどれもが最新でない事を確かめられる。この機構の目 的は最小のトランザクションオーバーヘッドでキャッシュされた情報の効果的な更新を行 えるようにする事である。更新リクエストにおいて、存在が知られていないリソースの不 注意な修正を阻止するためにも使用される。 特別な場合として、値 "*" はリソースのすべてのエンティティと一致する。 If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) もしエンティティタグどれもリソースでの GET に類似したリクエストのレスポンス (If- None-Match ヘッダを伴わない) において返されたエンティティタグエンティティタグと 一致したり、"*" が与えられどんな最新のエンティティももそのリソースに対して存在す るなら、サーバはリクエストされたメソッドを実行してはならない。代わりに、もしリク エストメソッドが GET もしくは HEAD なら、サーバは一致したエンティティの一つの ca che-related エンティティヘッダフィールド (特に ETag) を含んでいる 304 (Not Modif ied)レスポンスで応じるべきである。別のすべてのリクエストメソッドに対しては、サー バは 412 (Precondition Failed) のステータスで応じなければならない。 二つのエンティティタグが一致するかどうかをどのように決定するかのルールは 13.3.3 章参照。弱い比較機能は GET や HEAD リクエストにのみ使用できる。 もしエンティティタグのどれとも一致しなかったり、"*" が与えられ最新のエンティティ が存在しないのなら、サーバは If-None-Match ヘッダフィールドが存在しなかったよう にリクエストされたメソッドを実行できる。 もし If-None-Match ヘッダフィールドを伴わないリクエストが 2xx ステータス以外の何 かを結果として生じるなら、If-None-Match ヘッダは無視されなければならない。 "If-None-Match: *" の意味は、メソッドがオリジンサーバによって (ひょっとしたら Va ry メカニズムを使用しているキャッシュによって) 選択された表現が存在するなら実行 されてはならず、そして表現が存在しないのなら実行されるべきである。この機構は PUT 操作との競合を阻止することにおいて有用である。 例: If-None-Match: "xyzzy" If-None-Match: W/"xyzzy" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: * 14.27 If-Range もしクライアントがそのキャッシュにエンティティの部分的なコピーを持ち、そのキャッ シュにエンティティ全体の最新のコピーを持つ事を望んでいるなら、(If-Unmodified-Sin ce と If-Match のどちらかもしくは両方を使用して) 条件付き GET に伴う Range リク エストヘッダを使う事ができる。しかしながら、エンティティが既に修正されているため 条件が失敗するなら、クライアントは最新のエンティティボディ全体を取得するため二番 目のリクエストを作らなければならないだろう。 If-Range ヘッダはクライアントが二番目のリクエストへ "short-circuit" を可能にする 。口語体では、この意味は `もしエンティティが変更されていないなら、私が持っていな い部分を送ってくれ; もしそうでなければ新しいエンティティ全たくを送ってくれ' とな る。 If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) もしクライアントがエンティティに対するエンティティタグを持たず、Last-Modified 日 付を持っているなら、If-Range ヘッダにその日付を使用できる(サーバは正当な HTTP-da te を区別でき、エンティティタグのすべての形式を多くても 2 文字検査する事によって 区別できる)。If-Range ヘッダは Rangeヘッダとともにのみ使用されるべきであり、リク エストが Range ヘッダを含んでいなかったりサーバがサブレンジ操作をサポートしてい なければ無視されなければならない。 もし If-Range ヘッダにおいて与えられるエンティティタグがエンティティに対する最新 のエンティティタグと一致するなら、サーバは 206 (PartialContent) レスポンスを使用 してエンティティタグの記述されたサブレンジを供給すべきである。もしエンティティタ グが一致しなければ、サーバは 200(OK) レスポンスを使用してエンティティ全体を返す べきである。 14.28 If-Unmodified-Since If-Unmodified-Since リクエストヘッダフィールドはメソッドを条件付きにするために使 用される。もしリクエストされたリソースがこのフィールドに記述された時間から更新さ れていなければ、サーバは If-Unmodified-Since ヘッダが与えられていないようなリク エストされた操作を実行するべきである。 もしリクエストされたバリアントが記述された時間から更新されているなら、サーバはリ クエストされた操作を実行してはならず、412 (PreconditionFailed) を返さなければな らない。 If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date フィールドの例は以下のようになる: If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT もしリクエストが標準的に (例えば If-Unmodified-Since ヘッダが伴わないような) 2xx ステータス以外の何かを結果としてもたらす場合、If-Unmodified-Since ヘッダは無視さ れるべきである。 もし記述された日付が不正なら、ヘッダは無視される。 14.29 Last-Modified Last-Modified エンティティヘッダフィールドはオリジンサーバがバリアントの最終更新 時間だと思っている日付と時間を示す。 Last-Modified = "Last-Modified" ":" HTTP-date この使用例は以下のようになる。 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT このヘッダフィールドの正確な意味はオリジンサーバのインプリメンテーションと元のリ ソースの性質に依存する。ファイルではこれはちょうどファイルシステムの最終更新時間 である。動的に追加されたエンティティではその構成部分に対する最終更新時間のセット のもっとも最近のものである。データベースゲートウェイではそのレコードの最終更新タ イムスタンプである。仮想オブジェクトでは内部的な状態が変更された最後の時間である 。 オリジンサーバはメッセージ発生のサーバの時間よりも遅れた Last-Modified日付を送っ てはならない。この場合、リソースの最終変更は未来におけるある時間を示し、サーバは その日付をメッセージ発生の日付と取り替えなければならない。 オリジンサーバはそのレスポンスの Date 値を生成する時刻に可能な限り近いエンティテ ィの Last-Modified 値を得るべきである。これは特にエンティティがレスポンスの生成 された時間の近くで変更されたなら、受け取り側にエンティティの変更時間の正確な査定 を行えるようにする。 HTTP/1.1 サーバは実行可能であれば Last-Modified を送るべきである。 14.30 Location Location レスポンスヘッダフィールドはリクエストの完了や新しいリソースの確認のた め受け取り側に Request-URI 以外のロケーションへリダイレクトするために使用される 。201 (Created) レスポンスに対して、Location はリクエストによって生成された新し いリソースのものである。3xx レスポンスでは、ロケーションはリソースに自動リダイレ クトするためサーバが提案したURL を示すべきである。フィールド値は単一の絶対 URL からなる。 Location = "Location" ":" absoluteURI この例は以下のようになる。 Location: http://www.w3.org/pub/WWW/People.html 注意: Content-Location ヘッダフィールド (14.15 章) は、Content-Locationがリクエ ストに同封されたエンティティのロケーションを示すと言う点で Location とは異なる。 それゆえレスポンスは Location と Content-Location の両方ののヘッダフィールドを含 む事ができる。いくつかのメソッ ドのキャッシュ要求に対する 13.10 章も参照。 14.31 Max-Forwards Max-Forwards リクエストヘッダフィールドは、帰りの次のサーバにリクエストを転送で きるプロキシやゲートウェイの数を制限するため TRACE メソッド(14.31 章) で使用され る。これはクライアントが中間連鎖において支障やループがあると思われるリクエスト連 鎖のトレースを試行するときに有用である。 Max-Forwards = "Max-Forwards" ":" 1*DIGIT Max-Forwards 値はこのリクエストメッセージが転送可能な残りの回数を示す10 進整数で ある。 Max-Forwards ヘッダフィールドを含んでいる TRACE リクエストを受け取るプロキシやゲ ートウェイそれぞれは、リクエストを転送する前にこの値をチェックして更新すべきであ る。もしゼロ (0) の値を受け取ったら、受取人はリクエストを転送すべきではなく、代 わりにレスポンスエンティティボディとして (9.8 章で記述されているように) 受け取っ たリクエストのメッセージを含んでいる 200 (OK) レスポンスを伴って、最後の受取人と して応じるべきである。もし受け取った Max-Forwards 値がゼロよりも大きいなら、転送 されるメッセージは 1 つ減少した値を伴う更新された Max-Forwards フィールドを含む べきである。 Max-Forwards ヘッダフィールドはこの仕様書によって定義されている別のすべてのメソ ッド、そしてこのメソッド定義の一部として明白に参照されていないすべての拡張メソッ ドに対して無視されるべきである。 14.32 Pragma Pragma 一般ヘッダフィールドはリクエスト/レスポンス連鎖上のすべての受取人に適用で きるインプリメンテーション記述命令を追加するために使用される。すべての pragma 命 令はプロトコルの観点からオプション的な動作を詳述する。しかしながら、いくつかのシ ステムはこの命令と一致する動作を要求する事ができる。 Pragma = "Pragma" ":" 1#pragma-directive pragma-directive = "no-cache" | extension-pragma extension-pragma = token [ "=" ( token | quoted-string ) ] no-cache ディレクティブがレスポンスメッセージにおいて与えられるとき、アプリケー ションはたとえ要求されているもののキャッシュされたコピーを持っていても、リクエス トをオリジンサーバに転送すべきである。この pragma命令は no-cache キャッシュ命令 (14.9 章) と同じセマンティクスを持ち、HTTP/1.0 との下位互換性のためここで定義さ れる。クライアントは no-cacheリクエストが HTTP/1.1 に準じているか分からないサー バに送られるとき両方のヘッダフィールドを加えなければならない。 pragma 命令がリクエスト/レスポンス連鎖上のすべての受取人に受け入れられるため、そ のプロキシやゲートウェイアプリケーションの重要性に関わらず、Pragma 命令はそれら のアプリケーションを通過しなければならない。具体的な受取人に対する pragma を詳述 する事は不可能である。しかしながら、受取人に関係しないどんな pragma 命令もその受 取人によって無視されるべきである。 HTTP/1.1 クライアントは Pragma リクエストヘッダを送信すべきではない。HTTP/1.1 キ ャッシュは "Pragma: no-cache" をクライアントが"Cache-Control: no-cache" を送った ように扱うべきである。新しい Pragma命令は HTTP において定義されないだろう。 14.33 Proxy-Authenticate Proxy-Authenticate レスポンスヘッダフィールドは 407 (Proxy AuthenticationRequire d) レスポンスの一部として追加されなければならない。フィールド値はこの Request-UR I に対してプロキシに適用できる認証スキームやパラメータを示す誰何からなる。 Proxy-Authenticate = "Proxy-Authenticate" ":" challenge HTTP アクセス認証プロセスは 11 章で記述される。WWW-Authenticate と違い、Proxy-Au thenticate ヘッダフィールドは現在の接続にのみ適用され、それより手前のクライアン トに渡されるべきではない。しかしながら、中間プロキシがそれより手前のクライアント からの信用証明を要求する事で、それ自身の信用証明を得る必要があるかもしれない。こ のような事情はプロキシがProxy-Authenticate ヘッダフィールドをフォローしている様 に現れるだろう。 14.34 Proxy-Authorization Proxy-Authorization リクエストヘッダフィールドはクライアントが認証を必要とするプ ロキシでそれ自身 (もしくはそのユーザ) を識別できるように使用される。Proxy-Author ization フィールド値は、プロキシに対するユーザエージェントの認証情報と/もしくは リクエストされたリソースの realm を含む信用証明からなる。 Proxy-Authorization = "Proxy-Authorization" ":" credentials HTTP アクセス認証プロセスは 11 章で記述されている。Authrization と違い、Proxy-Au thorization ヘッダフィールドは、Proxy-Authorization フィールドを使用して認証を要 求した [訳注: クライアントから見て] 次の外向きのプロキシにのみあてはめられる。連 鎖において複数のプロキシが使用されているとき、Proxy-Authorization ヘッダフィール ドは信用証明を受け取る事を期待している最初の外向きのプロキシによって消滅する。も しそれが与えられたリクエストをプロキシどうしが協力して認証すると言う事によるメカ ニズムであるなら、プロキシはクライアントリクエストから次のプロキシに信用証明を中 継できる。 14.35 Public Public レスポンスヘッダフィールドはサーバによって提供されるメソッドのセットのリ ストである。このフィールドの目的は厳密に言えば受け取り側に通常でないメソッドに関 してサーバの能力を知らせるためである。メソッドはリストされるメソッドは Request-U RI に適用できてもできなくても良い。Allow ヘッダフィールド (14.7 章) は固有の URI に対してみとめられるメソッドを示すために使用できる。 Public = "Public" ":" 1#method 使用例は以下のようになる。 Public: OPTIONS, MGET, MHEAD, GET, HEAD このヘッダフィールドはクライアントに直接接続しているサーバにのみ適用できる (例え ば接続の連鎖における最も近い隣側)。もしレスポンスがプロキシを通過するなら、プロ キシは Public ヘッダフィールドを削除するかそれ自身の能力で受け入れられるものに置 き換えるかどちらかを行わなければならない。 14.36 Range 14.36.1 Byte Ranges すべての HTTP エンティティがバイトのシーケンスとしての HTTP メッセージで表される ため、バイトレンジの概念はすべての HTTP エンティティに対して意味がある (しかしな がら、すべてのクライアントとサーバがバイトレンジ操作をサポートする必要はない)。 HTTP におけるバイトレンジ仕様はエンティティボディ (メッセージボディと同じである 必要はない) におけるバイトのシーケンスに適用される。 バイトレンジ操作は単一のエンティティにおけるバイトの単一の範囲もしくは範囲のセッ トを詳述できる。 ranges-specifier = byte-ranges-specifier byte-ranges-specifier = bytes-unit "=" byte-range-set byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) byte-range-spec = first-byte-pos "-" [last-byte-pos] first-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT byte-range-spec の first-byte-pos 値は範囲の最初のバイトのオフセットを与える。la st-byte-pos 値は範囲の最後のバイトのオフセットを与える。これは、記述されたバイト 位置が含まれている。バイトオフセットはゼロから開始する。 もし last-byte-pos 値が与えられるなら、byte-range-spec における first-byte-pos 以上でなければならず、そうでなければ byte-range-spec は不正である。不正な byte-r ange-spec を受け取った側はそれを無視しなければならない。 もし last-byte-pos 値がなかったりエンティティボディの現在の長さ以上なら、last-by te-pos はバイトにおいて多くともエンティティボディの現在の長さのそれと等しくなる 。 last-byte-pos のその選択により、クライアントはエンティティのサイズを知らなくても 回収されるバイトの数値を限定できる。 suffix-byte-range-spec = "-" suffix-length suffix-length = 1*DIGIT suffix-byte-range-spec は suffix-length 値によって与えられる長さの、エンティティ ボディのサフィックスを記述するために使用される (これは、この形式がエンティティボ ディの最後の N バイトを示す)。もしエンティティが記述された suffix-length より小 さい場合、エンティティボディ全体が使用される。 byte-range-specifier 値の例 () は以下のようになる (長さ 10000 のエンティティボデ ィを仮定): * 最初の 500 バイト (バイトオフセット 0-499 を含む): bytes=0-499 * 次の 500 バイト (バイトオフセット 500-999 を含む): bytes=500-999 * 最後の 500 バイト (バイトオフセット 9500-9999 を含む): bytes=-500 * もしくは bytes=9500- * 最初と最後のバイトのみ (0 と 9999 のバイト): bytes=0-0,-1 * 次の 500 バイトの公式な仕様ではないがいくつかの合法的方法 (バイトオフセット 500-999 を含む): bytes=500-600,601-999 bytes=500-700,601-999 14.36.2 Range Retrieval Requests 条件付きもしくは条件なし GET メソッドを使用した HTTP 回収リクエストは、Range リ クエストヘッダを使用してエンティティ全体の代わりにエンティティの一つ以上のサブレ ンジを要求できる。これはリクエストの結果として返されるエンティティに適用する。 Range = "Range" ":" ranges-specifier サーバは Range ヘッダを無視できる。しかしながら、Range が部分的に失敗した転送の 回復と大きいエンティティの部分的な回収を効果的に支援するため、HTTP/1.1 オリジン サーバと中間キャッシュは可能であればバイトレンジをサポートすべきである。 もしサーバが Range ヘッダをサポートし、記述されたレンジがエンティティに対して適 切であれば: * 条件なし GET における Range ヘッダの存在は GET が別の方法で成功したなら、 返される物を変更する。言いかえれば、レスポンスは 200 (OK) の代わりに 206 (Part ial Content) のステータスコードを伝える。 * 条件付き GET (If-Modified-Since, If-None-Match の一つもしくは両方または I f-Unmodified-Since と If-Match の一つもしくは両方を使用したリクエスト) におけ る Range の存在は、GET が別の方法で成功し条件が真ならば、返されるものを変更す る。もし条件が偽ならば返されるレスポンスは 304 (Not Modified) を装う。 いくつかの場合、If-Range ヘッダ (14.27 章) を使うよりも Range ヘッダを追加したほ うがより適切である。 もしレンジをサポートするプロキシが Range リクエストを受信したら向かうサーバにそ れを転送し、応答においてエンティティ全体を受信したら、そのクライアントが要求した 範囲のみを返すべきである。もしそのキャッシュ割り当て方針と一致するなら受信したレ スポンスのエンティティをそのキャッシュに保存すべきである。 14.37 Referer Referer[sic] リクエストヘッダフィールドはクライアントがサーバの利益 Request-URI が得られたリソースのアドレス (URI) を記述できるようにする ("referrer", ヘッダフ ィールドの綴りは間違っている)。Referer リクエストヘッダフィールドはサーバに興味 、ログ、キャッシュの最適化などのためのリソースへの逆リンクのリストを生成できるよ うにする。現在使用されていないリンクやミス入力されたリンクをメンテナンスのためト レースできるようにもする。もし Request-URI が自身の URI を持たないリソースから得 られたなら、Referer フィールドは送られてはならない。これはユーザキーボードから入 力されたような場合である。 Referer = "Referer" ":" ( absoluteURI | relativeURI ) 例: Referer: http://www.w3.org/hypertext/DataSources/Overview.html もしフィールド値が部分的な URI なら、Request-URI に対する相対的なものと解釈され るべきである。この URI はフラグメントを含んではならない。 注意: リンクのソースがプライベート情報であったり別のプライベート情報ソースを示す かもしれないため、ユーザが Referer フィールドが送られるかどうかを選択できる事を 強く勧める。例えば、ブラウザクライアントは公然/匿名の閲覧のためのトルグスイッチ を持つ事ができ、これはそれぞれ Referer と From 方法の送信を有効/向こうにするだろ う。 14.38 Retry-After Retry-After レスポンスヘッダフィールドは、どれくらいの間サービスが利用できないか をリクエストしているクライアントに示すため、503 (ServiceUnavailable) レスポンス を伴って使用される。このフィールドの値は HTTP-date かレスポンスの時間後の整数秒 数 (10 進数) のどちらかである。 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) この使用の二つの例は以下のようになる。 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120 後者は 2 分間の遅延である。 14.39 Server Server レスポンスヘッダフィールドはオリジンサーバでリクエストを扱うために使用さ れているソフトウェアに関する情報を含んでいる。フィールドは複数の製品トークン (3. 8 章) とサーバとすべての重要なサブプロダクトを識別するコメントを含む事ができる。 製品トークンはアプリケーションを識別するためにそれらの重要性の順でリストされる。 Server = "Server" ":" 1*( product | comment ) 例: Server: CERN/3.0 libwww/2.17 もしレスポンスがプロキシを通して転送されているなら、プロキシアプリケーションは S erver レスポンスヘッダを置き換えてはならない。代わりに、Via フィールド (14.44 章 で記述される) を含むべきである。 注意: サーバの具体的なソフトウェアバージョンを示す事は、サーバマシンをあるセキュ リティホールが知られているソフトウェアに対するより無防備なアタックを許す。サーバ 実装者はこのフィールドを設定可能なオプションにする事が奨励される。 14.40 Transfer-Encoding Transfer-Encoding 一般ヘッダフィールドは、送り側から受け取り側へメッセージボディ を安全に転送するために、それに適用されている変換のタイプがなんであるかを示す。こ れは転送コーディングがメッセージの特質であり、エンティティの特質ではないと言う点 で Content-Encoding とは異なる。 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 転送コーディングは 3.6 章で定義されている。一つの例は以下のようになる。 Transfer-Encoding: chunked ほとんどの HTTP/1.0 アプリケーションは Transfer-Encoding ヘッダを理解していない 。 14.41 Upgrade Upgrade 一般ヘッダは、クライアントがどんな追加的な通信プロトコルをサポートしてる かと、サーバがプロトコルをスイッチするための適切なものを見つけたなら、何を優先し て使うかを記述できるようにする。サーバは 101 (SwitchingProtocols) レスポンスにお いてプロトコルがスイッチしている事を示すためUpgrade ヘッダフィールドを使用しなけ ればならない。 Upgrade = "Upgrade" ":" 1#product たとえば以下のようになる。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade ヘッダフィールドは HTTP/1.1 からある別の互換性のないプロトコルに移行する ための簡単なメカニズムを供給するのを目的とする。たとえ現在のリクエストが HTTP/1. 1 を使って作られたとしても、クライアントがより高いメジャーバージョン番号を伴う H TTP の最新バージョンのような、別のプロトコルを使つかうのを要求する事を表せる事に よりそれを行う。これは、もし利用可能なら "より良い" プロトコルを優先して使うサー バを示すとき、クライアントがより一般的にサポートしているプロトコルでリクエストを 開始できるようにする事により、非互換プロトコル間の難しい移行を取り除く (ここで" より良い" はサーバによって決定され、ひょっとするとリクエストされたメソッドと/も しくはリソースの特質にしたがっている)。 Upgrade ヘッダフィールドは存在する転送層接続上のアプリケーション層プロトコルをス イッチするためにのみ適用される。Upgrade はプロトコルのを主張するために使用できな い。サーバによるその受諾と使用はオプションである。プロトコル変換後のアプリケーシ ョン層通信の能力と本質は選択されたプロトコルに完全に依存する。とはいえプロトコル 変更後の最初の動作は Upgradeヘッダフィールドを含む初めの HTTP リクエストへのレス ポンスでなければならない。 Upgrade ヘッダフィールドは直接接続においてのみ適用する。したがって、upgrade キー ワードは Upgrade が HTTP/1.1 メッセージで与えられるとき、Connection ヘッダフィー ルド (14.10 章) において供給されなければならない。 Upgrade ヘッダフィールドは異なる接続へのプロトコルのスイッチを示すために使用され る。この理由により、 301, 302, 303, 305 リダイレクションレスポンスを使用する事が より適切である。 この仕様書では 3.1 章の HTTP バージョンルールと、この仕様書の将来的な更新によっ て定義されるような、Hypertext Transfer Protocol のファミリによって使用されうプロ トコル名 "HTTP" のみを定義する。しかしながら、これはクライアントとサーバの両方が 名前を同じプロトコルに関結び付けている時のみ有用であろう。 14.42 User-Agent User-Agent リクエストヘッダフィールドはリクエストを開始したユーザエージェントに 関する情報を含んでいる。これは統計上の目的、プロトコル違反のトレース、そして特有 のユーザエージェントの制限を回避するために合わせたレスポンスのためのユーザエージ ェントの自動認識のために存在する。ユーザエージェントはリクエストにこのフィールド を加えるべきである。このフィールドはそのエージェントとユーザエージェントの重要な 一部を形成するすべてのサブプロダクトを識別するための複数の製品トークン (3.8 章) とコメントを含める事ができる。慣例により、製品トークンはそのアプリケーションを識 別するためのそれらの重要性の順にリストされる。 User-Agent = "User-Agent" ":" 1*( product | comment ) 例: User-Agent: CERN-LineMode/2.15 libwww/2.17b3 14.43 Vary Vary レスポンスヘッダフィールドは、レスポンスエンティティがserver-driven ネゴシ エーション (12 章) を使用してレスポンスの利用可能な表現から選択されたと言う合図 を送るためサーバによって使用される。Varyヘッダでリストされるフィールド名はそれら のレスポンスヘッダである。Variフィールド値は、ヘッダフィールドの与えられたセット が、表現が変化する上での次元を包囲する事、もしくは変化の次元が指定されなく ("*") 従って将来的なリクエストのどんな局面でも変化しうると言う事のどちらかを示す。 Vary = "Vary" ":" ( "*" | 1#field-name ) HTTP/1.1 サーバは server-driven ネゴシエーションに従っているあらゆるキャッシュ可 能なレスポンスに付随する適切な Vary ヘッダフィールドを加えなければならない。そう する事は、これがユーザエージェントにレスポンスが変化する上での次元に関する有用な 情報を提供するであろうため、キャッシュがそのリソース上の将来のリクエストを適切に 解釈し、ユーザエージェントにそのリソース上のネゴシエーションの存在に関して知らせ る事ができる。 Vary フィールド値によって名前が付けられたヘッダフィールドのセットは、"selecting" リクエストヘッダとして知られる。 Request-URI が Vary ヘッダを含んでいる一つ以上のキャッシュエントリを記述している ような、続くリクエストをキャッシュが受け取ったとき、もしキャッシュされた Vary ヘ ッダにおいて名前が付けられているヘッダのすべてが新しいリクエストに存在しなく、前 のリクエストからの保存された selectingリクエストヘッダのすべてが新しいリクエスト における相当するヘッダに一致しないなら、キャッシュは新しいリクエストへのレスポン スを構築するためのそのようなキャッシュエンティティを使用してはならない。 もし最初のリクエストにおける selecting リクエストヘッダが、BNF に相当するものに よってみとめられる場所に連続した空白 (LWS) を追加したり削除したり、さらに/もしく は 4.2 章のメッセージヘッダに関するルールをフォローする、同じフィールド名が伴う 複数のメッセージヘッダフィールドを組み合わせる事で、二番目のリクエストにおける s electing リクエストヘッダに変換できるなら、そしてその場合にのみ、二つのリクエス トからの selecting リクエストヘッダは一致すると定義される。 "*" の Vary フィールド値は、記述できないパラメータ ひょっとするとリクエストヘッ ダフィールドの内容以外のもの (例: クライアントのネットワークアドレス) がレスポン ス表現の選択において役割を果たすことを合図する。このリソース上の続くリクエストは オリジンサーバによってのみ適切に解釈され、従ってキャッシュはリソースに対してキャ ッシュされている新鮮なレスポンスを持っているとき、リクエストを転送 (条件付きかも しれない) しなければならない。キャッシュによる Vary ヘッダの使用は 13.6 章参照。 Vary フィールド値は、レスポンスに対して選択された表現がもっとも適切な表現の選択 でリストされたリクエストヘッダフィールド値のみを検討する、選択アルゴリズムに基づ いている事を合図する。レスポンスが新鮮である時間の持続期間の間、同じ選択がリスト されたフィールド名に対する同じ値を伴って将来的なリクエストのために作られるだろう という事をキャッシュは仮定できる。 与えられたフィールド名はこの仕様書で定義されている標準リクエストヘッダフィールド のセットに限定されない。フィールド名は大文字小文字を区別しない。 14.44 Via Via 一般ヘッダフィールドはゲートウェイとプロキシにより、リクエストにおけるユーザ エージェントとサーバの間、そしてレスポンスにおけるオリジンサーバとクライアントの 間の中間プロトコルと受け取り側を示すために使用される。これは RFC 822 の "Recieve d" フィールドと類似し、メッセージの転送を追跡し、リクエストループを避け、リクエ スト/レスポンス連鎖上のすべての送り主のプロトコル能力を確認するために使用される 。 Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) received-protocol = [ protocol-name "/" ] protocol-version protocol-name = token protocol-version = token received-by = ( host [ ":" port ] ) | pseudonym pseudonym = token received-protocol はリクエスト/レスポンス連鎖のそれぞれのセグメント上のサーバや クライアントによって受け取られたメッセージのプロトコルバージョンを示す。received -protocol バージョンはメッセージが転送されるとき、すべての受取人に見える上流のア プリケーションのプロトコル能力に関する情報のように Via フィールド値に付け加えら れる。 もしそれが "HTTP" であれば、そしてその場合にのみ、protocol-name はオプションであ る。received-by フィールドは通常、後にメッセージを転送した受取人のサーバやクライ アントのホストとオプション的なポート番号である。しかしながら、もし実際のホストが 取り扱いに慎重を要する情報だとみなせば、これは received-protocol のデフォルトポ ートとみなす事ができる。 複数の Via フィールド値はメッセージを転送したそれぞれのプロキシやゲートウェイに 相当する。それぞれの受取人は、末端の結果が転送しているアプリケーションの並びに応 じてならべられるようにその情報を追加しなければならない。 コメントは User-Agent や Server ヘッダフィールドに類似し、受取人のプロキシやゲー トウェイのソフトウェアを識別するための Via ヘッダフィールドにおいて使用する事が できる。しかしながら、Via ヘッダフィールドにおけるすべてのコメントはオプションで あり、メッセージを転送した先のあらゆる受取人によって削除される かもしれない。 たとえば、リクエストメッセージは HTTP/1.0 ユーザエージェントから内部的な "fred" というコートネームのプロキシに送られ、それは HTTP/1.1 を使用して nowhere.com の 公開プロキシにリクエストを転送し、それはオリジンサーバ www.ics.uci.edu にリクエ ストを転送するで完了する。www.ics.uci.eduにより受け取られたリクエストは以下のよ うな Via ヘッダフィールドを持つだろう: Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) ネットワークファイアウォールを通る門となるプロキシとゲートウェイはデフォルトによ り、ファイアウォール領域内のホストの名前とポートを転送すべきではない。この情報は 明白に許可された場合にのみ広められるべきである。もし許可されていなければ、ファイ アウォールの背後のどんなホストの recieved-by ホストもそのホストに対する適切な偽 名によっておきかえられるべきである。 内部構造の隠蔽に非常に強いプライバシーを必要とする組織のため、プロキシは Via ヘ ッダフィールドのエントリの順序あるサブシーケンスをそのような単一のエントリと全く 同一の received-protocol 値を結合する事ができる。たとえば、以下のようになる Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy は以下のように折り畳める Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 複数のエンティティがすべて同じ組織の管理下になく、ホストがまだ偽名に置き換えられ ていないなら、アプリケーションは複数のエントリを結合すべきではない。アプリケーシ ョンは異なる received-protocol 値を持つエントリを結合しなければならない。 14.45 Warning Warning レスポンスヘッダフィールドは、レスポンスステータスコードによって反映され ていないレスポンスの状態に関する追加的な情報を伝えるために使用される。この情報は 典型的には 排他的ではないが キャッシング操作からセマンティクス透過性の欠如の可能 性に関する警告に使用される。 Warnign ヘッダは以下を使用してレスポンスに付随して送られる。 Warning = "Warning" ":" 1#warning-value warning-value = warn-code SP warn-agent SP warn-text warn-code = 2DIGIT warn-agent = ( host [ ":" port ] ) | pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string レスポンスは一つ以上の Warning ヘッダを伝える事ができる。 warn-text は自然言語であり、レスポンスを受け取った人間のユーザにもっとも理解でき そうな文字セットである。この結論はキャッシュやユーザのロケーション、リクエストに おける Accept-Language フィールド、レスポンスにおける Content-Length フィールド などのような、すべての利用で切る情報に基づいている。デフォルトは文字セット ISO-8 859-1 を使用した英語である。 もし ISO-8859-1 以外の文字セットが使用されるなら、RFC 1522 [14] で記述されている 方法を使用して warn-text をエンコードしなければならない。 どのようなサーバやキャッシュもレスポンスに Warning ヘッダを追加する事ができる。 新しい Warning ヘッダは存在する Warning ヘッダの後に追加されるべきである。キャッ シュはレスポンスとして受信したどんな Warning ヘッダも削除してはならない。しかし ながら、もしキャッシュがうまくキャッシュエントリの正当性を確認したなら、具体的な Warning コードとして記述してあるようなもの以外のそのエントリに前もって付随したす べての Warningヘッダを削除すべきである。このとき、レスポンスの正当性確認において 受信したすべての Warning ヘッダを追加しなければならない。言いかえれば、Warning ヘッダはもっとも最近の適切なレスポンスに付随しているものである。 複数の Warinig ヘッダがレスポンスに追加されるとき、ユーザエージェントはレスポン ス内でそれらが現れる順に可能な限り多くを表示すべきである。もし警告のすべてを表示 できなければ、ユーザエージェント発見的方法に習うべきである。 * レスポンスにおいて先に現れる Warning は、レスポンスにおいて後に現れる物よ り高い優先度を持つ。 * ユーザの優先している文字セットの Warning は、同じ warn-code と同じ warn-age nt が伴う別の文字セットの警告よりも高い優先度を持つ。 複数の Warning ヘッダを生成するシステムは、このユーザエージェント動作の意図どう りにそれらを整理するべきである。 これは現在定義されている、それぞれ英語で推奨される warn-text を伴うwarn-code と その意味の説明である。 10 Response is stale 返されたレスポンスが古くなっているときはいつでも含まなければならない。キャッ シュはすべてのレスポンスにこの警告を追加できるが、レスポンスが新鮮であるとわかる までこれを削除してはならない。 11 Revalidation failed サーバに到達できなかったため、レスポンスの正当性再評価が失敗したと仮定される ためキャッシュが古いレスポンスを返した場合に追加されなければならない。キャッシュ はどんなレスポンスにもこの警告を追加できるが、レスポンスが正当性の再評価に成功す るまで削除されてはならない。 12 Disconnected operation ネットワークの残りからキャッシュの意図した切断により追加されるべきである。 SH OULD be included if the cache is intentionally disconnected from the rest of the network for a period of time. 13 Heuristic expiration キャッシュが発見的に 24 時間以上の新鮮さ持続時間を選択し、レスポンスの年齢が 24 時間より大きい場合に追加されなければならない。 14 Transformation applied もしレスポンスにまだこの Warning コードが存在しなければ、レスポンスの内容コー ディング (Content-Encoding ヘッダで示されるような) やメディアタイプ (Content-Typ e ヘッダで示されるような) を変更する変換がどんな物でも適用された場合、中間キャッ シュやプロキシによって追加されなければならない。正当性再評価の後レスポンスから削 除されてはならない。 99 Miscellaneous warning 警告テキストは人間のユーザに示したりログに取ったりするための任意の情報を追加 できる。この警告を受け取っているシステムはどんな自動動作も行ってはならない。 14.46 WWW-Authenticate WWW-Authenticate レスポンスヘッダフィールドは 401 (Unauthorized) レスポンスメッ セージに含まれなければならない。このフィールド値はRequest-URI に適用できる認証ス キームとパラメータを示す一つ以上の誰何からなる。 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge HTTP アクセス認証プロセスは 11 章で記述される。誰何の内容はコンマで区切られた認 証パラメータのリストのを自身に含んでいるかもしれないため、一つ以上の誰何を含んで いるかどうか、一つ以上の WWW-Authenticate ヘッダフィールドが供給されているかにつ いて、ユーザエージェントは WWW-Authenticate フィールド値を特に注意深く解析しなけ ればならない。 15 セキュリティ考察 この章はアプリケーション開発者、情報提供者、そしてユーザにこのドキュメントで記述 されているような HTTP/1.1 のセキュリティ限界を知らせるつもりである。ディスカッシ ョンは示された問題の決定的な解決を含んでいないが、セキュリティリスクを減らすため の幾つかの提案を行っている。 15.1 クライアントの認証 Basic 認証スキームはユーザ認証の安全な方法ではなく、エンティティを保護するどんな 方法においてもそれを行わない。これは伝達媒体として使用される物理的なネットワーク を横切ってクリアテキスト転送される。HTTP はセキュリティ工場のために使用される追 加的な認証スキームや暗号化メカニズムの、もしくは Basic 認証の強化 (one-time パス ワードを使用するためのスキームなど) の追加を妨げない。[訳注: クリアテキスト 転送 中継ホストで見られる可能性のあるテキスト。Basic 認証で使用される Base64 は簡単に 暗号化を解く事ができる。] Basic 認証におけるもっとも深刻な欠点は物理ネットワーク上でユーザのパスワードの本 質的なクリアテキスト転送をもたらすと言う事である。これは熟考した認証がアドレスを 試みると言う問題である。 Basic 認証がパスワードのクリアテキスト転送を伴うため、取り扱いに慎重を要する情報 や貴重な情報を保護するため (強化をする事無しに) 決して使用されるべきではない。 Basic 認証の一般的な使用は、たとえばサーバ上で正確な使用統計を集める目的ように、 身元確認 ユーザに身元確認の意味となるユーザ名とパスワードを供給する事 の目的のた めである。この方法で使用されるとき、もし保護されたドキュメントを横切る不正さが主 だった関心を持たないなら、その使用に危険は伴わないと思いたくなる。もしサーバがユ ーザのユーザ名とパスワードの両方を配給し、特に彼または彼女のパスワードを選択する 事をユーザに許さない場合にのみこれは正しい。複数パスワードの管理作業を避けるため の単一のパスワードをしばしば再使用する幼稚なユーザのため危険が起こる。 もしサーバがユーザ自身のパスワードの選択を許可するなら、脅威はサーバ上のドキュメ ントを横切る不正さのみではなく、アカウントパスワードを使う事を選んでいるすべての ユーザのアカウントを横切る不正さである。もしユーザが自身のその意味のパスワードを 選択できるように許されているなら、サーバはパスワードを含んでいるファイル (おそら く暗号化されている) を管理しなければならない。これらの多くは多分遠くのサイトから のユーザのアカウントパスワードであろう。もしこの情報が安全な様式で管理されている なら、そのようなシステムのオーナーや管理人は考えられるところでは義務を負っている 。 Basic Authentication も偽のサーバによってだまされる事に無防備である。事実彼が悪 意を持ったサーバやゲートウェイに接続しているとき、もしユーザが Basic 認証によっ て保護された情報を含んでいるホストに接続する事を信じるようにさせられるなら、アタ ッカーは後で使うためにパスワードを要求し保存してエラーを偽る。このタイプの攻撃は 熟考した認証 [32] では不可能である。サーバ実装者はゲートウェイや CGI スクリプト によって偽造されているこの種の可能性に対してガードすべきである。特に、そのゲート ウェイがクライアントによって探知できない方法でオリジナルサーバを装っている間、ク ライアントを複数処理に従事するための接続維持メカニズムを使用できるため、サーバが ゲートウェイへの接続に単純に返す事はとても危険である。 15.2 認証スキームの選択提供 HTTP/1.1 サーバは 401 (Authenticate) レスポンスの複数の誰何結果を返す事ができ、 それぞれの誰何は別のスキームで使用できる。ユーザエージェントに返される誰何の命令 はサーバがそれらが選択されたのを望むであろう命令である。サーバは最初にその誰何を "もっとも安全な" 認証スキームで命令すべきである。ユーザエージェントはユーザに、 ユーザエージェントが理解する最初のそれをさせる事を誰何として選択すべきである。 サーバが WWW-Authenticate ヘッダを使って認証スキームの選択を提供するとき、認証の "安全" は悪意のあるユーザが誰何のセットを取り込む事み、認証スキームのもっとも弱 いものを使用する事で彼/彼女自身を認証しようとするようなことだけである。従って、 その命令はサーバの情報よりもユーザの信頼証明を保護するのに役に立つ。 可能な man-in-the-middle (MITM) アタックはクライアントがユーザの信頼証明 (パスワ ードのような) を暴露するそれを使うであろう事を望んで、選択のセットに弱い認証スキ ームを追加するであろう。この理由により、クライアントは受け入れた選択から理解でき るうちでもっとも強いスキームを常に使用すべきである。 さらに強い MITM アタックはすべての提出された選択を削除し、Basic 認証をリクエスト する誰何を挿入するであろう。この理由により、この種のアタックに関して心配のあるユ ーザエージェントはかつてサーバによって要求されたもっとも強い認証スキームを覚えて おき、それよりも弱いものを使う前にユーザに確認を必要とする警告メッセージを提供す る事ができる。そのような MITM アタックが仕掛ける特に陰険な方法はだ混ざれやすいユ ーザに "free" キャッシングサービスを提供するであろう。 15.3 サーバログ情報の悪用 サーバはそれらの読み込み傾向や関心の対象で識別されるであろうユーザのリクエストに 関する個人情報を保存する立場にある。この情報は本質において明らかに秘密であり、そ の扱いはある国において法によって抑制されているであろう。データを供給するために H TTP プロトコルを使用している人たちは、そのようなデータが発行された結果によって身 元確認ができるどんな個人の許可なしに配布されさないという保証に対して責任がある。 15.4 取り扱いが慎重な情報の転送 一般的なデータ転送プロトコルに似て、HTTP は転送されるデータ内容を規制できないし 、与えられたどんなリクエストの状況の内、どんな情報の特有の一部の慎重さを決定する どんな優先方法もない。それゆえ、アプリケーションはこの情報の供給者にとって可能で あるようなこの情報上でのたくさんの制御を供給すべきである。四つのヘッダフィールド がこの状況において特に言及の価値がある: Server, Via, Referer 及び From。 サーバの具体的なソフトウェアのバージョンを示す事は、サーバマシンにセキュリティホ ールが知られているソフトウェアに対するアタックをより攻撃せやすくするかもしれない 。実装者は Server ヘッダフィールドをコンフィギュレーションできるオプションとさせ るべきである。 ネットワークファイアウォールを通すポータルを果たすプロキシは、ファイアウォールの 向こうのホストを識別するヘッダ情報の転送に関する特別な用心を持つべきである。特に 、それらは削除されるか受け入れる表現、ファイアウォールの向こうで制作されたすべて の Via フィールドに置き換えるべきである。 Referer フィールドは調査されるための読み込み傾向やリンクの逆引きを認める。これは とても有用であるが、もしユーザの詳細が Referer に含まれている情報から分割されて いなければ、その力は悪用される事ができる。さらに個人情報が既に削除されていても、 Referer フィールドは公表が不適当であろうプライベートドキュメントの URI を示すか もしれない。 From フィールドで送られる情報はユーザのプライバシー利害や彼らのサイトのセキュリ ティポリシーに反するかもしれないし、それゆえユーザが有効、無効、フィールド値の変 更ができるようにしなければ、それは転送されるべきではない。ユーザはユーザ設定やア プリケーションデフォルト設定においてこのフィールドの内容をセットできなければなら ない。 必要としているのではないが、われわれはユーザに From と Referer 情報の送信を有効 、無効にする事を提供する便利なトルグインターフェースを提案する。 15.5 ファイルやパス名を基にしたアタック HTTP オリジンサーバの実装は HTTP リクエストによって返されるドキュメントをサーバ 管理者によって意図されたものだけに制限ようにを気をつけるすべきである。もし HTTP サーバがファイルシステムのコールを伴う HTTP URIを直接解釈するなら、サーバは HTTP クライアントへの配信を目的としないファイルを送付しないよう特に注意を払わなければ ならない。たとえば、UNIX, Microsoft Windows や他のオペレーティングシステムはカレ ントディレクトリの上のレベルのディレクトリを示すパス要素として ".." を使う。その ようなシステムにおいて、もし HTTP サーバ経由でアクセス可能である事が意図されてい る外のリソースへのアクセスを別の方法で許すならば、HTTP サーバは Request-URI にお けるそのような構造のどんな物も許してはならない。同じく、サーバ内部でのみでの参照 が意図されたファイル (アクセス制御ファイル、設定ファイルやスクリプトコードなど) は、それらが取り扱いに慎重を要する情報を含んでいるため、不適当な検索から保護され なければならない。経験からそのような HTTP サーバインプリメンテーションの小さなバ グがセキュリティリスクに結びつく。 15.6 個人情報 HTTP クライアントはしばしば (ユーザの名前、ロケーション、メールアドレス、パスワ ード、暗号キーなどのような) 個人情報のたくさんの量を持ち、HTTP プロトコル経由で 別のリソースへのこの情報の意図されない流出を妨げるように特に気をつけるべきである 。われわれは、ユーザにそのような情報公開を制御するために用意される便利なインター フェースと、設計者や実装者がこの部分に特に注意する事を特に強く推奨する。歴史的な 背景は、この部分のエラーがしばしば深刻なセキュリティとプライバシーの問題の両方と なり、しばしば実装者の会社に対する不利な評判を高める事を示している。 15.7 Accept ヘッダに関連するプライバシー問題 Accept request-header はアクセスされたすべてのサーバにユーザに関する情報を示す事 ができる。特に Accept-Language ヘッダは、しばしば特有の言語を理解する事が特有の 民族グループの一員であることに強く関連させられているため、個人的な性質であるとみ なすであろう情報を示す。リクエストごとで送られる Accept-Language ヘッダの内容を コンフィギュレーションするためのオプションを提供するユーザエージェントは、コンフ ィギュレーションプロセスがユーザに必要としているプライバシーの損失に気づかせるよ うなメッセージを含むようにすることが強く推奨される。 プライバシーの損失を制限するアプローチは、ユーザエージェントに対してデフォルトに より Accept-Language ヘッダを送信する事を除外し、サーバによって生成された Vary r esponse-header フィールドのすべてを捜すことにより、そのような送信がサーバの品質 を向上できることに気づいたなら、サーバにAccept-Language ヘッダを送る事を開始すべ きかどうかをユーザに問うであろう。 特に、もしそれらが quality 値を含んでいるなら、リクエストごとに送られるユーザに よって設定された精巧な Accept ヘッダフィールドは、比較的信頼でき long-lived ユー ザを識別するものとしてサーバによって使用される事ができる。そのようなユーザを識別 するものは内容供給者が click-trailtracking を行う事を許し、共同作業の内容供給者 が cross-serverclick-trail 個々のユーザのフォーム提出と調和する事を許す。プロキ シの向こう側でない多くのユーザのため、ユーザエージェントが実行されているホストの ネットワークアドレスも long-lived ユーザを識別するものとして役に立つと言う事に注 意。プロキシがプライバシーを高めるために使用されている環境において、ユーザエージ ェントはエンドユーザに accept ヘッダコンフィギュレーションオプションを提供する事 に保守的であるべきである。極端なプライバシー手段として、プロキシは中継されたリク エストにおける acceptヘッダをフィルタできる。高いヘッダコンフィギュレーション性 機能を供給する一般的な目的のユーザエージェントは伴う可能性のあるプライバシーの損 失に関してユーザに警告すべきである。 15.8 DNS のごまかし HTTP を使用しているクライアントは Domain Name Service に非常に頼り、従って一般的 に IP アドレスと DNS 名の故意に間違った組み合わせをベースとしたセキュリティアタ ックがある。クライアントは IP アドレス/DNS 名の組み合わせの連続した正当性の想定 において用心深くあるべきである。 特に、HTTP クライアントは直前のホスト名 lookup の結果キャッシュよりも、IP アドレ ス/DNS 名組み合わせの確認に対するそれらの name resolver に頼るべきである。多くの プラットフォームは適切な場合において既にローカルにホスト名 lookup をキャッシュで き、それらはそうするようにコンフィギュレーションされるべきである。しかしながら、 これらの lookup はネームサーバによって報告された TTL (Time To Live) 情報がキャッ シュされた情報が有用なままであるであろうようなものになるときのみキャッシュされる べきである。 もし HTTP クライアントがパフォーマンスの改善をなすためにホスト名 lookupの結果を キャッシュするなら、それらは DNS によって報告される TTL 情報を監視しなければなら ない。 もし HTTP クライアントがこのルールを監視しないなら、それらは直前にアクセスしたサ ーバの IP アドレスが変更されるときだまされる。ネットワークの数値再割り当てがます ます一般的になってくる事が予想されるため、この形式のアタックの可能性は成長する。 従ってこの要求を監視する事はこの潜在的なセキュリティの弱さを減らす。 この要求は同じ DNS 名を使用している複製されたサーバに対してクライアントの load-b alancing 動作を改善し、この策略を使うサイトをアクセスする事においてユーザの直面 している失敗の可能性を減らす。 15.9 Location ヘッダとごまかし もし単一のサーバがお互い信頼していない複数の組織をサポートするなら、それらが権限 を持っていないところで、それらがリソースを無効にしようとしないように気をつけるた め、示された組織の制御の元に制作されたレスポンスのLocation ヘッダと Content-Loca tion ヘッダの値をチェックしなければならない。 16 謝辞 This specification makes heavy use of the augmented BNF and generic constructs d efined by David H. Crocker for RFC 822. Similarly, it reuses many of the definit ions provided by Nathaniel Borenstein and Ned Freed for MIME. We hope that their inclusion in this specification will help reduce past confusion over the relatio nship between HTTP and Internet mail message formats. The HTTP protocol has evolved considerably over the past four years. It has bene fited from a large and active developer community the many people who have parti cipated on the www-talk mailing list and it is that community which has been mos t res