5.1 リクエストライン リクエストラインは、メソッドトークンに始まり、 Request-URI とプロトコ ルバージョンが後に続き、CRLF で終了する。要素は SP によって分けられ る。最後の CRLF シーケンス以外には、CR も LF も許されない。 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 5.1.1 メソッド メソッドトークンは、 Request-URI により識別されるリソースに働きかける ためのメソッドを示す。メソッドは大文字・小文字を区別する。 Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | "CONNECT" ; Section 9.9 | extension-method extension-method = token リソースにより認められるメソッドのリストは、Allow ヘッダフィールド (section 14.7) により示される。許されるメソッドのセットは動的に変化で きるため、レスポンスのリターンコードはそのメソッドが現在リソースに許 されているかどうかにかかわらず、常にクライアントに通知される。オリジ ンサーバは、メソッドを理解できても要求されたリソースに対して許されて いない場合は、ステータスコード 405 (Method Not Allowed) を返す *べき であり*、またオリジンサーバがそのメソッドを認識できなかったり実装され ていない場合には 501 (Not Implemented) を返す *べきである*。すべての 一般目的サーバ{general-purpose servers} では、GET とHEAD メソッドは、 サポートしてい *なければならない*。他のすべてのメソッドは *オプショナ ル* であるが、もし上記のメソッドが実装されるなら、それらは section 9 で記述されているものと同じセマンティクスで実装されなければならない。 5.1.2 Request-URI Request-URI は、Uniform Resource Identifier (section 3.2) であり、リ クエストを適用するリソースを識別する。 Request-URI = "*" | absoluteURI | abs_path | authority Request-URI の四つのオプションは、そのリクエストの性質に依存する。ア スタリスク "*" は、そのリクエストが特有のリソースではなく、サーバ自身 に適用するという事を意味し、使われているメソッドがリソースに適用され る必要がないときにのみ許される。一例を挙げる。 OPTIONS * HTTP/1.1 absoluteURI 形式は、リクエストがプロクシに対して生成されている時に *要求される*。プロクシは、そのリクエストを転送するか、有効なキャッシ ュ内から提供する時に呼び出され、レスポンスを返す。プロクシは、そのリ クエストを別のプロクシか、あるいは absoluteURI によって特定されたサー バに直接送る事が *できる* 事に注意せよ。リクエストループを避けるため に、プロクシはそのサーバ名をエイリアス、ローカルバリエーション、数値 IP アドレスまで含め、すべて理解でき *なければならない*。Request-Line の例は以下の様になる。 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 HTTP の将来のバージョンにおいてすべてのリクエストが absoluteURI へ移 行する事ができるように、例え HTTP/1.1 クライアントはプロクシへのリク エストとしてのみしか生成しないものであったとしても、全ての HTTP/1.1 サーバはリクエストにおける absoluteURI 形式を受け入れ *なければならな い*。 authority 形式は、CONNECT メソッド (section 9.9) のみで使用する。 Request-URI の最も一般的な形式は、オリジンサーバやゲートウェイ上の リソースを識別するために使用される事である。この場合、URI の絶対パス は Request-URI として通信され *なければならない* (section 3.2.1, abs_path 参照) し、URI のネットワークロケーション(authority) は、Host ヘッダフィールドにおいて転送され *なければならない*。例えば、オリジン サーバから直接上記のリソースを回収する事を望むクライアントは、ホスト "www.w3.org" のポート 80 に TCP 接続を確立し、その行を送る。 GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org 残りのリクエストをその後に送る。絶対パスは空ではない事に注意せよ。も し、元の URI で何も与えられていなければ、それは "/" (サーバのルート) が与えられ *なければならない*。 Request-URI は、section 3.2.1 に記された形式で送られる。もし、 Request-URI に "% HEX HEX" エンコード [42] が使用されていたら、オリジ ンサーバはそのリクエストを適切に解釈するためにその Request-URI をデコ ードし *なければならない*。サーバは、不正な Request-URI には、適切な ステータスコードをもって応答す *べきである*。 透過的プロクシは、上で記した空の{null} abs_path を "/" に置き換えると いう場合以外は、次のインバウンドサーバに転送する時に、受け取った Request-URI の "abs_path" の一部を書き換え *てはならない*。 注意: "書き換え禁止" という規則は、オリジンサーバが予約された目的 のための予約されていない URL 文字を不適当に使用している時に、プロ クシがリクエストの意味を変えないようにする狙いがある。実装者は、い くつかの HTTP/1.1 以前のプロクシが Request-URI を書き換える事が知 られている、という事を認識すべきである。 5.2 リクエストによって識別されるリソース インターネットリクエストにより識別された正確なリソースは、Request-URI と Host ヘッダフィールドの両方で調べる事で決定される。 HTTP/1.1 リクエストによってリソースを決定する時、リクエストされたホス トによってリソースが異なるという事を認めていないオリジンサーバは、 Host ヘッダフィールド値を無視するで *あろう*。(但し、HTTP/1.1 での Host をサポートする別の必要条件について section 19.6.1.1 参照。) リクエストされたホストに基づいてリソースを区別する (しばしば仮想ホス トや空虚{vanity} なホスト名として参照される) オリジンサーバは、 HTTP/1.1 リクエストで要求されたリソースを決定するために以下のルールを 使わ *なければならない*。 1.もし、Request-URI が absoluteURI ならば、ホストは Request-URI の一 部である。リクエストにおけるどんな Host ヘッダフィールド値も無視さ れ *なければならない*。 2.もし、Request-URI が absoluteURI でなく、リクエストが Host ヘッダフ ィールドを含んでいるならば、ホストは Host ヘッダフィールド値によっ て決定される。 3.もし、規則 1 や 2 で決定されるようなホストがそのサーバで正当なホス トでないならば、レスポンスは 400 (Bad Request) エラーメッセージで *なければならない*。 Host ヘッダフィールドが無い HTTP/1.0 リクエストを受信した者は、要求さ れたリソースがどれほど正確な要求されているかを決定するため (例えば、 特定のホストのユニークな何かに対する URI パスの試験のような) 発見方法 を試す事が *できる*。 5.3 リクエストヘッダフィールド リクエストヘッダフィールドを用いて、クライアントはサーバにリクエスト やクライアント自身に関する追加的な情報を渡す事ができる。これらのフィ ールドは、メソッド発動{invocation} プログラミング言語におけるパラメー タと同等なセマンティクスを持つ、リクエスト修飾子として動作する。 request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization ; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 | If-Match ; Section 14.24 | If-Modified-Since ; Section 14.25 | If-None-Match ; Section 14.26 | If-Range ; Section 14.27 | If-Unmodified-Since ; Section 14.28 | Max-Forwards ; Section 14.31 | Proxy-Authorization ; Section 14.34 | Range ; Section 14.35 | Referer ; Section 14.36 | TE ; Section 14.39 | User-Agent ; Section 14.43 リクエストヘッダフィールド名は、プロトコルバージョンの変化に伴っての み確実に拡張されうる。しかしながら、新しい、あるいは実験的なヘッダフ ィールドは、もしそのコミュニケーションでのすべてのパーティがそれらを リクエストヘッダフィールドであると認識できるなら、一般的なヘッダフィ ールドのセマンティクスを与えても *よい*。認識されないヘッダフィールド は、エンティティヘッダフィールドとして扱われる。 6 レスポンス リクエストメッセージを受信・解釈した後、サーバは HTTP レスポンスメッ セージを返す。 Response = Status-Line ; Section 6.1 *(( general-header ; Section 4.5 | response-header ; Section 6.2 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 7.2 6.1 ステータスライン レスポンスメッセージの最初の行は、プロトコルのバージョン、ステータス コード番号、それに関連したテキストフレーズからなるステータスライン で、それぞれの要素は、SP によって分けられる。最後の CRLF シーケンス以 外には、CR も LF も許されない。 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 6.1.1 ステータスコードと説明句 ステータスコード要素とは、リクエストを理解し満足するための試行につい ての三桁の数字による結果コードである。これらのコードは、section 10 に て完全に定義されている。説明句は、ステータスコードについて短いテキス ト記述を与える目的を持つ。ステータスコードは自動処理によって、また説 明句は人間によってそれぞれ使われる事を意図している。クライアントは、 説明句を調べたり表示したりする必要はない。 ステータスコードの最初の数字はレスポンスのクラスを定義する。後ろの二 つの数字はどんな分類ルールも持たない。最初の数字には五つの値がある。 - 1xx: Informational - リクエストは受け入れられ、処理を続けている - 2xx: Success - 動作は正常に受信され、理解され、受け入れられた - 3xx: Redirection - リクエストを完了するためには、さらに動作を行 わなければならない - 4xx: Client Error - リクエストは間違った構文か、果たす事のできな いものを含んでいる - 5xx: Server Error - サーバは明らかに正当なリクエストを果たすのに 失敗した HTTP/1.1 で定義された個々のステータスコード数値、及びそれに相当する説 明句のセットの例の値を以下に示す。ここでリストされた説明句は推奨に過 ぎない。すなわち、これらはプロトコルに影響が出ないローカルな範囲で、 それに相当するものに置き換えても *よい*。 Status-Code = "100" ; Section 10.1.1: Continue | "101" ; Section 10.1.2: Switching Protocols | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created | "202" ; Section 10.2.3: Accepted | "203" ; Section 10.2.4: Non-Authoritative Information | "204" ; Section 10.2.5: No Content | "205" ; Section 10.2.6: Reset Content | "206" ; Section 10.2.7: Partial Content | "300" ; Section 10.3.1: Multiple Choices | "301" ; Section 10.3.2: Moved Permanently | "302" ; Section 10.3.3: Found | "303" ; Section 10.3.4: See Other | "304" ; Section 10.3.5: Not Modified | "305" ; Section 10.3.6: Use Proxy | "307" ; Section 10.3.8: Temporary Redirect | "400" ; Section 10.4.1: Bad Request | "401" ; Section 10.4.2: Unauthorized | "402" ; Section 10.4.3: Payment Required | "403" ; Section 10.4.4: Forbidden | "404" ; Section 10.4.5: Not Found | "405" ; Section 10.4.6: Method Not Allowed | "406" ; Section 10.4.7: Not Acceptable | "407" ; Section 10.4.8: Proxy Authentication Required | "408" ; Section 10.4.9: Request Time-out | "409" ; Section 10.4.10: Conflict | "410" ; Section 10.4.11: Gone | "411" ; Section 10.4.12: Length Required | "412" ; Section 10.4.13: Precondition Failed | "413" ; Section 10.4.14: Request Entity Too Large | "414" ; Section 10.4.15: Request-URI Too Large | "415" ; Section 10.4.16: Unsupported Media Type | "416" ; Section 10.4.17: Requested range not satisfiable | "417" ; Section 10.4.18: Expectation Failed | "500" ; Section 10.5.1: Internal Server Error | "501" ; Section 10.5.2: Not Implemented | "502" ; Section 10.5.3: Bad Gateway | "503" ; Section 10.5.4: Service Unavailable | "504" ; Section 10.5.5: Gateway Time-out | "505" ; Section 10.5.6: HTTP Version not supported | extension-code extension-code = 3DIGIT Reason-Phrase = * HTTP ステータスコードは拡張可能である。HTTP アプリケーションは、登録 されたすべてのステータスコードを明確に理解できる事が望ましいが、それ らのすべての意味を理解する必要はない。しかし、アプリケーションは最初 の数字によって示されるステータスコードのクラスはすべて理解し *なけれ ばならない* し、理解できないレスポンスはキャッシュし *てはならない* という例外を除いて、すべての理解できないレスポンスをそのクラスの x00 ステータスコードと同等に扱わ *なければならない*。例えば、431 という 理解できないステータスコードがクライアントに受信されたなら、そのリク エストに何か誤りがあると安全に推測ができ、それが 400 ステータスコード を受信したかのようにレスポンスを扱う事ができる。このような場合、エン ティティはこの異常なステータスを説明しているであろう人間が読める情報 を含んでいると思われるから、ユーザエージェントはレスポンスと共に返さ れたエンティティをユーザに見せる *べきである*。 6.2 レスポンスヘッダフィールド レスポンスヘッダフィールドを用いて、サーバはステータスラインに置けな いレスポンスに関する追加的な情報を渡す事ができる。これらのヘッダフィ ールドは、サーバについてや、Request-URI によって識別されるリソースへ の更なるアクセスに関する情報を与える。 response-header = Accept-Ranges ; Section 14.5 | Age ; Section 14.6 | ETag ; Section 14.19 | Location ; Section 14.30 | Proxy-Authenticate ; Section 14.33 | Retry-After ; Section 14.37 | Server ; Section 14.38 | Vary ; Section 14.44 | WWW-Authenticate ; Section 14.47 レスポンスヘッダフィールド名は、プロトコルバージョンの変化に伴っての み確実に拡張されうる。しかしながら、新しい、あるいは実験的なヘッダフ ィールドは、もしそのコミュニケーションでのすべてのパーティがそれらを レスポンスヘッダフィールドであると認識できるなら、一般的なヘッダフィ ールドのセマンティクスを与えても *よい*。認識されないヘッダフィールド は、エンティティヘッダフィールドとして扱われる。 7 エンティティ リクエストやレスポンスでのメッセージは、リクエストメソッドやレスポン スステータスコードによって規制されていなければ、エンティティを転送す る事が *できる*。エンティティは、エンティティヘッダフィールドとエンテ ィティボディから成るが、エンティティヘッダのみを含むレスポンスもあ る。 この章においては、送信者と受信者の両方がクライアントかサーバのどちら かを表すが、それはエンティティを送信するか受信するかに依存する。 7.1 エンティティヘッダフィールド エンティティヘッダフィールドは、エンティティボディや、もしボディが無 ければリクエストによって識別されたリソースについての外部情報を定義す る。この外部情報は、*オプションナル* なものもあるが、この仕様書の中で *要求している* ものもある。 entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Range ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header 拡張ヘッダメカニズムは、プロトコルを変更する事無く追加的エンティティ ヘッダフィールドを定義できるようにしているが、これらのフィールドが受 信者によって認識されるという事は仮定できない。認識されないヘッダフィ ールドは、受信者によって無視される *べきであり*、透過的プロクシによっ て転送され *なければならない*。 7.2 エンティティボディ もし、HTTP リクエストやレスポンスと共にエンティティボディが送られてき たら、それはエンティティヘッダフィールドによって定義されるフォーマッ トをもってエンコーディングされている。 entity-body = *OCTET エンティティボディは、section 4.3 に記されるように、メッセージボディ がある時のみ、メッセージの中に存在する。エンティティボディは、メッセ ージの安全かつ適切な転送を保証するために適用されるであろうあらゆる転 送エンコーディングをデコードする事によってメッセージボディから得られ る。 7.2.1 タイプ エンティティボディがメッセージに含まれる時、このボディのデータタイプ は Content-Type と Content-Encoding 各ヘッダフィールドによって決定さ れる。これらは、2層の順列エンコーディングモデル {ordered encoding model} を定義する。 entity-body := Content-Encoding( Content-Type( data ) ) Content-Type は、元のデータのメディアタイプを示す。Content-Encoding は、要求されたリソースが持つデータを、通常はデータ圧縮という目的のた めに適用されるあらゆる追加的な内容コーディングを示すために使われるで あろう。デフォルトのエンコーディングはない。 エンティティボディを含む HTTP/1.1 メッセージは、いつでもそのボディの メディアタイプを定義するための Content-Type ヘッダフィールドを含む *べきである*。メディアタイプが Content-Type ヘッダによって与えられな い場合に限り、受信者はリソースの内容の検査や、あるいはリソースを識別 するために使用されている URI の名前拡張子を調べる事によってメディアタ イプを推測してみても *よい*。もしメディアタイプが分からないままであっ たら、受信者はそれをタイプ "application/octet-stream" として扱う *べ きである*。 7.2.2 エンティティ長 メッセージのエンティティボディ長は、あらゆる転送エンコーディングが適 用される前のメッセージボディの長さである。section 4.4 では、どのよう にメッセージボディの転送長さが決められているかを定義している。 8 接続 8.1 持続的接続 8.1.1 目的 持続的接続が無い時代には、別々の URL からリソースを取得するために、そ れぞれで TCP 接続を確立していたため、サーバのロードを増加させ、インタ ーネットの混雑を引き起こす原因になっていた。インラインイメージやその 他の関連するデータの使用のために、クライアントはしばしば短時間に同じ サーバへ複数のリクエストを行う必要がある。これらのパフォーマンスの問 題の解析や持続的接続のプロトタイプの実装から得られた結果については、 現在入手可能である [26] [30]。持続的接続を実装する過程で得た経験や、 実際に HTTP/1.1 (RFC 2068) を実装したものを測定した所、良い結果が得ら れた [39]。また一方で、例えば T/TCP [27] のような、違う選択肢も研究さ れてきている。 持続的 HTTP 接続には、いくつかの利点がある。 - TCP コネクションの開閉が少なくなる事で、ルータやホスト (クライア ント、サーバ、プロクシ、ゲートウェイ、トンネル、キャッシュ) にお ける CPU 時間は節約され、TCP プロトコルコントロールブロックのた めに使用されるメモリも節約される。 - HTTP リクエストとレスポンスは、接続上でパイプライン化する事がで きる。パイプライン化によって、クライアントは、各々のレスポンスを 待つ事なく複数のリクエストを行う事ができ、また一つの TCP 接続を より少ない経過時間で、より効果的に使用できる。 - TCP のオープンや、TCP sufficient time にネットワークの混雑状況を 決定させるために使われるパケットの数の減少によって、ネットワーク における混雑は減少される。 - TCP 接続がすでに確立しているので、次回リクエスト時にはそのための 時間が必要無く、リクエストへの反応時間は短縮される。 - TCP 接続を閉じるという罰則無しにエラーを報告できるため、HTTP は より上品に発展する。もし古いサーバと通信するとしても、HTTP の将 来のバージョンを使用するクライアントは、楽天的に新しい機能を試み る事ができ、エラー報告の後には古いセマンティクスが伴う再試行も報 告されるであろう。 HTTP インプリメンテーションは持続的接続を実装す *べきである*。 8.1.2 全体の動作 HTTP/1.1 と HTTP のそれ以前のバージョンとの重要な違いは、すべての HTTP 接続において持続的な接続がデフォルトの動作であるかどうかという事 である。すなわち、何か別の方法が示されない限り、クライアントは、例え サーバからエラーレスポンスが返されても、サーバが持続的接続を維持する であろうと仮定す *べきである*。 持続的接続は、クライアントとサーバが TCP 接続を閉じる時に合図を行える というメカニズムを提供する。この合図は、Connection ヘッダフィールド (section 14.10) を用いて示す。一度接続を閉じる事が示されたら、クライ アントはその接続でそれ以上のリクエストを送っ *てはならない*。 8.1.2.1 ネゴシエーション HTTP/1.1 サーバは、HTTP/1.1 クライアントがリクエスト中に "close" とい う connection-token を含んでいる Connection ヘッダを送られなければ、 持続的接続を維持するつもりである事を想定しても *よい*。もし、サーバが レスポンスを送信した後すぐに接続を閉じる事を選ぶのであれば、 connection-token に close を含んでいる Connection ヘッダを送信す *べ きである*。 HTTP/1.1 クライアントは、接続が開いたままである事を期待しても *よい* が、サーバからのレスポンスが connection-token が close である Connection ヘッダを含んでいるかどうかに基づいて回線の維持についてを決 めるであろう。クライアントがそのリクエスト以上に接続を維持する事を望 まない場合は、connection-token に close を含む Connection ヘッダを送 る *べきである*。 もし、クライアントかサーバのどちらかが、Connection ヘッダにおいて close トークンを送ったならば、そのリクエストはその接続に対する最後の ものとなる。 クライアントやサーバは、それが明確に合図された場合以外は、1.1 よりも 低い HTTP のバージョンにおいては、持続的接続が維持されていると仮定す *べきではない*。HTTP/1.0 クライアントとの下位互換性に必要な情報につい ては section 19.6.2 参照。 持続性を維持するために、接続上のすべてのメッセージは section 4.4 で定 義されているように、自身で定義した (例えばそれが接続の閉鎖によって定 義されるようなものではない) メッセージ長さを持た *なければならない*。 8.1.2.2 パイプライン化 持続的接続をサポートするクライアントは、そのリクエストを "パイプライ ン" する事が *できる* (例えば、複数のレスポンスを待つ事無く、複数のリ クエストを送る)。サーバは、リクエストが受信されたのと同じ順番で、それ らのリクエストのレスポンスを返さ *なければならない*。 持続的接続を想定し、接続確立の後にすぐパイプラインを行うクライアント は、もし最初のパイプライン化への試行が失敗した場合は、それらの接続を 再試行する準備をす *べきである*。クライアントがそのような再試行を行う 場合は、その接続が持続的であると分かるまではパイプラインを行っ *ては ならない*。もし、サーバがすべての通信のレスポンスを返す前に接続を閉 じてしまったら、クライアントはそれらのリクエストを再送信する準備をし *なければならない*。 クライアントは、等冪でない{non-idempotent} メソッド、あるいはメソッド のシーケンスを使ったリクエストをパイプラインす *べきではない* (section 9.1.2 参照)。そうでなければ、転送接続の早過ぎる終了が不確定 な結果を招く事になるだろう。等冪でないリクエストを送ろうとするクライ アントは、前のリクエストのレスポンスステータスを受け取るまでリクエス トを送る事を待つ *べきである*。 8.1.3 プロクシサーバ プロクシが section 14.10 で指定されるように Connection ヘッダの機能を 正確に実装する事は特に重要である。 プロクシサーバは、自身が接続しているクライアントとオリジンサーバ (あ るいは別のプロクシサーバ) のそれぞれに持続的接続を知らせ *なければな らない*。それぞれの持続的接続は、一つの転送リンクのみで適用される。 プロクシサーバは、HTTP/1.0 クライアントと HTTP/1.1 の持続的接続を確立 し *てはならない* (但し、多くの HTTP/1.0 クライアントに実装されている Keep-Alive ヘッダを使った問題の情報と議論については RFC 2068 [33] 参 照)。 8.1.4 現実的な考察 多くのサーバは、もはや接続を維持しないとするタイムアウト値を持ってい るであろう。クライアントはたぶん同じサーバへとより多くの接続を持とう とするはずなので、プロクシサーバはサーバが設定するタイムアウト値より も大きな値にしたほうがよい。持続的接続の使用は、クライアントやサーバ のためのこのタイムアウト値の長さ (あるいは存在) に必要性を置かない。 クライアントやサーバがタイムアウトを望む時は、転送接続上礼儀正しい閉 鎖を発行す *べきである*。クライアントもサーバも、他方の転送の閉鎖を絶 えず監視し、適切にそれに応じる *べきである*。もし、クライアントやサー バが、相手側の閉鎖を即座に検出しなければ、それはネットワーク上の不必 要なリソース消耗を引き起こすかもしれない。 クライアント、サーバ、あるいはプロクシは、どんな時でも転送接続を閉鎖 する事が *できる*。例えば、サーバが "アイドル" 状態の接続を閉鎖しよう と決めたのと同時に、クライアントは新しいリクエストを送り始めるかもし れない。サーバ側から見れば接続はアイドルである間に閉鎖されているが、 クライアント側から見ればリクエストは進行中である。 これは、クライアント、サーバ、プロクシが、非同期のクローズイベントか ら回復でき *なければならない* という事を意味する。クライアントソフト ウェアは転送接続を再度オープンし、リクエストシーケンスが等冪 {idempotent} (section 9.1.2 参照) である限り、ユーザインタラクション なしに中止されたリクエストのシーケンスを再送信す *べきである*。そうで ないメソッドやシーケンスは自動的に再試行し *てはならない* が、ユーザ エージェントは人間のオペレータにリクエストの再試行についての選択を尋 ねても *よい*。アプリケーションが意味を理解した上で、ユーザ自身の確認 の代わりにユーザエージェントソフトウェアが確認しても *よい*。この自動 再試行は、もし二回目のリクエストシーケンスが失敗したなら繰り返す *べ きではない*。 サーバは、もし完全に可能なら、常に一つの接続につき少なくとも一つのリ クエストにレスポンスす *べきである*。サーバは、ネットワークやクライア ントの失敗を疑う場合以外は、レスポンスの転送中に接続をクローズす *べ きではない*。 持続的接続を使用するクライアントは、サーバへ維持する同時接続の数を制 限す *べきである*。シングルユーザクライアントは、どんなサーバやプロク シへも 2 接続より多く維持す *べきではない*。プロクシは、N は同時のア クティブユーザの数として、別のサーバやプロクシへの 2*N 接続以上を使用 す *べきである*。これらのガイドラインは HTTP レスポンスタイムを改善 し、ネットワークの混雑を避けようとするものである。 8.2 メッセージ転送の必要条件 8.2.1 持続的接続とフローコントロール HTTP/1.1 サーバは、一時的な過負荷を解消するためには、持続的接続を維持 し、TCP フローコントロールメカニズムを使う *べきであり*、クライアント が再試行するであろうという期待を持って接続を終了させるよりもよい。後 者の方法ではネットワークの混雑はよりひどくなるであろう。 8.2.2 エラーステータスメッセージのための接続のモニタリング メッセージボディを送る HTTP/1.1 (あるいはそれ以降) のクライアントは、 リクエストを送っている間、エラーステータスのためにネットワークの接続 をモニタリングす *べきである*。エラーステータスを発見した場合、すぐに ボディの転送を止める *べきである*。もしボディに "chunked" エンコーデ ィング (section 3.6) を施していたら、早過ぎるメッセージの終わりを表す ために 0 サイズのチャンクと空の trailer を使う事が *できる*。もしボデ ィより Content-Length ヘッダが先に送られていたら、クライアントは接続 を閉じ *なければならない*。 8.2.3 100 (Continue) ステータスの使用 100 (Continue) ステータス (section 10.1.1 参照) は、オリジンサーバが クライアントがリクエストボディを送る前に (リクエストヘッダに基づいた) リクエストを受け入れようとする場合に、リクエストボディを伴ったリクエ ストメッセージを送る事をクライアントに決めさせるという目的を持つ。い くつかのケースでは、サーバがボディを見る事も無くメッセージを受けつけ ていない場合にクライアントがボディを送る事は、不適切でひどく効率が悪 くなる事がある。 HTTP/1.1 クライアントの必要条件は、以下の通りである。 - もしクライアントがリクエストボディを送る前に 100 (Continue) レス ポンスのために待とうとするならば、"100-continue" という expectation を持った Expect リクエストヘッダフィールド(section 14.20) を送ら *なければならない*。 - もしリクエストボディを送るつもりが無いならば、"100-continue" と いう expectation を持った Expect リクエストヘッダフィールド (section 14.20) を送っ *てはならない*。 未だに古いインプリメンテーションが存在するため、プロトコルではクライ アントが 417 (Expectation Failed) ステータスや 100 (Continue) ステー タスを受け取る前に、"Expect: 100-continue" を送ってしまうかもしれない ようなあいまいな場面を認めている。それ故に、クライアントが 100 (Continue) ステータスを見た事が無いようなオリジンサーバ (あるいは経由 するプロクシ) にこれを送るような時でも、リクエストボディを送る前に無 期限で待つような事はす *べきではない*。 HTTP/1.1 オリジンサーバの必要条件は、以下の通りである。 - "100-continue" という expectation を持つ Expect リクエストヘッダ フィールドを含むリクエストを受け取った時は、100 (Continue) ステ ータスを応答し引き続き入力ストリームを読み続けるか、最終ステータ スコードを応答するか、どちらかを実行し *なければならない*。オリ ジンサーバは、100 (Continue) レスポンスを送る前にリクエストボデ ィを待ってい *てはならない*。最終ステータスコードを応答した場合 は、転送接続を切断しても *よい* し、引き続き読みこんで残りのリク エストを破棄しても *よい*。最終ステータスコードを返した場合は、 そのリクエストメソッドを実行し *てはならない*。 - オリジンサーバは、リクエストメッセージが "100-continue" という expectation を持つ Expect リクエストヘッダを含んでいなければ 100 (Continue) レスポンスを送る *べきではなく*、リクエストが HTTP/1.0 (あるいはそれ以前) のクライアントからのものであったら、 100 (Continue) レスポンスを送っ *てはならない*。この規則には拡張 がある。すなわち、RFC 2068 との互換性のため、サーバは "100-continue" という expectation を持つ Expect リクエストヘッダ を含んでいない HTTP/1.1 PUT あるいは POST リクエストへのレスポン スに 100 (Continue) を送る事が *できる*。クライアントのプロセス が 100 (Continue) ステータスのために宣言されない待機によって遅れ る事を最小限にするという目的を持つこの拡張は、HTTP/1.1 リクエス トにのみ適用され、他の HTTP バージョン値を持つリクエストには適用 されない。 - オリジンサーバは、すでにそのリクエストに関する一部、あるいは全部 のリクエストボディを既に受け取っている場合、100 (Continue) レス ポンスを省略する事が *できる*。 - 100 (Continue) レスポンスを送るオリジンサーバは、先に転送接続が 切られているので無ければ、一度リクエストボディが受け取られ、処理 され、最終的には最終ステータスコードを送ら *なければならない*。 - オリジンサーバが "100-continue" という expectation を持つ Expect リクエストヘッダフィールドを含まないリクエストを受け取ったなら ば、リクエストはリクエストボディを含んでいるので、サーバはその転 送接続からのリクエストボディ全体を読みきる前に最終ステータスコー ドを返すが、リクエスト全体を読みきるまで、あるいはクライアントが その接続を切断するまでは、サーバは、その転送接続を切断す *べきで はない*。そうしなければ、クライアントは確実にレスポンスメッセー ジを受け取れないかもしれない。しかし、この必要条件はサーバがサー ビス不能攻撃{denial-of-service attacks} やひどく破綻したクライア ントインプリメンテーションから、己の身を守る事を妨げるようには作 作られてはいない。 HTTP/1.1 プロクシの必要条件は、以下の通りである。 - プロクシが "100-continue" という expectation を持つ Expect リク エストヘッダフィールドを含むリクエストを受け取った時に、プロクシ が次に接続する{next-hop} サーバが HTTP/1.1 以上に従っている事を 知っている、あるいは次に接続するサーバの HTTP バージョンを知らな い場合には、Expect ヘッダフィールドを含めて、リクエストを転送し *なければならない*。 - プロクシが、次に接続するサーバが HTTP/1.0 以下のバージョンである 事を知っていたら、そのリクエストは転送せずに、417 (Expectation Failed) ステータスを返さ *なければならない*。 - プロクシは、最近参照したネクストホップサーバから受け取った HTTP バージョン番号をキャッシュに記録し保管す *べきである*。 - プロクシは、HTTP/1.0 (あるいはそれ以前) のクライアントから受け取 り、そこに "100-continue" という expectation を持つ Expect リク エストヘッダフィールドを含んでいないリクエストメッセージは、100 (Continue) レスポンスを転送し *てはならない*。この必要条件は、 1xx レスポンス (section 10.1 参照) を転送するという一般規則を上 書きする。 8.2.4 サーバが早まって接続を閉じた場合のクライアントの振る舞い もし、HTTP/1.1 クライアントがリクエストボディを持つが、"100-continue" という expectation を持つ Expect リクエストヘッダフィールドを含んでい ないリクエストメッセージを送り、しかもクライアントは HTTP/1.1 オリジ ンサーバには直接接続はしておらず、そこでクライアントがサーバからのど んなステータスをも受け取る前に接続の切断を知った場合は、クライアント はリクエストを再試行す *べきである*。クライアントがこのリクエストを再 試行する時は、確実なレスポンスの獲得を保証させるため、以下の "binary exponential backoff" アルゴリズムを使用 *できる*。 1. サーバへの接続を初期化する 2. リクエストヘッダを転送する 3. サーバへと見積もった round-trip time (つまり、その接続を確立す るためにかかった時間に基づいているもの) か、あるいは round-trip time が利用できい場合は定数値である 5 秒で変数 R を初期化する。 4. T = R * (2**N) を計算する。この時、N はこのリクエストの前までの 試行回数である。 5. サーバからのエラーレスポンスが来るか、もしくは T 秒 (どちらかが 来るまで) 待つ 6. エラーレスポンスが受信されなければ、T 秒後にリクエストのボディ を転送する。 7. クライアントは、コネクションが早まって切断されたのを知ったなら ば、リクエストが受け入れられ、エラーレスポンスを受け取るか、ユ ーザが待ちかねて再試行プロセスを終了するまで、ステップ 1 から繰 り返す。 上のどの時点でも、エラーステータスを受けとったら、クライアントは - 続ける *べきではない* し - もしリクエストメッセージを完全に送信していなければ、接続を切断す *べきである*。 9 メソッド定義 HTTP/1.1 のための一般的なメソッドのセットは以下に定義される。このセッ トは拡張可能であるが、追加されるメソッドは別々に拡張されたクライアン トとサーバに対して同じセマンティクスを共有する事を仮定できない。 Host リクエストヘッダフィールド(section 14.23) は、すべての HTTP/1.1 リクエストに付加され *なければならない*。 9.1 安全なメソッドと等冪{idempotent} なメソッド 9.1.1 安全なメソッド 実装者は、インターネット上における相互動作においてはソフトウェアがユ ーザを表しているという事を認識すべきであり、ユーザがそれら自身や他の ものに対して予測しない意図を持つようなあらゆる動作に気がつく事ができ るように注意すべきである。 特に、GET と HEAD メソッドはその動作にリソースの回収以上の意味を持つ *べきではない* という慣習が確立されている。これらのメソッドは、"安全" だと考えるべきである。これによって、ユーザエージェントがそれ以外の、 例えば POST, PUT, DELETE のようなメソッドを特別な方法で表す事ができる ようになり、ユーザにひょっとしたら安全でない動作が要求されているかも しれないという事実を認識させる。 本質的に、サーバが GET リクエストを実行した結果として副作用を起こさな いという事を保証するのは不可能であり、事実、いくつかの動的なリソース はそれが特徴であると考えている。ここで特に区別すべきなのは、ユーザが 副作用を要求しなかったという事であり、それゆえにそれらに対しては責任 をもてない。 9.1.2 等冪{idempotent} なメソッド メソッドは、(エラーや期限切れ発行とは別に) 同一のリクエストの N > 0 の副作用が単一のリクエストにおけるものと同じであるような際には "等冪{idempotence}" の性質を持つ事もできる。GET, HEAD, PUT, DELETE 各 メソッドはこの性質を共有する。また、OPTIONS と TRACE 各メソッドは副作 用を持つ *べきではない* し、本来等冪であるものである。 しかしながら、たとえその順序にて実行される全てのメソッドが等冪であっ たとしても、いくつかのリクエストの順番は等冪ではない。(もし全体の順序 中のある一つを実行しても、その順序の全体、または一部分を再実行した際 に結果は常に変わらないという事になるのであれば、順序は等冪である。) 例えば、同じ順序でもその結果が後に修正される値に依存するのであれば、 順序は等冪ではない。 副作用を持たない順序は、(同時に起こる動作は同じリソースの一組{set} 上 に実行されている事は無い、との条件で) 定義によって等冪である。 9.2 OPTIONS OPTIONS メソッドは、Request-URI によって識別されるリクエスト／レスポ ンス連鎖上で利用可能な通信オプションについての情報のためのリクエスト を表す。クライアントは、このメソッドはを使ってリソースアクションを暗 に意味したりリソース回収を初期化する事なしに、リソースやサーバの能力 に関するオプションや必要条件を決定する事ができる。 このメソッドへのレスポンスはキャッシュ可能ではない。 もし OPTIONS リクエストが (Content-Length や Transfer-Encoding の存在 によって指し示される様な) エンティティボディを含むならば、そのメディ アタイプは Content-Type フィールドによって指し示され *なければならな い*。この特性は、そのようなエンティティボディのいかなる使用方法も決定 しないが、HTTP の将来的な拡張によってそのサーバについてのより詳細な情 報文字列を作るために OPTIONS のボディを使うかもしれない。そのような拡 張機能をサポートしていないサーバでは、リクエストボディを廃棄する *か もしれない*。 もし、Request-URI がアスタリスク ("*") なら、OPTIONS リクエストは特定 のリソースへというよりも全体としてサーバへ適用する意思を示す。サーバ のコミュニケーションオプションは典型的にリソースに依存するので、"*" リクエストは、まるで "ping" や "no-op" のように使われるのみで、すなわ ちサーバの能力をテストするする事をクライアントに許可する以上には意味 を持たない。例えば、これはプロクシに HTTP/1.1 に従っているか (あるい はその機能が欠けているか) をテストするために使われる。 もし、Request-URI が アスタリスクでなければ、OPTIONS リクエストはその リソースと通信する時に利用可能なオプションのみを尋ねる。 200 レスポンスには、サーバによって実装され、そのリソースに適用できる オプション的な機能を示す (例えば、Allow のような) ヘッダフィールド や、可能であればこの仕様書で定義されていないような拡張も含む *べきで ある*。もしレスポンスボディがあれば、それはコミュニケーションオプショ ンについての情報も含む *べきである*。そのようなボディのフォーマットは この仕様書では定義しないが、HTTP の将来の拡張によって定義されるであろ う。適切なレスポンストを選択するために、フォーマッコンテントネゴシエ ーションを使われる *かもしれない*。もしレスポンスボディが含まれていな ければ、そのレスポンスは "0" というフィールド値を持つ Content-Length フィールドを含ま *なければならない*。 Max-Forwards リクエストヘッダフィールドは、リクエスト連鎖中で特定のプ ロクシを目標に使われるで *あろう*。プロクシは、転送が許可されたリクエ ストのための absoluteURI と共に OPTIONS リクエストを受けとった時に は、Max-Forwards フィールドをチェックし *なければならない*。もし、 Max-Forwards フィールドの値がゼロ("0") ならば、プロクシはそのメッセー ジを転送し *てはならない*。その代わりに、プロクシ自身のコミュニケーシ ョンオプションを返す *べきである*。もし、Max-Forwards フィールドの値 がゼロより大きな整数値ならば、プロクシはリクエストを転送する際にその 値を一つ減らさ *なければならない*。リクエストの中に Max-Forwards フィ ールドが存在していなければ、転送するリクエストに Max-Forwards フィー ルドを含め *てはならない*。 9.3 GET GET メソッドは、Request-URI で識別される (エンティティ形式の) 情報な らなんでも回収する事を意味する。もし、Request-URI がデータ生産プロセ ス{data-producing process} を参照するのであれば、それはレスポンスのエ ンティティとして返されるであろうとして生産されるデータであり、もしそ のテキストがプロセスの出力として生じるのでなければ、プロセスのソース テキストではない。 リクエストメッセージに If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range のいずれかのヘッダフィールドを含ん でいる場合、GET メソッドのセマンティクスは条件付き GET に変わる。条件 付き GET メソッドは、エンティティがその条件付きヘッダフィールドによっ て表される状況下でのみ転送されるようにリクエストする。条件付き GET メ ソッドは、キャッシュされるエンティティに複数のリクエストを要求する事 や、クライアントによってすでに保持されているデータを転送する事無く清 新できるようにする事で、不必要なネットワークの使用を減らそうというも のである。 リクエストメッセージに Range ヘッダフィールドを含んでいる場合、GET メ ソッドのセマンティクスは "部分的 GET" に変わる。部分的 GET は、 section 14.35 で示されるように、転送されるエンティティの一部のみを要 求する。部分的 GET メソッドは、クライアントによって既に保持されている データを転送する事無くエンティティを部分的に取得させ、完全なものにで きるようにする事で、不必要なネットワークの使用を減らそうというもので ある。 GET リクエストへのレスポンスは、section 13 に示されるような HTTP キャ ッシングのための必要条件がそろった場合にのみ、キャッシュ可能となる。 フォームを使った場合のセキュリティの考察については、section 15.1.3 を 見よ。 9.4 HEAD HEAD メソッドは、サーバがレスポンスにおいてメッセージボディを返し *て はならない* 事を除けば GET と同一である。HEAD リクエストへのレスポン スにおける HTTP ヘッダに含まれる外部情報は、GET リクエストへのレスポ ンスで送られる情報と同一である *べきである*。このメソッドは、エンティ ティボディ自身を転送する事なしにリクエストによって意味されるエンティ ティに付いての外部情報を得るために使用される。このメソッドは、ハイパ ーテキストリンクの正当性、アクセス可能性、最近の修正のテストのため に、しばしば使用される。 HEAD リクエストへのレスポンスは、そのレスポンスに含まれる情報はリソー スから前もってキャッシュされたエンティティを更新するために使う事が *できる* 、という意味でキャッシュ可能である *かもしれない*。もし、新 しいフィールド値がキャッシュされたエンティティは (Content-Length, Content-MD5, ETag, Last-Modified 各値の変更によって示されるように) 現 在のエンティティと違うという事を示すならば、キャッシュはそのキャッシ ュエンティティを新鮮でないものとして扱わ *なければならない*。 9.5 POST POST メソッドは、サーバがリクエストライン内の Request-URI により識別 されるリソースへの新しい従属{subordinate} として、リクエストに同封さ れるエンティティを受け入れる事を要求するために使用される。POST は以下 の機能のカバーするための画一的メソッドとして設計されている。 - 既存リソースの注釈 - 掲示板、ニュースグループ、メーリングリスト、あるいはその類の記事 グループへのメッセージの投稿 - フォーム提出の結果のような、データ処理プロセス {data-handling process} へのデータブロックの供給 - 追加動作を通したデータベースの拡張 POST メソッドによって実行される実際の機能はサーバによって決定され、通 常は Request-URI に依存する。ポストされたエンティティは、ファイルが ディレクトリに従属し、ニュース記事がそれがポストされたニュースグルー プに従属し、レコードがそのデータベースに従属しているという事と同じ形 で、その URI に従属する。 POST メソッドによって実行される動作は、URI によって識別されうるリソー スという結果にはならないかもしれない。この場合、200 (OK) か 204 (No Content) が適切なレスポンスステータスであり、それはレスポンスが結果を 記述したエンティティを含んでいるかどうかに依存する。 リソースがオリジンサーバで既に生成されている場合、レスポンスは 201 (Created) であり、リクエストのステータス、新しいリソースへの参照、 Location ヘッダ (section 14.30) を記述したエンティティを含む *べきで ある*。 レスポンスが適切な Cache-Control や Expires ヘッダフィールドを含んで いなければ、このメソッドのレスポンスはキャッシュ可能ではない。しかし ながら、303 (See Other) レスポンスは、ユーザエージェントにキャッシュ 可能なリソースの検索を指示するために使用される。 POST リクエストは、section 8.2 にあるメッセージ転送要求に従わ *なけれ ばならない*。 セキュリティの考察については、section 15.1.3 参照。 9.6 PUT PUT メソッドは、同封されたエンティティを供給される Request-URI の元に 保存するように要求する。Request-URI が既に存在するリソースを参照して いる場合は、同封されるエンティティはオリジンサーバにあるそれの修正版 とみなされる *べきである*。Request-URI が既存のリソースを指していない 場合に、その URI がリクエストしているユーザエージェントによって新しい リソースとして定義する事ができる時は、オリジンサーバはその URI にリソ ースを作成できる。新しいリソースが作成された場合、オリジンサーバは 201 (Created) レスポンスをもってユーザエージェントに知らせ *なければ ならない*。既存のリソースが更新された場合は、リクエストが成功し終了し た事を示すために 200 (OK) か 204 (No Content) のいずれかのレスポンス コードを送る *べきである*。もし、リソースがその Request-URI に作成、 あるいは更新されなかった時は、問題の本質を反映する適切なエラーレスポ ンスが与えられる *べきである*。エンティティを受ける側は、理解できなか ったり実装していないようないかなる Content-* ヘッダ (例えば Content-Range 等) も無視してはならず、そのような場合には 501 (Not Implemented) レスポンスを返さ *なければならない*。 リクエストがキャッシュを通り抜けたり、Request-URI が現在キャッシュさ れている一つ以上のエンティティを識別する場合、これらのエンティティは 新鮮でないものとして扱われる *べきである*。このメソッドのレスポンスは キャッシュできない。 リクエスト POST と PUT とでの根本的な違いは、Request-URI の意味の違い をもたらす。POST リクエストにおける URI は、同封されたエンティティを 処理するであろうリソースを識別する。リソースは、データ受諾プロセス {data-accepting process} か、ある別のプロトコルへのゲートウェイ、ある いは注釈を受け入れる分割されたエンティティであろう。それに対して、PUT リクエストにおける URI は、リクエストとともに同封されたエンティティを 識別する。しかし、ユーザエージェントがリソースにその URI を割り当てる つもりであっても、サーバはそのリクエストをある別のリソースへと割り当 てようとし *てはならない*。そのリクエストを別の URI に申しこむように 要求する時は、サーバは 301 (Moved Permanently) レスポンスを返さ *なけ ればならない*。この時、ユーザエージェントはそのリクエストをリダイレク トするかどうかに関して決める事が *できる*。 単一のリソースが、多くの異なった URI によって識別される *かもしれな い*。例えば、ある記事が各々のバージョンを識別する URI とは別に、"最新 のバージョン" を識別するための URI を持っているかもしれない。この場 合、一般の URI への PUT リクエストは、オリジンサーバによって定義され ているいくつかの他の URI へと行われるはずである。 HTTP/1.1 では、PUT メソッドがオリジンサーバの状態にどのように影響を及 ぼすかは定義しない。 PUT リクエストは、section 8.2 にあるメッセージ転送要求に従わ *なけれ ばならない*。 特定のエンティティヘッダが別の方法では指定できない場合、PUT リクエス トにおけるエンティティヘッダは、PUT によって作成、あるいは修正された リソースに適用される *べきである*。 9.7 DELETE DELETE メソッドは、オリジンサーバが Request-URI により識別されるリソ ースを削除する事を要求する。このメソッドは、オリジンサーバにおいて人 間の手 (あるいは別の方法) によって上書きされている *かもしれない*。例 えオリジンサーバから返されたステータスコードは動作がうまく完了したと いう事を示していたとしても、クライアントはその操作が実行された事は保 証されない。しかしそのレスポンスが与えられた場合に、サーバがそのリソ ースを削除したり、アクセスできない場所へ移動したりしようとしていない のであれば、成功を示す *べきではない*。 成功したレスポンスは、もしレスポンスがステータスで表しているエンティ ティを含んでいるなら 200 (OK)、もし動作がまだ行われていないなら 202 (Accepted)、もし動作は行われたが、レスポンスにエンティティを含んでい ないなら 204 (No Content) である *べきである*。 もし、リクエストがキャッシュを通り抜けたり、Request-URI が現在キャッ シュされている一つ以上のエンティティとして識別されるなら、これらのエ ンティティは新鮮でないものとして扱われる *べきである*。このメソッドの レスポンスはキャッシュできない。 9.8 TRACE TRACE メソッドは、リクエストメッセージのアプリケーション層のループバ ックを遠隔的に発動するために使用される。リクエストの最後の受信者は、 200 (OK) レスポンスのエンティティボディとして、そのメッセージをクライ アントにそのまま送り返す *べきである*。最後の受信者とは、オリジンサー バ、もしくはリクエストで Max-Forwards (section 14.31) 値がゼロ (0) で あったものを受け取った最初のプロクシかゲートウェイである。TRACE リク エストはエンティティを含ん *ではならない*。 TRACE を使って、クライアントはリクエスト連鎖の反対側では何が受け取ら れているのかを見る事や、テストや診断情報のためのデータを使用する事が できる。これはリクエスト連鎖のトレースとして動作するので、Via ヘッダ フィールド (section 14.45) の値が特に重要である。Max-Forwards ヘッダ フィールドを使用する事で、クライアントにリクエスト連鎖の大きさに制限 を与える事ができ、これは無限ループ上でメッセージを転送するプロクシ連 鎖をテストするために有用である。 もしリクエストが妥当ならば、レスポンスは "message/http" という Content-Type と一緒に、エンティティボディとしてリクエストメッセージの 全体を含む *べきである*。このメソッドのレスポンスはキャッシュされ *て はならない*。 9.9 CONNECT この仕様書では、(例えば SSLトンネリング [44] 等の) トンネルとなるよう に動的に切り換える事ができるプロクシが使用する時のために CONNECT とい うメソッド名を予約する。 10 ステータスコード定義 各々のステータスコードについて、レスポンス時に後に従える事のできるメ ソッドと必要とされるすべての外部情報の記述と共に、以下に記述する。 10.1 Informational 1xx このステータスコードのクラスは一時的なレスポンスを示し、ステータスラ インとオプション的なヘッダからのみなり、空行で終了する。このステータ スコードのクラスのための必要なリクエストヘッダは無い。HTTP/1.0 では、 どんな 1xx ステータスコードも定義していないので、サーバは実験的な状況 下以外では HTTP/1.0 クライアントに 1xx レスポンスを送っ *てはならな い*。 クライアントは、例え 100 (Continue) ステータスメッセージを期待してい なかったとしても、通常のレスポンスの前の一つ以上の 1xx レスポンスを受 け入れるよう準備されてい *なければならない*。ユーザエージェントは、期 待していない 1xx レスポンスを無視する事が *できる*。 プロクシは、もしプロクシとクライアント間の接続が切断されている、ある いはプロクシ自身が 1xx レスポンスの生成を要求したという場合以外は、 1xx レスポンスを転送しなければならない。 (例えば、プロクシがリクエス トを転送する時に "Expect: 100-continue" というフィールドを付け加えた 時には、それに相当する 100 (Continue) レスポンスを転送する必要はな い。) 10.1.1 100 Continue クライアントは、そのリクエストを続ける *べきである*。この暫定的レスポ ンスは、リクエストの始めの部分は受け取られ、サーバによって拒否された ものではないという事をクライアントに知らせるために使用される。クライ アントは、リクエストの残りを送り続けるか、もし既にリクエストが完了し ていれば、このレスポンスを無視す *べきである*。サーバは、リクエストが 完了した後に最終的なレスポンスを送ら *なければならない*。このステータ スコードの使用・処理の詳細な議論のために section 8.2.3 参照。 10.1.2 101 Switching Protocols サーバは理解し、Upgrade メッセージヘッダフィールド (section 14.42) を 使って、この接続で使用されているアプリケーションプロトコルを変更する 事でクライアントのリクエストに従おうとしている。サーバは 101 レスポン スを終了する空行のあと、すぐにレスポンスの Upgrade ヘッダフィールドに よって定義されたプロトコルに変更するだろう。 プロトコルは、変更した方が有益な場合にのみ変更される *べきである*。例 えば、HTTP のより新しいバージョンに変更するという事は、古いバージョン 以上に有益だし、リアルタイムに、同期するプロトコルを変更する事はその ような機能を使うリソースを配布するときに都合が良いだろう。 10.2 Successful 2xx このステータスコードのクラスは、クライアントのリクエストがうまく受信 され、理解され、そして受け入れられた事を示す。 10.2.1 200 OK リクエストは成功した。レスポンスと共に返される情報はリクエストに使用 されたメソッドに依存し、例えば以下の様になる。 GET リクエストされたリソースに対応するエンティティがレスポンスとし て送られる。 HEAD リクエストされたリソースに対応するエンティティヘッダフィールド がメッセージボディを伴わずにレスポンスとして送信される。 POST 動作の結果を記述もしくは含んでいるエンティティ TRACE 端末サーバによって受信されたリクエストメッセージを含んでいるエ ンティティ 10.2.2 201 Created リクエストは果たされ、結果として新しいリソースが作成された。新しく作 成されたリソースは Location ヘッダにより与えられるリソースに対する最 も明確な URI を伴って、レスポンスのエンティティにおいて返される URI によって参照される。レスポンスは、ユーザあるいはユーザエージェントが 最も適切なものを選択するために、リソースの特徴と場所のリストをエンテ ィティとして含む *べきである*。エンティティのフォーマットは、 Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定 される。オリジンサーバは、201 ステータスコードを返す前にリソースを作 成し *なければならない*。もし動作がすぐに実行できないのであれば、サー バは代わりに 202 (Accepted) レスポンスを返す *べきである*。 201 レスポンスは、作成されたばかりのリクエストされたバリアントのため に、現在のエンティティタグの値を示す ETag レスポンスヘッダフィールド を含む事が *できる*。section 14.19 参照。 10.2.3 202 Accepted リクエストは処理のために受け入れられたが、処理は完了されていない。こ のリクエストは、実際に処理される時に拒否されるかもしれないので、最終 的に動作されるかどうかは不明である。このような非同期操作からステータ スコードを再送信するための機能は存在しない。 202 レスポンスは、意図的に責任を持たない{non-committal}。これはサーバ が、プロセスが完了されるまでユーザエージェントとの接続を持続させる事 無く、他のいくつかのプロセス (多分一日に一度しか実行されないバッチ志 向プロセス{batch-oriented process}) のためのリクエストを受け入れる事 を可能にするという目的を持つ。このレスポンスによって返されるエンティ ティは、リクエストの現在の状態を表すものと、状態モニタへのポインタ、 あるいはそのリクエストがいつ果たされるかをユーザが予期できる見積もり のどちらかを含む *べきである*。 10.2.4 203 Non-Authoritative Information エンティティヘッダにおいて返された外部情報は、オリジンサーバから利用 できるような決定的なセットではなく、ローカルもしくはサードパーティコ ピーから集められたものである。提示されたセットは元のバージョンのサブ セットかスーパーセットで *あろう*。例えば、リソースについてのローカル な注釈情報を含む事はオリジンサーバによって知らされる外部情報のスーパ ーセットとなるかもしれない。そのレスポンスが 200 (OK) とは別の方法で 示したい場合、このレスポンスコードを使用する必要はないが、そのような 場合にのみ適切である。 10.2.5 204 No Content サーバはリクエストを受け入れたが、エンティティボディを送り返す必要は 無く、更新された外部情報を返す事を望むだろう。レスポンスは、エンティ ティヘッダ形式の中に、新規あるいは更新された外部情報を含む事が *でき*、もしあればリクエストされたバリアントが関連付けられる *べきで ある*。 もしクライアントがユーザエージェントなら、リクエストの送信をもたらし た状態からその文書画面{view} を変える *べきではない*。このレスポンス は主に、ユーザエージェントの現在の{active} 文書画面を変える事無く、動 作を起こすための入力をさせる意図を持つが、どんな新規あるいは更新され た外部情報もユーザエージェントの現在の画面中にある現在の文書に適用さ れる *べきである*。 204 レスポンスは メッセージボディを含ん *ではならない* ので、常にヘッ ダフィールドの後の最初の空行で終了する。 10.2.6 205 Reset Content サーバはリクエストを受け入れたので、ユーザエージェントは送信されたリ クエストをもたらした現在の画面をリセットす *べきである*。このレスポン スは主に、ユーザが別の入力動作を簡単に始められるように、入力が与えら れたフォームをクリアして、ユーザの入力経由で動作を起こすための入力を させる意図を持つ。レスポンスはエンティティを含ん *ではならない*。 10.2.7 206 Partial Content サーバはリソースに対する部分的 GET リクエストを受け入れた。リクエスト は、望む範囲を示すための Range ヘッダフィールド (section 14.35) を含 め *なければならない* し、またリクエストを条件付きにしたいければ If- Range ヘッダフィールド (section 14.27) を含んだ方が *よい*。 レスポンスは、以下のヘッダフィールドを含め *なければならない*。 - このレスポンスに含まれる範囲を示す Content-Range ヘッダフィール ド (section 14.16) か、それぞれの部分に Content-Range フィールド を含む multipart/byteranges という Content-Type のどちらか。この レスポンスにて Content-Length ヘッダフィールドが送られた場合、そ の値はメッセージボディで転送される OCTET の実際の数と一致し *な ければならない*。 - Date - もしそのヘッダが、同じリクエストに対して 200 レスポンス を返すで あろう場合は ETag, Content-Location のうち一つ以上 - もしフィールド値が、同じバリアントのための以前のレスポンスで送ら れたものと異なるならば、Expires, Cache-Control, Vary のうち一つ 以上 もし 206 レスポンスが、強いキャッシュバリディタ (section 13.3.3 参照) を使った If-Range リクエストの結果ならば、レスポンスは他のエンティテ ィヘッダを含める *べきではない*。もし、レスポンスが弱いバリディタを使 った If-Range リクエストの結果がとしたら、レスポンスは他のエンティテ ィヘッダを含め *てはならない*。これはキャッシュされたエンティティボデ ィと更新されたエンティティヘッダとの不一致を避ける為である。そうで無 ければ、レスポンスは同じリクエストに対して 200 (OK) レスポンスと共に 返されたであろうすべてのエンティティヘッダを含め *なければならない*。 もし ETag か Last-Modified ヘッダが正確に一致しなければ、キャッシュは 他の以前キャッシュされた要素と 206 レスポンスとを結びつけ *てはならな い*。section 13.5.4 参照。 Range や Content-Range ヘッダをサポートしていないキャッシュは、206 (Partial) レスポンスをキャッシュし *てはならない*。 10.3 Redirection 3xx このステータスコードのクラスは、リクエストを果たすためにはユーザエー ジェントによって更なる動作が行われる必要がある事を示す。二番目のリク エストで使われたメソッドが GET か HEAD である場合にのみ、ユーザとの相 互動作無しに、ユーザエージェントによって要求された動作を実行する事が *できる*。リダイレクションループによって各々のリダイレクションはネッ トワーク渋滞を生み出す事になるので、クライアントは無限リダイレクショ ンループを発見す *べきである*。 注意: この仕様書の前のバージョンでは、5 回のリダイレクションを最大 として推奨している。内容開発者{Content developers} は、そのような 修正された制限を実装したクライアントがあるであろう事を意識すべきで ある。 10.3.1 300 Multiple Choices リクエストされたリソースは、表現セットの一つに対応し、各々が特有の場 所にあり、エージェント駆動型ネゴシエーション情報 (section 12) が、ユ ーザ (あるいはユーザエージェント) が望む表現を選択でき、その位置にリ クエストをリダイレクトできるように供給されている。 もし HEAD リクエストでなければ、レスポンスはエンティティにユーザかユ ーザエージェントが最も適切なものを選択するためのリソースの特徴と場所 のリストを含む *べきである*。エンティティのフォーマットは、Content- Type ヘッダフィールドにて与えられるメディアタイプによって指定される。 データフォーマットやユーザエージェントの能力に依存する事なので、最も 適切な選択は自動的に行われる *かもしれない*。しかし、この仕様書ではそ のような自動選択に対してどのような標準も定義しない。 サーバが選択された表現を持っているのであれば、Location フィールド内に その表現のための具体的な URI を含む *べきである*。ユーザエージェント は、自動リダイレクションのためにその Location フィールドの値を使うこ とが *できる*。このレスポンスは、別のものを示しているのでなければキャ ッシュ可能である。 10.3.2 301 Moved Permanently リクエストされたリソースは新しい恒久的な URI に割り当てられたので、以 降そのリソースへの参照は返された URI の一つを使用す *べきである*。リ ンク編集機能を持つクライアントは、可能であればサーバにより返された新 しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべ きである。このレスポンスは、別のものを示しているのでなければキャッシ ュ可能である。 新しい恒久的 URI は、レスポンス内の Location フィールドによって与えら れる *べきである*。リクエストメソッドが HEAD でなければ、レスポンスの エンティティは新しい URI へのハイパーリンクを持った短いハイパーテキス トの注釈を含む *べきである*。 もし 301 ステータスコードが GET や HEAD 以外のリクエストのレスポンス として受信されたら、リクエストが発行された時点の条件から変わっている かもしれないため、ユーザエージェントはユーザに確認せずに、リクエスト を自動的にリダイレクトし *てはならない*。 注意: 301 ステータスコードを受信した後 POST リクエストを自動的にリ ダイレクトする時、既存の HTTP/1.0 ユーザエージェントの中には誤って それを GET リクエストに変えるものがある。 10.3.3 302 Found リクエストされたリソースは、一時的に別の URI に属している。このリダイ レクションは場合によって変更されるかもしれないので、クライアントは将 来のリクエストではその Request-URI を使い続ける *べきである*。このレ スポンスは Cache-Control か Expires のどちらかのヘッダフィールドによ って期限が示されている場合にのみキャッシュ可能である。 一時的 URI は、レスポンス内の Location フィールドによって与えられる *べきである*。リクエストメソッドが HEAD でなければ、レスポンスのエン ティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの 注釈を含む *べきである*。 もし 302 ステータスコードが GET や HEAD 以外のリクエストのレスポンス として受信されたら、リクエストが発行された時点の条件から変わっている かもしれないため、ユーザエージェントはユーザに確認せずに、リクエスト を自動的にリダイレクトし *てはならない*。 注意: RFC 1945 や RFC 2068 では、クライアントはリダイレクトするリ クエストのメソッドを変えてはならないと明確に述べられている。しかし ながら、多くの既存ユーザエージェントは 302 レスポンスをまるで 303 レスポンスのようにみなし、元々のリクエストメソッドにかかわらず Location フィールド値へと GET を行う。ステータスコード 303 と 307 は、クライアントが期待する反応の種類を明確にしたいというサーバのた めに加えられた。 10.3.4 303 See Other リクエストに対するレスポンスは別の URI の元から発見でき、このリソース を GET メソッドを使用して回収す *べきである*。このメソッドは、主に POST によって活性化される {POST-activated} スクリプトの出力が選択され たリソースへユーザエージェントをリダイレクトできるようにするために存 在する。新しい URI は元々リクエストされたリソースに対する代わりの参照 ではない。303 レスポンスはキャッシュ可能し *てはならない* が、二番目 の (リダイレクトされた) リクエストへのレスポンスはキャッシュ可能であ る。 異なる URI は、レスポンス内の Location フィールドによって与えられる *べきである*。リクエストメソッドが HEAD でなければ、レスポンスのエン ティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの 注釈を含む *べきである*。 注意: 多くの HTTP/1.1 以前のユーザエージェントは 303 ステータスを 理解できない。そのようなクライアントと相互通信する時、ほとんどのユ ーザエージェントは 302 レスポンスを 303 レスポンスのように扱うの で、302 レスポンスコードが代わりに使われるであろう。 10.3.5 304 Not Modified クライアントが条件付き GET リクエストを実行し、アクセスは許可されたが その文書は更新されていなかった場合、サーバはこのステータスコードもっ て応答す *べきである*。304 レスポンスはレスポンスボディを含ん *ではな らない* ので、いつもヘッダフィールドの後の最初の空行で終了する。 レスポンスは以下のヘッダフィールドを含ま *なければならない*。 - その省略が section 14.18.1 によって要求されていなければ、Date 時計の無いオリジンサーバがこのルールに従っている場合、プロクシやクラ イアントは ([RFC 2068] の section 14.19 にて既に記されているように) 受信した Date ヘッダを持たないいかなるレスポンスにも自身の Date を付 け加える事で、キャッシュは正常に作動するであろう。 - もしそのヘッダが、同じリクエストに対して 200 レスポンス を返すで あろう場合は ETag, Content-Location のうち一つ以上 - もしフィールド値が、同じバリアントのための以前のレスポンスで送ら れたものと異なるならば、Expires, Cache-Control, Vary のうち一つ 以上 条件付き GET に、強いキャッシュバリディタ (section 13.3.3 参照) を使 う場合、レスポンスは他のエンティティヘッダを含める *べきではない*。そ うでない (例えば条件付き GET が弱いバリディタを使う) 場合、レスポンス は他のエンティティヘッダを含め *てはならない*。これは、キャッシュされ たエンティティボディと更新されたエンティティヘッダとの不一致を避ける 為である。 304 レスポンスが現在キャッシュされていないエンティティを示すならば、 キャッシュはレスポンスを無視し、条件なしのリクエストを反復しなければ *ならない*。 キャッシュが受信された 304 レスポンスをキャッシュエントリを更新するた めに使用する場合、キャッシュはレスポンスで与えられたあらゆる新しいフ ィールド値をも反映させるため、エントリを更新し *なければならない*。 10.3.6 305 Use Proxy リクエストされたリソースは Location フィールドによって与えられるプロ クシを通してアクセスされ *なければならない*。Location フィールドはプ ロクシの URI を与える。受信側はプロクシ経由で単一のリクエストを再送信 する事を期待する。305 レスポンスはオリジンサーバによってのみ生成され *なければならない*。 注意: RFC 2068 では、305 は単一リクエストをリダイレクトさせようと する事、またオリジンサーバによってのみ生成される事は明確にしていな い。これらの制限がセキュリティの上で重要な意味を持つという事を認識 していなかったためである。 10.3.7 306 (Unused) 306 ステータスコードは前のバージョンの仕様書では使われていたが、もは や使われておらず、将来のために予約されている。 10.3.8 307 Temporary Redirect リクエストされたリソースは、一時的に別の URI に属している。このリダイ レクションは場合によって変更されるかもしれないので、クライアントは将 来のリクエストではその Request-URI を使い続ける *べきである*。このレ スポンスは Cache-Control か Expires のどちらかのヘッダフィールドによ って期限が示されている場合にのみキャッシュ可能である。 一時的 URI は、レスポンス内の Location フィールドによって与えられる *べきである*。多くの HTTP/1.1 以前のユーザエージェントは 307 ステータ スを理解できないので、リクエストメソッドが HEAD でなければ、レスポン スのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテ キストの注釈を含む *べきである*。それゆえ、その注釈にはユーザが新しい URI に元々のリクエストを繰り返すのに必要な情報を含む *べきである*。 もし 302 ステータスコードが GET や HEAD 以外のリクエストのレスポンス として受信されたら、リクエストが発行された時点の条件から変わっている かもしれないため、ユーザエージェントはユーザに確認せずに、リクエスト を自動的にリダイレクトし *てはならない*。 10.4 Client Error 4xx ステータスコードの 4xx クラスは、クライアントが間違えているような場合 を示す。HEAD リクエストへのレスポンスを除き、サーバはエラー状況が一時 的か恒久的かに拘わらず、エラー状況の説明を含むエンティティを返す *べ きである*。これらのステータスコードは、あらゆるリクエストメソッドに適 用されうる。ユーザエージェントは、含まれるエンティティすべてをユーザ に表示す *べきである*。 もしクライアントがデータを送信している最中ならば、TCP を使用している サーバインプリメンテーションは、サーバが入力接続を切断する前に、レス ポンスを含んでいるパケットの受領をクライアントが認識できる事を保証す るために気を配る *べきである*。もし切断後にもクライアントがサーバにデ ータを送信し続けていたら、サーバの TCP スタックはクライアントにリセッ トパケットを送り、これによって、HTTP アプリケーションがリクエストを読 み出して中間処理する前に、クライアントの認識されない入力バッファを消 去するだろう。 10.4.1 400 Bad Request リクエストは、不正なシンタックスのためサーバに理解されなかった。クラ イアントは、修正しないままでそのリクエストを再送信す *べきではない*。 10.4.2 401 Unauthorized リクエストはユーザ認証を必要とする。レスポンスは、リクエストされたリ ソースに適用できる challenge を含む WWW-Authenticate ヘッダフィールド (section 14.47) を含ま *なければならない*。クライアントは、適切な Authorization ヘッダフィールド (section 14.8) を伴うリクエストを繰り 返す事が *できる*。もしリクエストがすでに Authorization credentials を含んでいるのであれば、この 401 レスポンスは認証がそれらの credentials に対して拒否された事を示す。もし 401 レスポンスが前のレス ポンス時と同じ challenge を含み、ユーザエージェントが既に最低一回認証 を試みているならば、そのエンティティに関連する診断情報を含んでいるで あろうから、ユーザエージェントはレスポンスで与えられたエンティティを 表示す *べきである*。HTTP アクセス認証は、"HTTP Authentication: Basic and Digest Access Authentication" において説明されている。 10.4.3 402 Payment Required このコードは、将来の使用のため予約されている。 10.4.4 403 Forbidden サーバはリクエストを理解したが、それを実行する事を拒否した。認証は役 に立たないであろうから、リクエストは繰り返される *べきではない*。リク エストメソッドが HEAD で無い時に、サーバはなぜリクエストが実行されな かったかを公にしたいならば、エンティティにおいて拒否の理由を記す *べ きである*。サーバはこの情報をクライアントに利用されたくないならば、ス テータスコードとして 404 (Not Found) を代わりに使う事ができる。 10.4.5 404 Not Found サーバが、Request-URI に一致するものを見つけられなかった。その状態が 一時的か恒久的かに拘わらず、与えられる指示はない。もしサーバが、ある 内部に組み込まれているメカニズムを通して、古いリソースが恒久的に利用 できず、それを転送するためのアドレスも無いという事を知っていたら、410 (Gone) ステータスコードが使用される *べきである*。このステータスコー ドは一般に、サーバが何故リクエストが拒否したかを正確には表したく無い 時、あるいは他に適切なレスポンスが無い時に使われる。 10.4.6 405 Method Not Allowed リクエストラインに記述されたメソッドは、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) と似ているが、クライアントが最初にプ ロクシに認証されなければならない事を示す。プロクシは、リクエストされ たリソースのためのプロクシに適用できる challenge を含んだ Proxy- Authenticate ヘッダフィールド (section 14.33) を返さ *なければならな い*。クライアントは、適切な Proxy-Authorization ヘッダフィールド (section 14.34) を伴うリクエストを繰り返す事ができる。HTTP アクセス認 証は、"HTTP Authentication: Basic and Digest Access Authentication" [43] において説明されている。 10.4.9 408 Request Timeout クライアントは、サーバの待ち時間内にリクエストを発行しなかった。クラ イアントは、それ以降に修正しないでリクエストを繰り返しても *よい*。 10.4.10 409 Conflict リクエストは、リソースの現在の状態との矛盾のため完了できなかった。こ のコードは、ユーザが矛盾を解決し、リクエストを再提出できる事が期待で きる状況のみに許される。レスポンスボディには、ユーザが矛盾の原因を認 識するための十分な情報を含む *べきである*。理論的には、そのレスポンス エンティティはユーザやユーザエージェントが問題を修正するための十分な 情報を含んでいるであろうが、実際それは不可能だろうしその必要もない。 矛盾は、PUT リクエストへのレスポンス時に最も発生しやすい。例えば、も しバージョン処理{versioning} が使用され、PUT されているエンティティが 初期 (サードパーティ) のリクエストによって作られたものと矛盾している リソースに変わるものを含んでいるならば、サーバはリクエストが完了でき ない事を示す 409 レスポンスを使用できる。この場合、レスポンスエンティ ティにはおそらく、レスポンスの Content-Type によって定義されるフォー マット中で二つのバージョンの違いについてのリストを含むであろう。 10.4.11 410 Gone リクエストされたリソースは、もはやそのサーバでは利用できないし、転送 先のアドレスも分からない。この状況は、恒久的なものとみなされるであろ う。リンク編集機能を持つクライアントは、ユーザから承認を得た後に Request-URI の参照を削除す *べきである*。サーバがその状況が恒久的なも のかどうかを、知らないか、あるいはそれを決定するための能力が無いので あれば、代わりにステータスコード 404 (Not Found) が使用される *べき である*。別の方法が示されなければ、このレスポンスはキャッシュできる。 410 レスポンスは主に、リソースが故意に利用不可能であったり、サーバの オーナーがリソースへのリモートリンクを削除したい事を受信者に通知する 事でウェブメンテナンスの作業を補助する意図を持つ。そのような事は、期 間限定の宣伝サービスや、サーバのサイト内でもはや働いていない個人が所 有していたリソースに対して一般的である。"無くなった{gone}" ような恒久 的に利用できないすべてのリソースをマークしたり、いつまでもそのマーク を維持しておく必要はないが、これをいつ破棄するかはサーバオーナーの判 断にまかされる。 10.4.12 411 Length Required サーバは、定義された Content-Length の無いリクエストを受け入れる事を 拒否した。リクエストメッセージにメッセージボディの長さを含んでいる妥 当な Content-Length ヘッダフィールドを追加すれば、クライアントはリク エストを繰り返す事が *できる*。 10.4.13 412 Precondition Failed 一つ以上のリクエストヘッダフィールドで与えられた前提条件は、それがサ ーバでテストされたときに偽であると評価された。このレスポンスコードは クライアントが現在のリソースの外部情報 (ヘッダフィールドデータ) を前 提条件として置けるようにし、それによってリクエストされたメソッドを目 的以外のリソースに適用されないようにする。 10.4.14 413 Request Entity Too Large リクエストエンティティがサーバが想定、あるいは処理可能なものより大き いため、サーバはリクエストの処理を拒否している。サーバは、クライアン トにリクエストを続けさせないため接続を閉じて *よい*。 もしその状態が一時的なものであれば、サーバはそれが一時的であるという 事と、クライアントが再試行しても *よい* 経過時間を示す Retry-After ヘ ッダフィールドを含む *べきである*。 10.4.15 414 Request-URI Too Long サーバが中間処理をするために想定している Request-URI より長いため、サ ーバはリクエストのサービスを拒否している。このまれな状態は、クライア ントが長いクエリ情報を伴った POST リクエストを GET リクエストに不適当 に変換した時、クライアントがリダイレクションの URI "ブラックホール" (例えば、リダイレクトされた URI が自身の末尾を指すようなものを自身の 前に置いてしまうような状態) に陥った時、あるいはサーバが Request-URI の読み出しや操作のために固定長バッファを使用しているいくつかのサーバ に存在する当面のセキュリティホールを利用しようとしているクライアント からアタックを受けている時にのみ起こる傾向がある。 10.4.16 415 Unsupported Media Type リクエストのエンティティは、リクエストされたメソッドに対してリクエス トされたリソースがサポートしていないフォーマットであるため、サーバは リクエストのサービスを拒否している。 10.4.17 416 Requested Range Not Satisfiable リクエストが Range ヘッダフィールド (section 14.35) を含み、このフィ ールドの範囲指定値が選ばれたリソースの現在の範囲に重なっていなくて、 リクエストに If-Range リクエストヘッダフィールドを含んでいなかった ら、サーバはこのステータスコードを含むレスポンスを返す *べきである*。 (バイトレンジの場合、これはすべての byte-range-spec 値での first- bytes-pos が、現在選択されているリソースの長さを超えている事を意味す る。) このステータスコードをバイトレンジのリクエストで返す場合、レスポンス には選ばれたリソースの現在のサイズを特定するために Content-Range ヘッ ダフィールドを含む *べきである* (section 14.16 参照)。このレスポンス は、コンテントタイプが multipart/byteranges のものに使用し *てはなら ない*。 10.4.18 417 Expectation Failed Expect リクエストヘッダフィールド (section 14.20 参照) によって与えら れるこの拡張は、このサーバでは受け入れる事はできないし、あるいはサー バがプロクシであったなら、次に到達するサーバがそのリクエストを受け入 れる事ができないという明白な証拠を持っている。 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 ゲートウェイやプロクシとして動作するサーバは、URI によって特定される アップストリームサーバ (例えば HTTP, FTP, LDAP) や、リクエストを完了 させようとするためにアクセスに必要な他の補助のサーバ (例えば DNS) か ら適時のレスポンスを受信しなかった。 注意: 実装者向け: 設置されたプロクシの中には、DNS lookup がタイム アウトした時に 400 あるいは 500 を返すものがあるという事が知られて いる。 10.5.6 505 HTTP Version Not Supported サーバは、リクエストメッセージで使用された HTTP プロトコルバージョン をサポートしていない、あるいはサポートを拒否している。サーバは、この エラーメッセージ以外は、section 3.1 で表されるように、クライアントと 同じメジャーバージョンを使用してリクエストを完了させる事は不可能、 あ るいはそれを望んでいないという事を示している。レスポンスは、何故この バージョンがサポートされていないか、どんな別のプロトコルがこのサーバ によってサポートされているかを記述したエンティティを含む *べきであ る*。