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 リクエストに相当する場 合以外、サーバはエラー状況と