HTTP 意味論（ § 7 〜 § 15 ）

7.3.1. ~cacheへの~route法

`~client$が`~cache$ `CACHING$r を備えていて, かつ それにより要請を満足できる場合、 要請は，通例的に，最初にそこへ~directされる。 ◎ If the client has a cache [CACHING] and the request can be satisfied by it, then the request is usually directed there first.

7.3.2. ~proxyへの~route法

代表的な`~client$は、［ 要請が`~cache$により満足できない ］場合に［ 要請を満足するために利用される`~proxy$があるかどうか ］を決定するため，自身の環境設定を検査することになる。 ~proxy環境設定は、 実装に依存するが，［ ~URI接頭辞の照合, 選択的な権限の照合, または この両者 ］に基づくことが多く、 ~proxy自身は，通例的に［ "`http$c" ／ "`https$c" ］~URIにより識別される。 ◎ If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI.

適用-可能な［ "`http$c" ／ "`https$c" ］`~proxy$がある場合、 `~client$は，［ その~proxyへの接続を確立する（または再利用する） ］ことにより`内方$へ接続してから［ `~client$の`~target~URI$に合致する`要請~target$ ］を包含している~HTTP要請~messageをそこへ送信する。 ◎ If an "http" or "https" proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy and then sending it an HTTP request message containing a request target that matches the client's target URI.

7.3.3. 生成元への~route法

適用-可能な`~proxy$は無い場合、 代表的な`~client$は，［ 当の識別された資源への~accessを得するために， （`~target~URI$の`~scheme$に特有な）~handler~routineを呼出す ］ことになる。 これが どう成遂げられるかは、 `~target~URI$の`~scheme$に依存し，それを~~規定する仕様により定義される。 ◎ If no proxy is applicable, a typical client will invoke a handler routine (specific to the target URI's scheme) to obtain access to the identified resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification.

`4.3.2§ は、 "`http$c" 資源への~accessを得する方法を定義する — 識別された`生成元~server$に向けて`内方$への接続を確立-（または再利用-）してから，［ `~client$の`~target~URI$に合致する`要請~target$ ］を包含している~HTTP要請~messageをそこへ送信することにより。 ◎ Section 4.3.2 defines how to obtain access to an "http" resource by establishing (or reusing) an inbound connection to the identified origin server and then sending it an HTTP request message containing a request target that matches the client's target URI.

`4.3.3§ は、 "`https$c" 資源への~accessを得する方法を定義する — ［ 識別された`生成元$に対し権限的な`生成元~server$ ］に向けて`内方$への`~secure化$された接続を確立-（または再利用-）してから，［ `~client$の`~target~URI$に合致する`要請~target$ ］を包含している~HTTP要請~messageをそこへ送信することにより。 ◎ Section 4.3.3 defines how to obtain access to an "https" resource by establishing (or reusing) an inbound secured connection to an origin server that is authoritative for the identified origin and then sending it an HTTP request message containing a request target that matches the client's target URI.

7.6.1. `Connection^h

`Connection^h ~headerは、［ 現在の接続に欲される制御~option ］を~listすることを，`送信者$に許容する。 ◎ The "Connection" header field allows the sender to list desired control options for the current connection.

`Connection@p
	= #`connection-option$p
`connection-option@p
	= `token$p

`connection-option$p が各 `接続~option@ （ `connection options^en ）を与える。 それらは、 文字大小無視である。 ◎ Connection options are case-insensitive.

`送信者$は、［ `Connection^h 以外の`~field$ ］を［ 現在の接続［ 用／について ］の制御~情報を給する ］ために利用するときは，対応する`~field名$を `Connection^h ~headerの中に~listしなければナラナイ。 ~HTTPの一部の~versionは、 そのような情報~用の~fieldの利用を禁制する — したがって， `Connection^h ~fieldを許容しない — ことに注意。 ◎ When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field name within the Connection header field. Note that some versions of HTTP prohibit the use of fields for such information, and therefore do not allow the Connection field.

すなわち， `Connection^h ~headerは、［ 直近の`受信者$のみに意図された（`隣点間$）`~field$ ］と［ `連鎖$上にある すべての`受信者$に意図された（`端点間$）`~field$ ］とを判別できるようにする，宣言的な仕方を供する — それは、 ~messageを`自己-記述的$にすることで，［ 接続ごとに特有な，将来の拡張 ］を［ 旧い`媒介者$により盲目的に回送されるおそれ ］なく配備することを許容する。 ◎ Hence, the Connection header field provides a declarative way of distinguishing fields that are only intended for the immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they will be blindly forwarded by older intermediaries.

さらに，`媒介者$は、［ 回送する前に除去が要求される ］ことが既知な各~fieldを， ~fieldの意味論を適用した後に［ 除去するか置換する ］ベキである — ~field名が `connection-option$p として出現したかどうかを問わず。 次に挙げる~fieldは，これに含まれるが、 この限りでない ⇒＃ `Proxy-Connection$h `HTTP/1.1$r, `Keep-Alive$h `2068/19.7.1$rfc, `TE$h, `Transfer-Encoding$h `HTTP/1.1$r, `Upgrade$h ◎ Furthermore, intermediaries SHOULD remove or replace fields that are known to require removal before forwarding, whether or not they appear as a connection-option, after applying those fields' semantics. This includes but is not limited to: • Proxy-Connection (Appendix C.2.2 of [HTTP/1.1]) • Keep-Alive (Section 19.7.1 of [RFC2068]) • TE (Section 10.1.4) • Transfer-Encoding (Section 6.1 of [HTTP/1.1]) • Upgrade (Section 7.8)

`送信者$は、 `接続~option$として［ `内容$を受け取るすべての`受信者$向けに意図された`~field$ ］に対応するものは，送信してはナラナイ。 例えば， `Cache-Control$h は、 接続~optionとしては，決して適切にならない。 ◎ A sender MUST NOT send a connection option corresponding to a field that is intended for all recipients of the content. For example, Cache-Control is never appropriate as a connection option (Section 5.2 of [CACHING]).

`接続~option$は、 常に［ ~message内に在る`~field$ ］に対応するとは限らない — 結付けられる~parameterが無い接続~optionに対しては、［ 接続ごとに特有な`~field$ ］は不要になり得るので。 対照的に，［ 対応する接続~optionを伴わずに受信した，接続ごとに特有な~field ］は、 通例的に［ 当の~fieldは`媒介者$により不適正に回送された ］ことを指示するので，`受信者$は無視する~OUGHT。 ◎ Connection options do not always correspond to a field present in the message, since a connection-specific field might not be needed if there are no parameters associated with a connection option. In contrast, a connection-specific field received without a corresponding connection option usually indicates that the field has been improperly forwarded by an intermediary and ought to be ignored by the recipient.

仕様~策定者は，~field【登録-済みな~field名】に対応しない新たな`接続~option$を定義するときは、 今後の衝突を避けるべく，対応する`~field名$を予約する~OUGHT。 そのように予約された~field名は、 `~HTTP~field名~registry^cite（ `16.3.1§ ）に登録される。 ◎ When defining a new connection option that does not correspond to a field, specification authors ought to reserve the corresponding field name anyway in order to avoid later collisions. Such reserved field names are registered in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (Section 16.3.1).

7.6.2. `Max-Forwards^h

`Max-Forwards^h ~headerは、 `要請~method$［ `TRACE$m ／ `OPTIONS$m ］と伴に，［ 要請が`~proxy$により回送される回数 ］を制限する仕組みを供する。 これは、 `~client$が［`連鎖$の途上で［ 失敗する／~loopする ］ように出現する要請 ］を~traceするよう試みるとき，有用になり得る。 ◎ The "Max-Forwards" header field provides a mechanism with the TRACE (Section 9.3.8) and OPTIONS (Section 9.3.7) request methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting to trace a request that appears to be failing or looping mid-chain.

`Max-Forwards@p
	= 1*`DIGIT$P

`Max-Forwards^h は、［ 当の要請~messageを回送できる残りの回数 ］を指示する~decimal整数を値にとる。 ◎ The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.

`受信者$は、［ 他の`要請~method$に伴って受信した `Max-Forwards^h ~header ］については，無視してもヨイ。 ◎ A recipient MAY ignore a Max-Forwards header field received with any other request methods.

7.6.3. `Via^h

`Via@p
	= #( `received-protocol$p `RWS$p `received-by$p [ `RWS$p `comment$p ] )
`received-protocol@p
	= [ `protocol-name$p "/" ] `protocol-version$p【！; see `7.8§】
`received-by@p
	= `pseudonym$p [ ":" `port$p ]
`pseudonym@p
	= `token$p

【 “`pseudonym^p” ＝ “`pseudo^en” + “`anonymous^en” （ “~~疑似匿名（~~仮名）” ） 】

`Via$h `~field値$を成す各~memberは、 当の~messageを回送した［ `~proxy$／`~gateway$ ］を表現する。 各`媒介者$は、［ ~messageがどう受信されたかについての，自前の情報 ］を［ 回送した`受信者$たちの順序が保たれる ］ように付加する。 ◎ Each member of the Via field value represents a proxy or gateway that has forwarded the message. Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients.

`received-protocol$p は、 ~messageの`下流$の`媒介者$たちに対し，［ `上流$の`送信者$により利用された~protocol, その~version ］を指示する。 すなわち， `Via$h `~field値$は、［ 要請／応答 ］`連鎖$にて広告された~protocol能力を，`下流$の`受信者$から可視であり続けるように記録する — これは、 `2.5§ にて述べたとおり，［ 後方-互換でない特能のうち，どれが［ 応答／今後の要請 ］の中で利用するときに安全になり得るか ］を決定するときに有用になり得る。 ~~簡潔にするため、 受信される~protocolが~HTTPであるときは， `received-protocol$p 内の `protocol-name^p は省略される【されてもヨイ？】 。 ◎ For each intermediary, the received-protocol indicates the protocol and protocol version used by the upstream sender of the message. Hence, the Via field value records the advertised protocol capabilities of the request/response chain such that they remain visible to downstream recipients; this can be useful for determining what backwards-incompatible features might be safe to use in response, or within a later request, as described in Section 2.5. For brevity, the protocol-name is omitted when the received protocol is HTTP.

`received-by$p を成す部位は、 通常は［ `受信者$である`~server$, または［ ~messageを~~後続へ回送した`~client$ ］］の［ `~host$, および省略可能な`~port$番号 ］になる。 しかしながら，［ 本物の~hostは敏感な情報である ］と見なされる場合、 `送信者$は，それを `pseudonym$p に置換してもヨイ。 `port$p が供されていない場合、 `受信者$は，それを［ `received-protocol$p の既定の~TCP~port上で受信されたことを意味している ］と解釈してもヨイ — 当の~protocolに既定の~portが定義されている限り。 ◎ The received-by portion is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym. If a port is not provided, a recipient MAY interpret that as meaning it was received on the default port, if any, for the received-protocol.

`送信者$は、 各`受信者$の~softwareを識別するために【識別する側とされる側が逆？】， `comment$p を`生成-$してもヨイ — ［ `User-Agent$h ／ `Server$h ］~headerに相似的な。 しかしながら， `Via$h ~header内の~commentは任意選択であり、 受信者は — ~messageを回送するに先立って — それらを除去してもヨイ。 ◎ A sender MAY generate comments to identify the software of each recipient, analogous to the User-Agent and Server header fields. However, comments in Via are optional, and a recipient MAY remove them prior to forwarding the message.

Via: 1.0 fred, 1.1 p.example.net

［ ~network~firewallを通る~portal ］として利用される`媒介者$は、 明示的に可能化されていない限り，［ ~firewall領域の中の各~host ］の［ 名前, ~port ］を回送するベキでない。 可能化されていない場合、 そのような`媒介者$は，［ ~firewallの背後の~hostを表すような，各 `received-by$p ~host ］を［ その~hostに適切な `pseudonym$p ］に置換するベキである。 ◎ An intermediary used as a portal through a network firewall SHOULD NOT forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, such an intermediary SHOULD replace each received-by host of any host behind the firewall by an appropriate pseudonym for that host.

`媒介者$は、 `Via$h ~headerの［ `received-protocol$p 値が互いに一致する，~~連続する一連の~list~member ］を，単独の~memberに結合してもヨイ。 ◎ An intermediary MAY combine an ordered subsequence of Via header field list members into a single member if the entries have identical received-protocol values.＼

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

8.3.1. ~MIME型

【 この訳では、 原文の［ `Internet media type^en, その略称 `media type^en ］を，一律に “~MIME型” と表記する （ ~RFC以外の他の~web標準と一貫させるため）。 】

~HTTPは、［ ~openかつ拡張できる，~dataの型~付けと型~折衝 ］を供するため，［ `Content-Type$h, `Accept$h ］~header内で~MIME型 `RFC2046$r を利用する。 `~MIME型@ （ `media-type$p ）は、 ~data形式, および様々な処理~model — ~message文脈に則って，~dataを処理する方法 — を定義する。 ◎ HTTP uses media types [RFC2046] in the Content-Type (Section 8.3) and Accept (Section 12.5.1) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with the message context.

`media-type@p
	= `type$p "/" `subtype$p `parameters$p
`type@p
	= `token$p
`subtype@p
	= `token$p

［ `type$p, `subtype$p ］どちらも、 文字大小無視である。 ◎ The type and subtype tokens are case-insensitive.

`type/subtype^p には、 ~semicolonで区切られた何個かの `~MIME型~parameter@ — ［ 名前, 値 ］が成す~pairの形をとる`~parameter$ — が後続してもヨイ。 ~parameterの有無は、［ ~MIME型~registryにおける その定義 ］に依存して，~MIME型の処理に有意になり得る。 各~parameterの値が文字大小区別になるかどうかは、 当の~parameterの名前の意味論に依存する。 ◎ The type/subtype MAY be followed by semicolon-delimited parameters (Section 5.6.6) in the form of name/value pairs. The presence or absence of a parameter might be significant to the processing of a media type, depending on its definition within the media type registry. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name.

text/html;charset=utf-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
text/html;charset=UTF-8

~MIME型は、 `BCP13$r にて定義される手続-に則って，~IANAにより登録される~OUGHT。 ◎ Media types ought to be registered with IANA according to the procedures defined in [BCP13].

8.3.2. ~charset

~HTTPでは、［ ~textな表現の文字~符号化~scheme `6365/2$rfc ］を［ 指示する／折衝する ］ときに， `~charset^dfn （ `charset^en ）名を利用する。 この文書に定義される~fieldにおいては、 ~charset名は［ `Content-Type$h の `parameters$p 内に／ `Accept-Encoding$p† 用に素な~token形として ］出現する。 どちらの事例でも、 ~charset名は文字大小無視で照合される。 ◎ HTTP uses "charset" names to indicate or negotiate the character encoding scheme ([RFC6365], Section 2) of a textual representation. In the fields defined by this document, charset names appear either in parameters (Content-Type), or, for Accept-Encoding, in the form of a plain token. In both cases, charset names are matched case-insensitively.

【† `7419$errata（Verified）： `Accept-Encoding^p は `Accept-Charset$p に置換するべき。 】

~charset名は、 `2978/2$rfc にて定義される手続-に則って， ~IANA `Character Sets＠~IANA-a/character-sets$cite ~registryに登録される~OUGHT。 ◎ Charset names ought to be registered in the IANA "Character Sets" registry (<https://www.iana.org/assignments/character-sets>) according to the procedures defined in Section 2 of [RFC2978].

注記： 理論~上は、 ~charset名は， `mime-charset^p ~ABNF規則 `2978/2.3$rfc にて定義される （ `Err1912$r により正された上で）。 その規則は， `token$p に含まれない 2 つの文字（ "`{^c", "`}^c" ）を許容するが、 これを書いた時点では，それらの文字を含む~charset名は登録されていない （ `Err5433$r を見よ）。 ◎ Note: In theory, charset names are defined by the "mime-charset" ABNF rule defined in Section 2.3 of [RFC2978] (as corrected in [Err1912]). That rule allows two characters that are not included in "token" ("{" and "}"), but no charset name registered at the time of this writing includes braces (see [Err5433]).

8.3.3. `multipart^c 型

~MIMEは、［ 単独の`~message本体$の中に， 1 個以上の`表現$が~capsule化される ］ような，いくつかの "`multipart^c" 型を供する。 すべての "`multipart^c" 型は、 `2046/5.1.1$rfc にて定義されるとおり，共通な構文を共有し、 `~MIME型$ 値の一部として，境界~parameterを内包する。 `~message本体$自身は、 ~protocol要素である — `送信者$は、 本体の各 部分~間の改行を表現するときは， `CRLF$P のみを`生成-$しなければナラナイ。 ◎ MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body. All multipart types share a common syntax, as defined in Section 5.1.1 of [RFC2046], and include a boundary parameter as part of the media type value. The message body is itself a protocol element; a sender MUST generate only CRLF to represent line breaks between body parts.

~HTTP~message~frame法においては、 "`multipart^c" 境界が `~message本体$の長さの指示子として利用されることはない — `内容$を［ 生成する／処理する ］実装により，利用されることはあっても。 例えば， "`multipart/form-data^c" 型は、 `RFC7578$r にて述べられるとおり，要請~内に~form~dataを運ばせるために利用されることが多い。 また， "`multipart/byteranges$c" 型は、 一部の `206$st 応答に利用するためとして，この仕様により定義される。 ◎ HTTP message framing does not use the multipart boundary as an indicator of message body length, though it might be used by implementations that generate or process the content. For example, the "multipart/form-data" type is often used for carrying form data in a request, as described in [RFC7578], and the "multipart/byteranges" type is defined by this specification for use in some 206 (Partial Content) responses (see Section 15.3.7).

8.4.1. 内容~符号法

内容~符号法の値（ `content-coding$p ）は、［ `表現$に［ 適用された／適用できる ］符号化法による形式変換 ］を指示する。 内容~符号法は、 首に，次を許容するために利用される ⇒ 表現の下層の［ `~MIME型$の同一性, 情報 ］を損なうことなく，表現を — 圧縮するなど — 有用に形式変換する。 ◎終 表現が［ 符号化形で格納され，直に伝送され ］，最終-受信者のみがそれを復号することは、 ~~頻繁にある。 ◎ Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted directly, and only decoded by the final recipient.

`content-coding@p
	= `token$p

すべての内容~符号法は、 文字大小無視であり，［ `16.6§ にて述べるとおり， `内容~符号法~registry$cite の中に登録される ］~OUGHT。 ◎ All content codings are case-insensitive and ought to be registered within the "HTTP Content Coding Registry", as described in Section 16.6

各種 内容~符号法~値は、［ `Accept-Encoding$h, `Content-Encoding$h ］~header内で利用される。 ◎ Content-coding values are used in the Accept-Encoding (Section 12.5.3) and Content-Encoding (Section 8.4) header fields.

8.5.1. 言語~tag

`言語~tag@ （ `language tag^en ）は、 `RFC5646$r にて定義されるとおり， 自然~言語 — 他者と情報をやりとりするために，ヒトにより［ 話される／書かれる ］などにより伝達される言語 — を識別する。 ~computer言語は、 明示的に除外される。 ◎ A language tag, as defined in [RFC5646], identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded.

~HTTPでは、 言語~tagを［ `Accept-Language$h ／ `Content-Language$h ］~headerの中で利用する。 `Accept-Language$h は，より~~広い `language-range$p 生成規則を利用するように定義される一方、 `Content-Language$h は，次に定義する `language-tag$p 生成規則を利用する： ◎ HTTP uses language tags within the Accept-Language and Content-Language header fields. Accept-Language uses the broader language-range production defined in Section 12.5.4, whereas Content-Language uses the language-tag production defined below.

`language-tag@p
	= <Language-Tag, `5646/2.1$rfc>

fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

更なる情報は、 `RFC5646$r を見よ。 ◎ See [RFC5646] for further information.

8.8.1. 弱い vs. 強い

検証子には、［ 強いもの, 弱いもの ］がある。 `弱い検証子$は、 容易に生成できるが， 比較~~用途には あまり有用でない。 `強い検証子$は、 比較~~用途には理想的であるが， 効率的に生成することは とても困難にも（ときには不可能にも）なり得る。 ~HTTPは、［ すべての形の`資源$が，同じ強さの検証子を固守する ］ことを課すのではなく，［ 利用-中にある検証子の型を公開する ］こと, および［ `弱い検証子$を いつどこで`事前条件$に利用できるか ］についての制約を課す。 ◎ Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.

`強い検証子@ （ `strong validator^en ）とは、［ `表現~data$が変化する度に値が変化する，`表現~metadata$ ］であって，［ `GET$m 要請に対する `200$st 応答 ］の`内容$にて観測-可能になるものである。 ◎ A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the content of a 200 (OK) response to GET.

`強い検証子$は，`表現~data$の変化-以外の理由 — `表現~metadata$の意味論的に有意な部分（例： `Content-Type$h ）が変更されたなど — から変化することもあるが、 `生成元~server$にとって~~最大の関心~事は，［［ ~remote~cacheや著作~toolにより保持されている，格納-済み応答 ］を無効化する必要がある ］ときに限り値を変更することである。 ◎ A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.

~cache~entryは、 その失効~時機に関わらず，いつまでも持続し続けるかもしれない。 したがって~cacheは、［ ~~遠い過去に得された検証子を利用している~entry ］を検証するよう試みることもある。 `強い検証子$は、［ ある特定の`資源$に結付けられた，すべての`表現$のすべての~version ］間で，時間~越しに一意になる。 しかしながら、［ 互いに異なる資源 ］の表現~間にわたる一意性については，含意されない （すなわち、［ 同じ`強い検証子$が，同~時に複数の資源の表現~用に利用-中にある ］かもしれないが，それらの表現が等価になることは含意しない）。 ◎ Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).

実施においては、 種々の`強い検証子$が利用されている。 厳密な改訂~制御に基づくものが最良である — 表現に対する各~変更に際して，［ 表現が `GET$m から~access可能にされる前 ］に，常に，一意な~node名と改訂~識別子がアテガわれるような。 ［ `応答~header$が送信されるに先立って，~dataが可用である ］下では，耐衝突~hash関数を`表現~data$に適用して得られる~digestでも足り、 検証~要請が受信される度に計算し直す必要はない。 ただし，`資源$が［ ~metadataにおいてのみ相違するような，別個な`表現$を有する ］場合には （`内容~折衝$の対象になる`~MIME型$のうち複数のものが，同じ~data形式を共有するときに生じ得る）、 `生成元~server$は，［ それらの表現どうしを判別するための追加的な情報 ］を検証子に組入れる必要がある。 ◎ There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.

`生成元~server$は、［ 先立つ`表現$たちが現在の`表現$の代用として受容-可能でない ］と見なす度に，`弱い$`実体~tag$を変更するベキである。 言い換えれば、 ~cacheの中の旧い応答を無効化するよう求める度に，変更する~OUGHT。 ◎ An origin server SHOULD change a weak entity tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity tag ought to change whenever the origin server wants caches to invalidate old responses.

例えば，［ 動的な測定に基づいて内容が秒単位で変化するような，気象情報の表現 ］は、 同じ`弱い検証子$により， （`生成元~server$から見て）等価な表現たちが成す集合に~group化されるかもしれない — ~cache済み表現が、 （たぶん，~server負荷や天気の質に基づいて動的に調整されるような）適度な期間， 有効であり続けられるようにするために。 同様に、 表現の改変~時刻が秒単位の分解能で定義されていて， その表現が 1 秒~間に 2 回~改変され， それらの改変の合間に検索取得され得る場合には、 `弱い検証子$になることがある。 ◎ For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.

同様に、 検証子は、 所与の`資源$の~~複数の`表現$間で同~時に共有されているならば， `弱い$ものになる — それらの`表現~data$が一致しない限り。 例えば，`生成元~server$が［ `gzip$c `内容~符号法$が適用された`表現$ ］に対し［ 内容~符号法を伴わない表現のときと同じ`検証子$ ］を送信する場合、 それは`弱い検証子$になる。 しかしながら、 複数の`表現$が同じ`強い検証子$を同時に共有することもある — 同じ`表現~data$に対し，複数の異なる`~MIME型$が可用であるときなど、 それらが`表現~metadata$においてのみ相違する場合には。 【！ https://www.rfc-editor.org/errata/eid5162】 ◎ Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.

`強い検証子$は、 どの`条件付き要請$にも利用できる — ［ `~cache検証$, 内容の`部分的$な範囲, “`更新喪失$” 回避法 ］も含め。 `弱い検証子$を利用できるのは、［ ~clientが以前に得した`表現~data$との正確な同等性を要求しないとき ］に限られる — ~cache~entryを検証するときや，近過去な変更に対しては、 ~webの辿りを制限するときなど。 ◎ Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.

8.8.2. `Last-Modified^h

応答~内の `Last-Modified$h ~headerは、 `生成元~server$が要請の取扱いから結論に至った， `改変~日時@ — `選定された表現$が最後に改変された日付時刻 — を指示する時刻印を供する。 ◎ The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.

`Last-Modified@p
	= `HTTP-date$p

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

8.8.3. `ETag^h

応答~内の `ETag$h ~fieldは、 それが応対した要請の取扱いから結論に至った，［ `選定された表現$用の現在の`実体~tag$（ `entity-tag$p ） ］を供する。 `実体~tag@ （ `entity tag^en ）は、［ 同じ`資源$からの複数の`表現$を相違化するための，`不透明$な検証子 ］であり， 表現が複数あることが何に因るのか — ［ `資源$の状態が時間~越しに変化したこと／ `内容~折衝$により同~時に複数の表現が妥当になったこと／ あるいはこの両者 ］に因るのか — は問わない。 `実体~tag$の主部は，引用符で括られた`不透明$な文字列（ `opaque-tag$p ）であり、 `弱い検証子$であるときは，それを指示する `weak$p も接頭される： ◎ The "ETag" field in a response provides the current entity tag for the selected representation, as determined at the conclusion of handling the request. An entity tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.

`ETag@p
	= `entity-tag$p

`entity-tag@p
	= [ `weak$p ] `opaque-tag$p
`weak@p
	= ~Ps"W/"
`opaque-tag@p
	= `DQUOTE$P *`etagc$p `DQUOTE$P
`etagc@p
	= `21^X
	/ `23-7E^X
	/ `obs-text$p
	; 
`DQUOTE^P を除く `VCHAR^P, および `obs-text^p
◎
VCHAR except double quotes, plus obs-text

注記： `opaque-tag$p は、 以前は `quoted-string$p （ `2616/3.11$rfc ）として定義されていた。 そのため、 受信者の中には，~backslash~escapeを外そうとするものもある。 したがって，~serverは、 `実体~tag$内では~backslash文字を避ける~OUGHT。 ◎ Note: Previously, opaque-tag was defined to be a quoted-string ([RFC2616], Section 3.11); thus, some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity tags.

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

`実体~tag$は、［ `弱い検証子$, `強い検証子$（これが既定） ］どちらにもなり得る。 `表現$に`実体~tag$を供する`生成元~server$は、［ その代の`実体~tag$が， `強い検証子$の特性~すべてを満足するものでない場合 ］には、 `実体~tag$に `weak$p （ "`W/^c", 文字大小区別）を接頭して， `弱い検証子$として~markしなければナラナイ。 ◎ An entity tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity tag for a representation and the generation of that entity tag does not satisfy all of the characteristics of a strong validator (Section 8.8.1), then the origin server MUST mark the entity tag as weak by prefixing its opaque value with "W/" (case-sensitive).

`送信者$は、 `ETag^h ~fieldを`~trailer節$内に送信してもヨイ （ `6.5§ を見よ）。 しかしながら，`~trailer$は無視されることが多いので、 `ETag^h は — `内容$の送信-中に`実体~tag$を`生成-$していない限り — `~header$として送信する方が好ましい。 ◎ A sender MAY send the ETag field in a trailer section (see Section 6.5). However, since trailers are often ignored, it is preferable to send ETag as a header field unless the entity tag is generated while sending the content.

GET /index HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip

HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-a"
Content-Length: 70
Vary: Accept-Encoding
Content-Type: text/plain

Hello World!
Hello World!
Hello World!
Hello World!
Hello World!

HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b"
Content-Length: 43
Vary: Accept-Encoding
Content-Type: text/plain
Content-Encoding: gzip

`…~binary~data…^com

9.2.1. 安全な~method

`要請~method$は、［ それに定義される意味論が本質的に読専である ］とき， `安全@ （ `safe^en ）であると見なされる — すなわち，`~client$は、［ `安全$な~methodを`~target資源$に適用した結果 ］として，`生成元~server$上の いかなる状態~変化も［ 要請しない／期待しない ］。 同様に，［ `安全$な~methodの適度な利用 ］は、 生成元~server上に，いかなる［ 害／~propertyの損失／通例的でない負担 ］も及ぼさないものと期待されている。 ◎ Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

この［ `安全$な~methodの定義 ］は、 その呼出ngが［ 有害にもなり得る ／ 読専でない~~部分がある ／ 副作用を及ぼす ］ような挙動を含まないことを実装に~~強いるものではない。 しかしながら，重要な点は、 `~client$は［ 追加的な挙動を要請しないし, それについて~~関知できない ］ことにある。 例えば、 ほとんどの~serverは，［ ~methodに関わらず，応答が完了するごとに要請~情報を~access~log~fileに付加する ］が、［ その~log~storageが満杯になり，~serverを失敗させ得る ］としても，`安全$と見なされる。 同様に，~Web広告を選定することにより起動される要請は、 `安全$であっても，広告料を課金するような副作用を伴うことが多い。 ◎ This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and cause the server to fail. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.

この仕様が定義する`要請~method$のうち［ `GET$m , `HEAD$m , `OPTIONS$m , `TRACE$m ］は、 `安全$であるものと定義される。 ◎ Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.

~methodが`安全$か否かを判別する目的は、［ 自動化された検索取得~処理n（~spider）／ ~cache処理能の最適化（事前fetch） ］が，害を及ぼす心配なしに働くことを許容することにある。 加えて、 ~UAが，信用できない~~可能性もある内容を処理する際に［ `安全$でない~methodが自動的に利用されないよう，適切な拘束を適用する ］ことも許容する。 ◎ The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.

`~UA$は、 ~methodが`安全$か否かを判別して，［ `安全$でない動作は，要請される前に利用者が自覚できる ］よう［ ~~行われ得る動作を利用者に呈示する ］ベキである。 ◎ A user agent SHOULD distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware of an unsafe action before it is requested.

`資源$が［ `~target~URI$の中の~parameter群が動作を選定する効果を有する ］ように構築されているとき、［ その動作が`要請~method$の意味論に整合する ］ことを確保することは，資源~所有者の責務である。 例えば，~Webに基づく内容~編集~softwareが［ `query$p ~parameterの中で， "`page?do=delete^c" などの動作を利用する ］ことは、 共通的にある。 そのような資源の目的が，安全でない動作を遂行することにある場合、 資源~所有者は，［ それが`安全$な要請~methodを利用して~accessされる ］ときには［ その動作を不能化するなどにより許容しない ］ようにしなければナラナイ。 さもなければ、［ ~link保守, 事前fetch, 探索~indexを築く, 等々 ］の~~目的で［ どの`~URI参照$に対しても，自動化された処理により `GET$m が遂行される ］ときに，~~望ましくない副作用が~~生じることになる。 ◎ When a resource is constructed such that parameters within the target URI have the effect of selecting an action, it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the purpose of such a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate side effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, building a search index, etc.

9.2.2. 冪等~method

`要請~method$は、［ 複数回の［ 互いに一致する，その~methodを伴う要請 ］により意図される，`~server$に対する効果 ］が［ 一回の［ そのような要請 ］による効果 ］と同じになるとき， `冪等@ （ `idempotent^en ）であると見なされる。 この仕様が定義する要請~methodのうち［ `PUT$m, `DELETE$m ］, および`安全$とされるものは、 冪等である。 【`安全$な要請~methodは、この仕様が定義しないものでも，定義により冪等になろう。】 ◎ A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

`安全$の定義と同様に、 冪等性の定義が適用されるのは，［ 利用者から何が要請されたか ］に限られる — `~server$は、 各 冪等な要請に対し，次を行ってもかまわない ⇒＃ その~logを別にとる／ 改訂~制御~用の履歴を維持する／ 他の非~冪等な副作用を実装する ◎ Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.

冪等な~methodには、［ `~client$が`~server$の応答を読取n可能になる前に，通信が失敗した場合には、 要請を自動的に繰返せる ］という~~特徴がある。 例えば、 ~clientが `PUT$m 要請を送信したとき， 応答が受信される前に下層の接続が~closeされた場合、 ~clientは，新たな接続を確立して冪等な要請を再試行できる。 元の要請が成功していたとしても、 その要請を繰返した結果が — 応答は相違するかもしれないが — 意図された効果と同じになることは，わかっているので。 ◎ Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.

一部の`~client$は、 自動的な再試行がアリなときに，より~riskが高い~approachで推測するよう試みる。 例えば，~clientは、 `POST$m 要請に対する応答を一部でも受信する前に， 下層の~transport接続が~closeされた場合には — 特に，遊休中かつ持続的な接続が利用されているときは — それを自動的に再試行するかもしれない。 ◎ Some clients take a riskier approach and attempt to guess when an automatic retry is possible. For example, a client might automatically retry a POST request if the underlying transport connection closed before any part of a response is received, particularly if an idle persistent connection was used.

`~proxy$は、 冪等でない要請を自動的に再試行してはナラナイ。 `~client$は、［ 失敗した自動的な再試行 ］を自動的に再試行するベキでない。 ◎ A proxy MUST NOT automatically retry non-idempotent requests. A client SHOULD NOT automatically retry a failed automatic retry.

9.2.3. ~methodと~cache法

~cacheが応答を格納して利用するためには、 当の応答が応対した要請の~method【！the associated method】が~cachingを明示的に許容している必要があり，［ 後続な要請を満足するために当の応答を利用できる条件 ］についての詳細も必要になる — ~method定義が許容していない場合、 ~cacheできない。 追加的な要件については、 `CACHING$r を見よ。 ◎ For a cache to store and use a response, the associated method needs to explicitly allow caching and to detail under what conditions a response can be used to satisfy subsequent requests; a method definition that does not do so cannot be cached. For additional requirements see [CACHING].

この仕様は、［ `GET$m, `HEAD$m, `POST$m ］~method用に~cache法の意味論を定義する — 大多数の~cache実装は、［ `GET$m, `HEAD$m ］しか~supportしていないが。 ◎ This specification defines caching semantics for GET, HEAD, and POST, although the overwhelming majority of cache implementations only support GET and HEAD.

9.3.1. `GET^m

`GET^m ~methodは、 現在の［ `~target資源$用に`選定される表現$ ］を転送するよう要請する。 成功裡な応答は、 `~target~URI$により識別される “同じさの質” を反映する （ `URI$r `1.2.2§uri ）。 よって，~HTTPを介して識別-可能な情報を検索取得することは、 通例的に，ある識別子 — ［ その情報を `200$st 応答~内に供する~~可能性 ］が結付けられた識別子 — に対し `GET^m 要請を為すことにより遂行される。 ◎ The GET method requests transfer of a current selected representation for the target resource. A successful response reflects the quality of "sameness" identified by the target URI (Section 1.2.2 of [URI]). Hence, retrieving identifiable information via HTTP is usually performed by making a GET request on an identifier associated with the potential for providing that information in a 200 (OK) response.

`GET^m は、 情報を検索取得する首な仕組みであり， ほぼすべての処理能~最適化は そこに注力される。 重要な各~資源に対し，~URIを生産する応用は、［ そのような最適化による便益を得ながら，他の応用によるそれらの再利用-も可能化する ］ことで，~Webの更なる拡がりを促進する~network効果を発揮することになる。 ◎ GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Applications that produce a URI for each important resource can benefit from those optimizations while enabling their reuse by other applications, creating a network effect that promotes further expansion of the Web.

資源~識別子は ~remote~file~systemの~pathnameで， `表現$は そのような~file内容の複製であると、 ~~考えられがちである。 事実、 多くの`資源$が実装されている方法でもある （関係する~securityの考慮点については `17.3§ を見よ）。 しかしながら、 実施においては，そのような制限は無い。 ◎ It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of such files. In fact, that is how many resources are implemented (see Section 17.3 for related security considerations). However, there are no such limitations in practice.

資源~用の~HTTP~interfaceは、 単に［ 内容~objたちが成す~tree ／ 様々な~database~record上の~program的な~view ／ 他の情報~systemへの~gateway ］などとして実装される見込みも高い。 `~URI$を【資源へ】対応付ける仕組みが~file~systemに縛られているときでも、 `生成元~server$は — ~fileを直に転送するのではなく — ［ 要請を入力に~fileを実行して，その出力として表現を送信する ］よう環境設定されることもある。 いずれにせよ、［ 各~資源~識別子が どの実装に対応するか ］や［ その実装が［ `~target資源$の現在の表現を選定して送信すること ］を どう管理するか ］を知る必要があるのは、 生成元~serverのみである。 ◎ The HTTP interface for a resource is just as likely to be implemented as a tree of content objects, a programmatic view on various database records, or a gateway to other information systems. Even when the URI mapping mechanism is tied to a file system, an origin server might be configured to execute the files with the request as input and send the output as the representation rather than transfer the files directly. Regardless, only the origin server needs to know how each resource identifier corresponds to an implementation and how that implementation manages to select and send a current representation of the target resource.

`~client$は、 要請~内に `Range$h ~headerを送信することにより， `GET^m の意味論を`範囲~要請$ — `選定された表現$を成すいくつかの部分に限り，転送を要請する要請 — に改めることもできる。 ◎ A client can alter the semantics of GET to be a "range request", requesting transfer of only some part(s) of the selected representation, by sending a Range header field in the request (Section 14.2).

要請~messageの~frame法は，利用される~methodとは独立であるが、 `GET^m 要請~内に受信される`内容$には、 一般に意味論は定義されず，要請の意味や~targetを改めることはない — 加えて，`要請~密入~攻撃$ `HTTP/1.1$r のおそれがあるので、 一部の実装を［ 要請を却下して接続を~closeする ］よう導くかもしれない。 `~client$は、 `GET^m 要請~内に`内容$を`生成-$するベキでない — ただし、 それまでに［ そのような要請には目的があり，必要十分に~supportされることになる ］ものと帯域の［ 内／外 ］にて指示されていて， 当の要請が`生成元~server$へ向けて直に為される場合は除く。 `生成元~server$は、［ 内容を受信する私的な合意 ］があったとしても，それに依拠するベキでない — ~HTTP通信における各~参加者は、 要請の`連鎖$沿いにある`媒介者$たちを自覚しないことが多いので。 ◎ Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

`GET^m 要請に対する応答は、 `~cache可能$である — `Cache-Control$h ~headerから他が指示されない限り、 後続な［ `GET^m ／ `HEAD$m ］要請を満足するためとして，その応答を~cacheに利用してもヨイ。 ◎ The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING]).

情報の検索取得が，利用者が供した情報から`~target~URI$を構築する仕組み （例： `GET^m を利用している~formの~query~field【`参照＠~HTMLforms#concept-fs-action$】など） で遂行されるとき、［ ~URIの中に開示するには適切にならない，敏感になり得る~data ］が供されるかもしれない（ `17.9§ を見よ）。 一部の事例では、 そのような情報を露呈しないよう，当の~dataを［ ~filter／形式変換 ］できる。 他の事例 — 特に，応答を~cacheしても便益は無いとき — においては、 `GET^m に代えて `POST$m ~methodを利用すれば， そのような情報は — `~target~URI$の中ではなく — 要請の`内容$内に伝送できる。 ◎ When information retrieval is performed with a mechanism that constructs a target URI from user-provided information, such as the query fields of a form using GET, potentially sensitive data might be provided that would not be appropriate for disclosure within a URI (see Section 17.9). In some cases, the data can be filtered or transformed such that it would not reveal such information. In others, particularly when there is no benefit from caching a response, using the POST method (Section 9.3.3) instead of GET can transmit such information in the request content rather than within the target URI.

9.3.2. `HEAD^m

`HEAD^m ~methodは、［ `~server$は、 対する応答~内に`内容$を送信してはナラナイ ］ことを除いて， `GET$m に一致する。 `HEAD^m は、 `選定された表現$について［ その`表現~data$を転送することなく，その~metadataを得する ］ために利用される。 それは、［ ~hypertext~linkを~testする／近過去な改変を見出す ］~~目的で利用されることが多い ◎ The HEAD method is identical to GET except that the server MUST NOT send content in the response. HEAD is used to obtain metadata about the selected representation without transferring its representation data, often for the sake of testing hypertext links or finding recent modifications.

`~server$は、 `HEAD^m 要請に対する応答~内に，［ 要請~methodが `GET$m であったときに送信することになる~headerたち ］と同じ~headerたちを送信するベキである — ただし，~headerのうち［ `内容$を`生成-$する間に限り，その値が決定されるもの ］は、 省略してもヨイ。 例えば，一部の~serverは、 `GET^m に対する動的な応答を［ 小さな応答をより効率的に区切る／内容~選定に関する裁定を後で下す ］ために必要な最小~量な~dataが`生成-$されるまで，~bufferする。 `GET^m に対するそのような応答は、 `HEAD^m に対する応答の中には`生成-$されない~field — 例えば `Content-Length$h や `Vary$h — を包含するかもしれない。 `HEAD^h 要請~用には、 これらの細かな不整合は，【~field値を得るために】`内容$を`生成-$して破棄するより好ましいと見なされる — `HEAD^m は、 通例的に，効率の~~目的で要請されるので。 ◎ The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the content. For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain Content-Length and Vary fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency.

要請~messageの~frame法は，利用される~methodとは独立ではあるが、 `HEAD^m 要請~内に受信される`内容$には、 一般に意味論は定義されず，要請の意味や~targetを改めることはない — 加えて，`要請~密入~攻撃$ `HTTP/1.1$r のおそれがあるので、 一部の実装を［ 要請を却下して接続を~closeする ］よう導くかもしれない。 `~client$は、 `HEAD^m 要請~内に`内容$を`生成-$するベキでない — ただし、 それまでに［ そのような要請には目的があり，必要十分に~supportされることになる ］ものと帯域の［ 内／外 ］にて指示されていて，`生成元~server$へ向けて直に為される場合は除く。 `生成元~server$は、［ 内容を受信する私的な合意 ］があったとしても，それに依拠するベキでない — ~HTTP通信における参加者は、 要請の`連鎖$沿いにある`媒介者$を自覚しないことが多いので。 ◎ Although request message framing is independent of the method used, content received in a HEAD request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a HEAD request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

`HEAD^m 要請に対する応答は、 `~cache可能$である — `Cache-Control$h ~headerから他が指示されない限り、 後続な `HEAD^m 要請を満足するためとして，その応答を~cacheに利用してもヨイ。 そのような応答は、［ 以前に~cacheされた `GET$m に対する応答 ］にも影響するかもしれない — `CACHING$r `4.3.5＠~HTTPcache#head.effects§ を見よ。 ◎ The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING]). A HEAD response might also affect previously cached responses to GET; see Section 4.3.5 of [CACHING].

9.3.3. `POST^m

`POST^m ~methodは、 `~target資源$が［ 自前の特有な意味論に則って，要請~内に同封された`表現$を処理する ］よう要請する。 この~methodは、 例えば，次に挙げる機能に利用される（他にもある）： ◎ The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):

• 一群の~data — ~HTML~formに手入力された一連の~fieldなど — が成す~blockを，~data取扱い処理nに供する。 ◎ Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
• ［ 掲示板, ニュースグループ, メーリングリスト, ブログ, その他~類似な記事~群など ］へ，~messageを投函する。 ◎ Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
• `生成元~server$からは まだ識別されていない，新たな`資源$を作成する。 ◎ Creating a new resource that has yet to be identified by the origin server; and
• 既存の`資源$の`表現$（たち）に~dataを付加する。 ◎ Appending data to a resource's existing representation(s).

`生成元~server$は、［ `POST^m 要請の処理~結果に依存して，適切な`状態s~code$を選ぶ ］ことにより，応答の意味論を指示する — `POST^m に対する応答~内には、 この仕様が定義する ほぼすべての状態s~codeが受信され得る （例外は： `206$st, `304$st, `416$st ）。 ◎ An origin server indicates response semantics by choosing an appropriate status code depending on the result of processing the POST request; almost all of the status codes defined by this specification could be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).

`POST^m の処理~結果が既存の`資源$の`表現$と等価になる場合、 `生成元~server$は、 `303$st 応答を — その `Location$h ~header【！~field】内に当の資源の識別子を伴わせた上で — 送信することにより， `~UA$を~redirectしてもヨイ。 これには便益がある： ~UAに資源~識別子を供して，より［ `共用~cache$に受け入れられ易い~method ］を介して［ 当の`表現$を転送させる ］ような — ~UAが~cache済み表現をまだ有していない場合、 余分な要請~costがかかるが。 ◎ If the result of processing a POST would be equivalent to a representation of an existing resource, an origin server MAY redirect the user agent to that resource by sending a 303 (See Other) response with the existing resource's identifier in the Location field. This has the benefits of providing the user agent a resource identifier and transferring the representation via a method more amenable to shared caching, though at the cost of an extra request if the user agent does not already have the representation cached.

9.3.4. `PUT^m

`生成元~server$には、 以下の要件が課される — 以下、 `PUT^m された`表現$を %P と記す： ◎ ↓

• `~target資源$用の現在の`表現$が： ◎ ↓

  • 無い場合 ⇒ `PUT^m が何か一つを成功裡に作成したときは、 `201$st 応答を`~UA$に送信して，その旨を伝えなければナラナイ。 ◎ If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response.＼
  • 在る場合 ⇒ その表現が %P の状態に則って成功裡に改変されたときは、 `200$st または `204$st 応答を送信して，要請の成功裡な完了を指示しなければナラナイ。 ◎ If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.

• `~target資源$用に環境設定されたどの拘束にも， %P が整合することを検証yするベキである。 例えば，`生成元~server$は、 資源の`表現~metadata$を~URIに基づいて決定する場合には，［ 成功裡な `PUT^m 要請~内に受信した内容が，その~metadataと整合する ］ことを確保する必要がある。 ◎ An origin server SHOULD verify that the PUT representation is consistent with its configured constraints for the target resource. For example, if an origin server determines a resource's representation metadata based on the URI, then the origin server needs to ensure that the content received in a successful PUT request is consistent with that metadata.＼

  %P が~target資源と整合でないときは、 次のいずれかを行うベキである： ◎ When a PUT representation is inconsistent with the target resource, the origin server SHOULD either＼

  • ［ %P を形式変換するか, 資源についての環境設定を変更する ］ことにより，それらを整合させる。 ◎ make them consistent, by transforming the representation or changing the resource configuration, or＼
  • ［ 何故 %P が相応でないかを説明するに足る情報 ］を包含する，適切な~error~messageで応答する。 それが `Content-Type$h 値に対する拘束に特有であるときは、［ `409$st ／ `415$st ］が示唆される。 ◎ respond with an appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type values.

  例えば，［ `~target資源$における `Content-Type$h は常に "`text/html^c" になる ］ように環境設定されていて, ［ %P における `Content-Type$h は "`image/jpeg^c" になる ］場合、 次のいずれかを行う~OUGHT： ◎ For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the origin server ought to do one of:

  • ~target資源が新たな`~MIME型$を反映するよう，環境設定し直す。 ◎ reconfigure the target resource to reflect the new media type;
  • %P を新たな資源~状態として保存する前に、 %P の形式が資源の形式と整合するよう， %P を形式変換する。 ◎ transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state; or,
  • 要請に対し、［ ~target資源が "`text/html^c" に制限されていることを指示する， `415$st 応答 ］で却下する — たぶん［ 新たな`表現$に相応しい~targetになる，異なる資源への~link ］を内包するような。 ◎ reject the request with a 415 (Unsupported Media Type) response indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would be a suitable target for the new representation.

このことは、 各`~field$（~header／~trailer）がどう格納されるかにも及ぶ。 `Content-Type$h の様な共通な~headerは、 概して格納され，後続な `GET$m 要請に際して返されることになるが、 各~fieldの取扱いは，当の要請を受信した資源に特有である。 その結果として、 `生成元~server$は，［ `PUT$m 要請~内に受信した~fieldのうち，自身が認識しないもの ］を無視するベキである （すなわち，それらを当の資源~状態の一部として保存しない）。 ◎ This extends to how header and trailer fields are stored; while common header fields like Content-Type will typically be stored and returned upon subsequent GET requests, header and trailer field handling is specific to the resource that received the request. As a result, an origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., not save them as part of the resource state).

`PUT^m 要請を適正に解釈するためには、［ ~UAが，どの`~target資源$が【利用者から】欲されているか知っている ］ことが前提になる。 ［ ~clientに利するために、 状態変更 要請を受信した後，適正な`~URI$を選定する~service ］は、 `PUT^m ではなく， `POST$m ~methodを利用して実装するベキである。 `生成元~server$は、 要請された `PUT^m を — それにより`~target資源$の状態を変更することなく — 異なる資源に適用するよう望む場合には （例：当の資源は異なる~URIへ移動されたなど）， 適切な `3xx$st 応答を送信しなければナラナイ。 また，`~UA$は、 要請を~redirectするかどうかに関して，自前の裁定を下してもヨイ。 ◎ Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that selects a proper URI on behalf of the client, after receiving a state-changing request, SHOULD be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved to a different URI, then the origin server MUST send an appropriate 3xx (Redirection) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

`~target資源$に適用される `PUT^m 要請は、 他の`資源$に副作用を及ぼし得る。 例えば，ある記事は、 “各~version” （ある時点で他のいずれかの~versionと同じ状態を共有する，互いに異なる資源） を識別するために，別々な`~URI$を有するかもしれない。 したがって， “現在の~version” の~URIに対する成功裡な `PUT^m 要請は、 ~target資源の状態を変更することに加え，［ 新たな~versionの資源を作成したり、 更には，関係する資源~間の~linkを追加する ］こともある。 ◎ A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.

一部の`生成元~server$は、 部分的な `PUT$m （ `14.5§ ）を遂行するためとして， ［ `Content-Range$h ~headerを `PUT$m 要請に対する改変子として利用する ］ことを~supportする。 ◎ Some origin servers support use of the Content-Range header field (Section 14.4) as a request modifier to perform a partial PUT, as described in Section 14.5.

`PUT^m ~methodに対する応答は、 `~cache可能$でない。 成功裡な `PUT^m 要請が~cacheを通過した場合、 その~cacheに格納-済みな`~target~URI$用の応答は， （もし在れば）すべて`無効化-$されることになる。 ◎ Responses to the PUT method are not cacheable. If a successful PUT request passes through a cache that has one or more stored responses for the target URI, those stored responses will be invalidated (see Section 4.4 of [CACHING]).

9.3.5. `DELETE^m

`DELETE^m ~methodは、［ `~target資源$と，その現在の機能性との間の結付け ］を除去してもらうよう，`生成元~server$に要請する。 この~methodは，その効果においては UNIX の "rm" ~commandに類似するが、［ 以前に結付けられた情報が削除される ］という期待ではなく，［ 生成元~serverによる~URI対応付けにおける削除~演算 ］を表出する。 ◎ The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the "rm" command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.

`~target資源$に それ用の現在の`表現$が 1 個以上ある場合に，［ それらが`生成元~server$により破壊される／ それらに結付けられた~storageが取戻される ］かどうかは、 その`資源$の［ 資質, 生成元~serverによる実装（この仕様の視野を超える） ］に全面的に依存する。 同様に、 `DELETE^m の結果として，［ ~databaseや~gateway接続など，資源の他の実装~側面 ］が［ 非作動化される／~archiveされる ］必要が~~生じることもある。 一般に，生成元~serverが `DELETE^m を許容する`資源$は、［ 削除を成遂げる仕組みが制定されたもの ］に限られると見做されている。 ◎ If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond the scope of this specification). Likewise, other implementation aspects of a resource might need to be deactivated or archived as a result of a DELETE, such as database or gateway connections. In general, it is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing the deletion.

`DELETE^m ~methodを許容する`資源$は、 相対的に少数である — それは首に、［ 利用者が，その効果に関して指令する ］ような，~remote著作~用の環境に利用される。 例えば，［ `PUT$m 要請を利用して，以前に作成された資源 ］や［ `POST$m 要請に対する`201$st 応答の `Location$h ~headerを介して識別される資源 ］は、［ それらの動作を~~元に戻すような，対応する `DELETE^m 要請 ］を許容することもある。 類似に，著作~機能を実装する~customな~UA実装 — ~remoteで運用するために，~HTTP利用して改訂を制御する~clientなど — は、［ ~serverの~URI空間は、 ~version~repositoryに対応するよう加工-済みである前提 ］に基づいて， `DELETE^m を利用できることもある。 ◎ Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified via the Location header field after a 201 (Created) response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent implementations that implement an authoring function, such as revision control clients using HTTP for remote operations, might use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository.

要請~messageの~frame法は，利用される~methodとは独立ではあるが、 `DELETE^m 要請~内に受信される`内容$には、 一般に意味論は定義されず，要請の意味や~targetを改めることはない — 加えて，`要請~密入~攻撃$ `HTTP/1.1$r のおそれがあるので、 一部の実装を［ 要請を却下して接続を~closeする ］よう導くかもしれない。 `~client$は、 `DELETE^m 要請~内に`内容$を`生成-$するベキでない — ただし、 それまでに［ そのような要請には目的があり，必要十分に~supportされることになる ］ものと帯域の［ 内／外 ］にて指示されていて，`生成元~server$へ向けて直に為される場合は除く。 `生成元~server$は、［ 内容を受信する私的な合意 ］があったとしても，それに依拠するベキでない — ~HTTP通信における参加者は、 要請の`連鎖$沿いにある`媒介者$を自覚しないことが多いので。 ◎ Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

`DELETE^m ~methodに対する応答は、 `~cache可能$でない。 成功裡な `DELETE^m 要請が~cacheを通過した場合、 その~cacheに格納-済みな`~target~URI$用の応答は（もし在れば）， すべて`無効化-$されることになる。 ◎ Responses to the DELETE method are not cacheable. If a successful DELETE request passes through a cache that has one or more stored responses for the target URI, those stored responses will be invalidated (see Section 4.4 of [CACHING]).

9.3.6. `CONNECT^m

`CONNECT^h は、 `要請~target$に特別な形を利用する — それは，この~methodに~~固有であり、 `~tunnel$の行先を成す，~colonで分離された［ ~host名と~port番号 ］のみからなる。 既定の~portは無いので、 `~client$は，~port番号を送信しなければナラナイ — `CONNECT^h 要請が［ `authority$p 成分を包含していて，~portが省かれた`~URI参照$ ］に基づく場合でも。 ◎ CONNECT uses a special form of request target, unique to this method, consisting of only the host and port number of the tunnel destination, separated by a colon. There is no default port; a client MUST send the port number even if the CONNECT request is based on a URI reference that contains an authority component with an elided port (Section 4.1).＼

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com

`~server$は、 空または妥当でない~port番号を~targetにしている `CONNECT^m 要請に対しては — 概して， `400$st で応答することにより — 却下しなければナラナイ。 ◎ A server MUST reject a CONNECT request that targets an empty or invalid port number, typically by responding with a 400 (Bad Request) status code.

`CONNECT^h は，~HTTP接続の［ 要請／応答 ］に関する資質を変更するので、 その意味論を~protocolの伝送路~形式へ対応付ける仕方は， 特定の~HTTP~versionごとに異なるかもれない。 ◎ Because CONNECT changes the request/response nature of an HTTP connection, specific HTTP versions might have different ways of mapping its semantics into the protocol's wire format.

`CONNECT^m の利用は、 `~proxy$へ向けた要請に意図されている。 `CONNECT^m 要請を受信した~proxyは、［ `要請~target$により識別される`~server$へ直に接続する ］か, あるいは［ 別の~proxyを利用するよう環境設定されている場合は，当の要請を`内方$にある次の~proxyへ回送する ］ことにより，`~tunnel$を確立できる。 `生成元~server$は， `CONNECT^m 要請を受容してもヨイが、 ほとんどの生成元~serverは， `CONNECT^m を実装しない。 ◎ CONNECT is intended for use in requests to a proxy. The recipient can establish a tunnel either by directly connecting to the server identified by the request target or, if configured to use another proxy, by forwarding the CONNECT request to the next inbound proxy. An origin server MAY accept a CONNECT request, but most origin servers do not implement CONNECT.

`CONNECT^m 要請に対する応答は、 その`状態s~code$に応じて，次を指示する： ◎ ↓

• `2xx$st ⇒ `送信者$（および`内方$にある すべての`~proxy$）は、 その`~header節$の後に~tunnel~modeへ切替えることになる — これ以降に受信される~dataは、 `要請~target$により識別される~serverからのものになる。 ◎ Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the response header section; data received after that header section is from the server identified by the request target.＼
• 他の場合 ⇒ ~tunnelは、 まだ形成されていない。 ◎ Any response other than a successful response indicates that the tunnel has not yet been formed.

~proxy認証が，`~tunnel$を作成するための権限を確立するために利用されることもある。 ◎ Proxy authentication might be used to establish the authority to create a tunnel.＼

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: basic aGVsbG86d29ybGQ=

任意な~serverへ`~tunnel$を確立することには、 有意な~riskがある — 特に、 その行先が，~Web流通~用には意図されていない［ 周知な／予約-済みな ］~TCP~portであるときは。 例えば，［ "`example.com:25^c" への `CONNECT^m ］は、 ~proxyに［ ~SMTP流通~用に予約-済みな~port ］へ接続するよう示唆することになろう — 許容された場合、 ~proxyを，~spam~emailを中継させるように騙せてしまう。 `CONNECT^m を~supportする`~proxy$は、 その利用を［ 既知な~portたちが成す制限された集合 ］または［ 環境設定-可能な，安全な`要請~target$たちが成す~list ］に制約するベキである。 ◎ There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to "example.com:25" would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email. Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable list of safe request targets.

`~server$は、［ `CONNECT^m に対する `2xx$st 応答 ］内に［ `Transfer-Encoding$h ／ `Content-Length$h ］~headerを送信してはナラナイ。 `~client$は、［ `CONNECT^m に対する成功裡な応答 ］内に受信された［ `Content-Length$h ／ `Transfer-Encoding$h ］~headerを，無視しなければナラナイ。 ◎ A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response to CONNECT. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.

`CONNECT^m 要請~messageには、 `内容$は無い。 `CONNECT^m 要請~messageの`~header節$より後に送信された~dataの解釈は、 利用-中にある~HTTP~versionに特有になる。 ◎ A CONNECT request message does not have content. The interpretation of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use.

`CONNECT^m ~methodに対する応答は、 `~cache可能$でない。 ◎ Responses to the CONNECT method are not cacheable.

9.3.7. `OPTIONS^m

`OPTIONS^m ~methodは、［ `生成元~server$／介在している`媒介者$ ］に対し，［ `~target資源$に可用な通信~optionについての情報 ］を要請する。 この~methodは、 当の`資源$に対する動作を含意することなく［ 資源に結付けられた［ ~option／要件 ］／ ~serverの能力 ］を決定することを`~client$に許容する。 ◎ The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.

`OPTIONS^m 要請のうち，`要請~target$として~asterisk （ "`*^c" ）を伴うものは、 特定の`資源$に対してではなく， `~server-wide@ に適用される。 `~server$の通信~optionは，概して`資源$に依存するので、 この種の要請が有用になるのは， ~clientが~serverの能力を~testすること以外は何もしないもの — “`ping^en” や “`no-op^en” などに類する~methodなど — に限られる。 例えば、［ `~HTTP11$に適合するか否か，`~proxy$を~testする ］ときに，これを利用できる。 ◎ An OPTIONS request with an asterisk ("*") as the request target (Section 7.1) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof).

`OPTIONS^m 要請のうち， `要請~target$が~asterisk（ "`*^c" ）でないものは、 `~target資源$と通信するときに可用な~optionに適用される。 ◎ If the request target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource.

`~client$は、 `OPTIONS^m 要請~内に，［ 要請の`連鎖$にある，特定の`受信者$ ］に宛てて `Max-Forwards$h ~headerを送信してもヨイ。 `~proxy$は、 受信した要請を回送するときには，それが `Max-Forwards$h ~headerを伴っていない限り， `Max-Forwards$h ~headerを`生成-$してはナラナイ。 ◎ A client MAY send a Max-Forwards header field in an OPTIONS request to target a specific recipient in the request chain (see Section 7.6.2). A proxy MUST NOT generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.

`~client$は、［ `内容$を包含する `OPTIONS^m 要請 ］を`生成-$するときは，［ 当の`表現$の`~MIME型$を述べる妥当な `Content-Type$h ~header ］を送信しなければナラナイ。 この仕様は、 そのような`内容$の利用については，何も定義しないことに注意。 ◎ A client that generates an OPTIONS request containing content MUST send a valid Content-Type header field describing the representation media type. Note that this specification does not define any use for such content.

`OPTIONS^m ~methodに対する応答は、 `~cache可能$でない。 ◎ Responses to the OPTIONS method are not cacheable.

9.3.8. `TRACE^m

`TRACE^m ~methodは、 当の要請~message用に［ ~remoteからの，応用~levelの~loop-back ］を要請する。 要請の`最終-受信者$は、［ 受信した~messageを`内容$として内包する `200$st 応答 ］を`~client$へ返送して，受信した~messageを反映するベキである — ただし、 下に述べる【 “敏感な~dataを包含しそうな” 】`~field$は，~messageから除外した上で。 "`message/http$c" 形式 `HTTP/1.1$r は、 それを行う仕方の一つである。 ◎ The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the content of a 200 (OK) response. The "message/http" format (Section 10.1 of [HTTP/1.1]) is one way to do so.＼

`最終-受信者@ （ `final recipient^en ）とは、 `生成元~server$, または最初に［ 要請~内の `Max-Forwards$h 値に 0 を受信した`~server$ ］である。 ◎ The final recipient is either the origin server or the first server to receive a Max-Forwards value of zero (0) in the request (Section 7.6.2).

`~client$は、 `TRACE^m 要請~内に［ 応答により開示され得るような，敏感な~dataを包含する`~field$ ］を`生成-$してはナラナイ。 例えば，［ 格納されている利用者の`資格証$や~cookie `COOKIE$r ］を `TRACE^m 要請~内に送信するような~UAは、 無分別になろう。 要請の`最終-受信者$は、 応答の`内容$を`生成-$するときには，［ 要請~内の`~field$のうち，敏感な~dataを包含しそうなもの ］を除外するベキである。 ◎ A client MUST NOT generate fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials (Section 11) or cookies [COOKIE] in a TRACE request. The final recipient of the request SHOULD exclude any request fields that are likely to contain sensitive data when that recipient generates the response content.

`TRACE^m は、 `~client$が［ 要請の`連鎖$における，他方の終端で受信されたもの ］を見て，その~dataを［ ~test用や診断用の情報 ］に利用することを許容する。 特に関心~事になるものは、 `Via$h ~headerの値である — それは、 要請~連鎖の~traceとして動作するので。 `Max-Forwards$h ~headerの利用は、 ~clientが要請~連鎖の長さを制限することを許容する — それは、［ ~messageを回送している`~proxy$の`連鎖$が，無限~loopになっている ］かどうか~testするとき，有用になる。 ◎ TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (Section 7.6.3) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.

`~client$は、 `TRACE^m 要請~内に`内容$を送信してはナラナイ。 ◎ A client MUST NOT send content in a TRACE request.

`TRACE^m ~methodに対する応答は、 `~cache可能$でない。 ◎ Responses to the TRACE method are not cacheable.

10.1.1. `Expect^h

要請~内の `Expect^h ~headerは、 `期待@ （ `expectation$p ）を指示する — それは、［ 当の要請を適正に取扱うためには、 ~serverが~supportする必要がある ］ような，一定の挙動たちが成す集合である。 ◎ The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request.

`Expect@p
	= #`expectation$p
`expectation@p
	= `token$p [ "=" ( `token$p / `quoted-string$p ) `parameters$p ]

`Expect^h `~field値$は文字大小無視である。 ◎ The Expect field value is case-insensitive.

この仕様が定義する唯一の期待は、 "`100-continue$c" である（定義される~parameterは無い）。 ◎ The only expectation defined by this specification is "100-continue" (with no defined parameters).

`Expect^h にて［ `100-continue$c 以外の~memberを包含している`~field値$ ］を受信した`~server$は、 `417$st で応答して，予期されない期待には応えられないことを指示してもヨイ。 ◎ A server that receives an Expect field value containing a member other than 100-continue MAY respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met.

`期待$ `100-continue@c は、［ `~client$は，当の要請~内に（大概は巨大な）`内容$を送信しつつあり、［ ~method, `~target~URI$, および各種~header ］が［ 即時に成功をもたらすには足らない／~redirectになる／~error応答になる ］かどうかについて，`非最終-応答$ `100$st を受信するよう望んでいる ］ことを`受信者$に伝える。 これにより、 ~clientは，~~事前に［ `内容$を送信するに~~価するかどうかの指示 ］があるまで待機できるようになり、［ ~dataが~~巨大なとき／ ~errorになる見込みが高いと~clientが見越すとき （例：以前に検証yされた認証用の`資格証$を伴わずに，初回に状態変更~methodを送信するとき） ］に効率を改善できる。 ◎ A "100-continue" expectation informs recipients that the client is about to send (presumably large) content in this request and wishes to receive a 100 (Continue) interim response if the method, target URI, and header fields are not sufficient to cause an immediate success, redirect, or error response. This allows the client to wait for an indication that it is worthwhile to send the content before actually doing so, which can improve efficiency when the data is huge or when the client anticipates that an error is likely (e.g., when sending a state-changing method, for the first time, without previously verified authentication credentials).

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

`生成元~server$は、［ `~client$が，不必要な~data転送で~pipeを埋め~~始める ］前に，［ `401$st や `405$st などの~error~message ］で即時に応答できるようになる。 ◎ allows the origin server to immediately respond with an error message, such as 401 (Unauthorized) or 405 (Method Not Allowed), before the client starts filling the pipes with an unnecessary data transfer.

`~client$に課される要件は： ◎ Requirements for clients:

• `内容$を内包しない要請~内に `100-continue$c 期待を`生成-$してはナラナイ。 ◎ A client MUST NOT generate a 100-continue expectation in a request that does not include content.
• 要請の`内容$を送信する前に， `100$st 応答を待機するつもりがあるときは、 `100-continue$c 期待を包含する `Expect^h ~headerを送信しなければナラナイ。 ◎ A client that will wait for a 100 (Continue) response before sending the request content MUST send an Expect header field containing a 100-continue expectation.
• `100-continue$c 期待を送信してから，特定の長さの時間 待機することは、 要求されない — 応答がまだ受信されないうちに，`内容$の送信を続行してもヨイ。 更には， `100$st 応答は ~HTTP10媒介者を通しては送信され得ないので、 `内容$を送信する前に不定~期間 待機するベキでない。 ◎ A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the content even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the content.
• `100-continue$c 期待を包含する要請に対する応答~内に， `417$st を受信したときは、 その要請を， `100-continue$c 期待を除いた上で繰返すベキである — この `417^st0 応答は、 単に，［ 応答の`連鎖$は、 期待を~supportしていない ］ことを指示するので （例：~HTTP10~serverを通して渡されるとき）。 ◎ A client that receives a 417 (Expectation Failed) status code in response to a request containing a 100-continue expectation SHOULD repeat that request without a 100-continue expectation, since the 417 response merely indicates that the response chain does not support expectations (e.g., it passes through an HTTP/1.0 server).

`~server$に課される要件は： ◎ Requirements for servers:

• ~HTTP10要請~内に受信された `100-continue$c 期待は、 無視しなければナラナイ。 ◎ A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore that expectation.
• 次のいずれかに該当する場合、 `100$st 応答の送信を省略してもヨイ ⇒＃ 応対した要請の`内容$の一部をすでに受信した／ ~frame法が，`内容$が無いことを指示している ◎ A server MAY omit sending a 100 (Continue) response if it has already received some or all of the content for the corresponding request, or if the framing indicates that there is no content.
• `100$st 応答を送信した後，要請の`内容$を受信して処理したなら、 接続が尚早に~closeされない限り， 最終的には `最終-応答$【！最終-状態s~code】を送信しなければナラナイ。 ◎ A server that sends a 100 (Continue) response MUST ultimately send a final status code, once it receives and processes the request content, unless the connection is closed prematurely.
• 要請の`内容$全体を読取る前に，`最終-応答$【！最終-状態s~code】で応答するときは、 次のどちらを意図するか指示するベキである ⇒＃ 接続を~closeする（例： `HTTP/1.1$r `9.6＠~HTTPv1#persistent.tear-down§ を見よ）／ `内容$の読取りを継続する ◎ A server that responds with a final status code before reading the entire request content SHOULD indicate whether it intends to close the connection (e.g., see Section 9.6 of [HTTP/1.1]) or continue reading the request content.

10.1.2. `From^h

`From^h ~headerは、［ 要請を~~発行する~UAを制御するヒト利用者 ］の~Internet~email~addressを包含する。 ~addressは、 ~machineから利用-可能な［ `5322/3.4$rfc にて定義される `mailbox^p ］になる~OUGHT： ◎ The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address ought to be machine-usable, as defined by "mailbox" in Section 3.4 of [RFC5322]:

`From@p
	= `mailbox$p

`mailbox@p
	= <mailbox, `5322/3.4$rfc>

From: spider-admin@example.org

`From^h ~headerが~robot的でない~UAにより送信されることは稀である。 `~UA$は、 利用者により明示的に環境設定されない限り， `From^h ~headerを送信するベキでない — ［ 利用者の~privacyへの関心や, それらの~siteの~security施策 ］と競合するかもしれないので。 ◎ The From header field is rarely sent by non-robotic user agents. A user agent SHOULD NOT send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests or their site's security policy.

~robot的な~UAは、 自身が［ 過度な／求まれていない／妥当でない ］要請を送信しているときなど，［ ~server上に問題が生じた場合に，~robotを稼働させている~~責務者と連絡をとれる ］ような，［ 妥当な `From^h ~header ］を送信するベキである。 ◎ A robotic user agent SHOULD send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on servers, such as if the robot is sending excessive, unwanted, or invalid requests.

`~server$は、 `From^h ~headerを［ ~access制御や認証 ］用に利用するベキでない — その値は、［ 当の要請を受信-または観測している誰からも可視になる ］ものと期待され，~log~fileや~error報告の中に — ~privacyは何ら期待されていないとみなして — 記録されることが多いので。 ◎ A server SHOULD NOT use the From header field for access control or authentication, since its value is expected to be visible to anyone receiving or observing the request and is often recorded within logfiles and error reports without any expectation of privacy.

10.1.3. `Referer^h

`Referer^h ~headerは、 次を`~UA$に許容する ⇒ `~target~URI$が，ある`資源$†から得されたものであるとき、 その資源~用の`~URI参照$を指定する。 （† すなわち， “`referrer^en（~~参照元）” — `~field名$の綴りは誤っているが。） ◎ The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the "referrer", though the field name is misspelled).＼

`~UA$は、 `Referer^h `~field値$を`生成-$するときは，~URI参照に［ `fragment$p ／ `userinfo$p ］成分 `URI$r を内包してはナラナイ。 ◎ A user agent MUST NOT include the fragment and userinfo components of the URI reference [URI], if any, when generating the Referer field value.

`Referer@p
	= `absolute-URI$p
	/ `partial-URI$p

`~field値$は、 `absolute-URI$p か `partial-URI$p をとる。 後者の事例では、 参照先の~URIは，`~target~URI$に相対的になる（ `URI$r `5§uri ）。 ◎ The field value is either an absolute-URI or a partial-URI. In the latter case (Section 4), the referenced URI is relative to the target URI ([URI], Section 5).

`Referer^h ~headerは、［ 単純な解析／~log取り／最適化された~caching／等々 ］用に［ 他の`資源$へ戻れる~linkを`生成-$する ］ことを`~server$に許容する。 それはまた、 保守~用に［ 廃用にされた／誤入力された ］~linkを見出すことも可能にする。 一部の~serverは， `Referer^h ~headerを［ 他~siteからの~link（いわゆる “`deep linking^en（深く~linkする）” ）を否認する／ ~CSRF（ `cross-site request forgery^en ）を制約する ］ための手段として利用するが、 すべての要請がそれを包含するわけではない。 ◎ The Referer header field allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc. It also allows obsolete or mistyped links to be found for maintenance. Some servers use the Referer header field as a means of denying links from other sites (so-called "deep linking") or restricting cross-site request forgery (CSRF), but not all requests contain it.

Referer: http://www.example.org/hypertext/Overview.html

`~target~URI$が［ ~URIを有さない~sourceから得されたもの ］である場合（例：利用者~keyboardからの入力, 利用者の~bookmark）、 `Referer^h ~headerを除外するか, または その値に "`about:blank^c" を送信しなければナラナイ。 ◎ If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard, or an entry within the user's bookmarks/favorites), the user agent MUST either exclude the Referer header field or send it with a value of "about:blank".

`Referer^h ~headerの`~field値$は、 参照元~資源の全部的な~URIを伝達する必要はない — `~UA$は、 参照元~URIの`生成元$以外を成す各部を切落してもヨイ。 ◎ The Referer header field value need not convey the full URI of the referring resource; a user agent MAY truncate parts other than the referring origin.

一部の`媒介者$は、［ 外向けの要請から `Referer^h ~headerを無差別に除去する ］ことが既知である。 これは、 ~CSRF攻撃に対する保護に干渉するような，~~望ましくない副作用を及ぼす — それは、 利用者にとり，はるかに有害になる。 `Referer^h 内への情報~開示を制限するよう望む［ `媒介者$／`~UA$ ］拡張は、 それらの変更を特定の編集- — 内部~domain名を `pseudonym$p に置換したり，`query$p や`path$p 成分を切落すなど — に制約する~OUGHT。 `媒介者$は、［ `Referer^h ~headerの`~field値$, `~target~URI$ ］が同じ［ `~scheme$, `~host$ ］を共有するときは， `Referer^h ~headerを改変したり削除するベキでない。 ◎ Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the unfortunate side effect of interfering with protection against CSRF attacks, which can be far more harmful to their users. Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components. An intermediary SHOULD NOT modify or delete the Referer header field when the field value shares the same scheme and host as the target URI.

10.1.4. `TE^h

`TE^h ~headerは、［ `転送~符号法$／`~trailer節$ ］に関する`~client$の能力を述べる。 ◎ The "TE" header field describes capabilities of the client with regard to transfer codings and trailer sections.

要請~内に送信された `TE^h ~fieldのうち "`trailers@c" ~memberを伴うものは、［ `~client$は`~trailer$を破棄しない ］ことを指示する。 ◎ As described in Section 6.5, a TE field with a "trailers" member sent in a request indicates that the client will not discard trailer fields.

`TE^h はまた、 ~HTTP11の中で，［［ `~client$は、 応答~内に どの`転送~符号法$を受容-可能か ］について，~serverに助言する ］ためにも利用される。 この仕様の公表~時点では、 ~HTTP11のみが`転送~符号法$を利用する。 ◎ TE is also used within HTTP/1.1 to advise servers about which transfer codings the client is able to accept in a response. As of publication, only HTTP/1.1 uses transfer codings (see Section 7 of [HTTP/1.1]).

`TE@p
	= #`t-codings$p
`t-codings@p
	= "`trailers$c"
	/ ( `transfer-coding$p [ `weight$p ] )
`transfer-coding@p
	= `token$p *( `OWS$p ";" `OWS$p `transfer-parameter$p )
`transfer-parameter@p
	= `token$p `BWS$p "=" `BWS$p ( `token$p / `quoted-string$p )

【 各~parameterを与える `transfer-parameter^p の構文は、 `BWS^p を除けば `parameter$p と一致する。 】

`TE^h の`送信者$は、 `媒介者$に この~fieldを回送しないよう伝えるため， `Connection$h ~header内に "`TE^c" `接続~option$を送信しなければナラナイ。 ◎ A sender of TE MUST also send a "TE" connection option within the Connection header field (Section 7.6.1) to inform intermediaries not to forward this field.

10.1.5. `User-Agent^h

`User-Agent@p
	= `product$p *( `RWS$p ( `product$p / `comment$p ) )

`User-Agent^h `~field値$は、 1 個~以上の `製品~識別子@ （ `product$p ）からなる — 各 `製品~識別子$には 0 個以上の~comment（ `comment$p ）が後続する。 それらは組で［ ~UA~software, その有意な下位製品 ］を識別する。 慣行により、 製品~識別子たちは［ ~UA~softwareの識別-用における有意度 ］の降順で~listされる。 各 `製品~識別子$は、 【~softwareの】［ 名前, 省略可能な~version（ `product-version$p ） ］からなる。 ◎ The User-Agent field value consists of one or more product identifiers, each followed by zero or more comments (Section 5.6.5), which together identify the user agent software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the user agent software. Each product identifier consists of a name and optional version.

`product@p
	= `token$p ["/" `product-version$p]
`product-version@p
	= `token$p

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

同様に，実装には、［ 他の実装の製品~tokenを互換性を宣言するために利用する ］ことは奨励されない — そうすると，この~fieldの目的を~~無為にするので。 別の~UAとして仮装する~UAに対しては、 `受信者$は，［ 利用者が意図的に，その別の~UA用に誂えられた応答を — それが実際に利用されている~UAで働くかどうかに関わらず — 見るよう欲している ］ものと見做せる。 ◎ Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a user agent masquerades as a different user agent, recipients can assume that the user intentionally desires to see responses tailored for that identified user agent, even if they might not work as well for the actual user agent being used.

10.2.1. `Allow^h

`Allow^h ~headerは、［ `~target資源$が~supportするものとして広告された~method ］たちを~listする。 この~fieldの目的は、［ 当の`資源$への要請において妥当になる`要請~method$ ］を`受信者$に厳密に伝えることである。 ◎ The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.

`Allow@p
	= #`method$p

Allow: GET, HEAD, PUT

許容される~methodたちが成す実際の集合は、 各~要請の時点で，`生成元~server$により定義される。 `生成元~server$は、 `405$st 応答~内には， `Allow^h ~headerを`生成-$しなければナラナイ。 また、 他のどの応答~内にも`生成-$してもヨイ。 空な `Allow^h `~field値$は、［ 当の`資源$は，どの~methodも許容しない ］ことを指示する — それは、［ 当の資源は，環境設定により一時的に不能化されている場合 ］に `405$st0 応答~内に生じ得る。 ◎ The actual set of allowed methods is defined by the origin server at the time of each request. An origin server MUST generate an Allow header field in a 405 (Method Not Allowed) response and MAY do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in a 405 response if the resource has been temporarily disabled by configuration.

`~proxy$は、 `Allow^h ~headerを改変してはナラナイ — その値の中に指示された どの~methodも、 汎用な~message取扱い規則に則って取扱うときは，解する必要はない。 ◎ A proxy MUST NOT modify the Allow header field -- it does not need to understand all of the indicated methods in order to handle them according to the generic message handling rules.

10.2.2. `Location^h

`Location^h ~headerは、 応答に関係する特定の`資源$を指すために， 一部の応答~内で利用される。 関係性の型は、［ `要請~method$, `状態s~code$ ］の意味論の組合nで定義される。 ◎ The "Location" header field is used in some responses to refer to a specific resource in relation to the response. The type of relationship is defined by the combination of request method and status code semantics.

`Location@p
	= `URI-reference$p

`~field値$は、 単独の `URI-reference$p からなる。 値が相対~参照（ `URI$r `4.2§uri ）の形をとる場合、 最終-値は，`~target~URI$に~~相対的に解決することで算出される（ `URI$r `5§uri ）。 ◎ The field value consists of a single URI-reference. When it has the form of a relative reference ([URI], Section 4.2), the final value is computed by resolving it against the target URI ([URI], Section 5).

`Location^h の値は： ◎ ↓

• `201$st 応答においては、 要請により作成された`首な資源$を指す。 ◎ For 201 (Created) responses, the Location value refers to the primary resource created by the request.＼
• `3xx$st 応答においては、 要請を自動的に~redirectするときに選好される`~target資源$を指す。 ◎ For 3xx (Redirection) responses, the Location value refers to the preferred target resource for automatically redirecting the request.

後者の場合，当の値に素片~成分（ `fragment$p ）が無い場合、 `~UA$は，当の~redirectionを［ 当の値は［ `~target~URI$を`生成-$するときに利用した`~URI参照$ ］の素片~成分を継承している ］かのように処理しなければナラナイ （すなわち，~redirectionは、 元の参照に素片があるならば，それを継承する）。 ◎ If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the target URI (i.e., the redirection inherits the original reference's fragment, if any).

Location: /People.html#tim

Location: http://www.example.net/index.html

`Location^h 値~内の素片~識別子が，適切でなくなる状況もある： 例えば，［ `201$st 応答~内の `Location^h ~header ］は、［ 作成された`資源$に特有な~URI ］を供するものと仮定されることになる。 ◎ There are circumstances in which a fragment identifier in a Location value would not be appropriate. For example, the Location header field in a 201 (Created) response is supposed to provide a URI that is specific to the created resource.

注記： 一部の`受信者$は、［ `Location^h ~headerの`~URI参照$が妥当でない ］ときに，その回復を試みる。 この仕様は，そのような処理を義務化したり定義しないが、 堅牢性の~~目的で，それを許容する。 `Location^h の`~field値$は、 ~memberたちが成す~listを許容し得ない — ~list分離子である~commaは、 `URI-reference$p の中でも妥当な~data文字なので。 複数個の `Location$h `~field行l$を伴う妥当でない~messageが送信された場合、 当の経路~上の ある`受信者$は，それらの~field行lを一つに`結合-$するかもしれない。 その状況から妥当な `Location^h `~field値$を回復するのは、 困難であり，各 実装~間で相互運用可能にならない。 ◎ Note: Some recipients attempt to recover from Location header fields that are not valid URI references. This specification does not mandate or define such processing, but does allow it for the sake of robustness. A Location field value cannot allow a list of members because the comma list separator is a valid data character within a URI-reference. If an invalid message is sent with multiple Location field lines, a recipient along the path might combine those field lines into one value. Recovery of a valid Location field value from that situation is difficult and not interoperable across implementations.

注記： `Content-Location$h ~headerは、 それが［ 同封された`表現$に対応する最も特定な`資源$ ］を指す点で， `Location^h から相違する。 したがって、 応答が［ `Location^h, `Content-Location$h ］両~headerを包含することもアリである。 ◎ Note: The Content-Location header field (Section 8.7) differs from Location in that the Content-Location refers to the most specific resource corresponding to the enclosed representation. It is therefore possible for a response to contain both the Location and Content-Location header fields.

10.2.3. `Retry-After^h

~serverは、［ ~UAが後継の要請を為す前に，いつまで待機する~OUGHT ］かを指示するために， `Retry-After^h ~headerを送信する。 `503$st 応答に伴って送信されてきた `Retry-After^h は、［ 当の~serviceが~clientに可用でないと予期されるのは、 いつまでか ］を指示する。 `3xx$st 応答に伴って送信されてきた `Retry-After^h は、［ ~redirect要請を発行する前に，~UAに待機するよう依頼する最短な時間 ］を指示する。 ◎ Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request. When sent with a 503 (Service Unavailable) response, Retry-After indicates how long the service is expected to be unavailable to the client. When sent with any 3xx (Redirection) response, Retry-After indicates the minimum time that the user agent is asked to wait before issuing the redirected request.

`Retry-After^h の`~field値$は、 次のいずれかをとる ⇒＃ 【日時を与える】 `HTTP-date$p ／ 応答を受信してからの遅延~秒数【を与える `delay-seconds$p 】 ◎ The Retry-After field value can be either an HTTP-date or a number of seconds to delay after receiving the response.

`Retry-After@p
	= `HTTP-date$p
	/ `delay-seconds$p

`delay-seconds$p 値は、 秒数を表現する負でない~decimal整数である。 ◎ A delay-seconds value is a non-negative decimal integer, representing time in seconds.

`delay-seconds@p
	= 1*`DIGIT$P

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

10.2.4. `Server^h

`Server@p
	= `product$p *( `RWS$p ( `product$p / `comment$p ) )

`Server^h ~headerの`~field値$は、 1 個~以上の`製品~識別子$からなる — 各 `製品~識別子$には 0 個以上の `comment$p が後続する。 それらは組で［ 生成元~serverの~software, その有意な下位製品 ］を識別する。 慣行により、 製品~識別子たちは［ 生成元~serverの~softwareの識別-用における有意度 ］の降順で~listされる。 各 `製品~識別子$は、 それに定義されるとおり，【~softwareの】［ 名前, 省略可能な~version ］からなる。 ◎ The Server header field value consists of one or more product identifiers, each followed by zero or more comments (Section 5.6.5), which together identify the origin server software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the origin server software. Each product identifier consists of a name and optional version, as defined in Section 10.1.5.

Server: CERN/3.0 libwww/2.17

`生成元~server$は、［ ~~不必要に木目細かな詳細を包含する `Server^h ~header ］を`生成-$するベキでない。 また、［ 第三者-主体による下位製品の追加 ］を制限するベキである。 ~~過度に長く詳細な `Server^h `~field値$は、 応答の待時間を増やすのみならず， 内部~実装の詳細を露呈しかねないので、 攻撃者が既知な~securityの穴を見出して悪用することも（少しばかり）容易になる。 ◎ An origin server SHOULD NOT generate a Server header field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed Server field values increase response latency and potentially reveal internal implementation details that might make it (slightly) easier for attackers to find and exploit known security holes.

11.6.1. `WWW-Authenticate^h

`WWW-Authenticate^h 応答~headerは、 `~target資源$に適用-可能な［ `認証~scheme$たち, および `認証~parameter$たち ］を指示する。 ◎ The "WWW-Authenticate" response header field indicates the authentication scheme(s) and parameters applicable to the target resource.

`WWW-Authenticate@p
	= #`challenge$p

`401$st 応答を`生成-$する`~server$は、［ 1 個~以上の `challenge$p を包含する， `WWW-Authenticate^h ~header ］を送信しなければナラナイ。 ~serverは、 他の応答~message内にも， `WWW-Authenticate^h ~headerを`生成-$してもヨイ — 【後の要請に】 `資格証$（または異なる`資格証$）を給することが， 対する応答に影響し得ることを指示するために。 ◎ A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge. A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response.

応答を回送している`~proxy$は、 その応答~内の `WWW-Authenticate^h ~headerを改変してはナラナイ。 ◎ A proxy forwarding a response MUST NOT modify any WWW-Authenticate header fields in that response.

`~UA$には、 `~field値$を構文解析するときには特別に~careすることを~~勧める — それは，複数個の `challenge$p を包含するかもしれず、 各 `challenge$p も［ ~commaで分離された`認証~parameter$たちが成す~list ］を包含し得るので。 更には、 この~header自体も複数~回 生じ得る。 ◎ User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times.

WWW-Authenticate: Basic realm="simple", Newauth realm="apps", type=1, title="Login to \"apps\""

しかしながら、 一部の~UAは，この形を認識しない。 結果として、［ `WWW-Authenticate^h の`~field値$を同じ`~field行l$に複数個の~memberを伴わせて送信する ］ことは，相互運用可能にならないかもしれない。 ◎ Some user agents do not recognize this form, however. As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable.

注記： `challenge$p 文法~生成規則も~list構文を利用する。 したがって，［ ~comma, 空白, ~comma ］が成す連列は、［ 先行している `challenge$p に適用するもの ］としても, ［ `challenge$p たちが成す~listにおける，空な~entry ］としても見なせる。 実施においては，この多義性は、 当の~headerの`~field値$の意味論に影響しないので，無害である。 ◎ Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value and thus is harmless.

11.6.2. `Authorization^h

`Authorization^h 【要請】~headerにより、 `~UA$は，自身を`生成元~server$から認証してもらうことが可能になる — 必要とされてはいないが通例的には， `401$st 応答を受信した後に。 その値は、［ 要請-中にある`資源$の `realm$c 用の，`~UA$の認証~情報 ］を包含する`資格証$からなる。 ◎ The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

`Authorization@p
	= `credentials$p

要請が認証され, かつ `realm$c も指定されている場合、 同じ`資格証$は，［ この `realm$c に属する 他のすべての要請に対しても，妥当である ］ものと予め見做されるようになる（`認証~scheme$自体が，他のもの — ［ `challenge$p 値に則って, あるいは同期された`時計$を利用して ］様々になるような`資格証$など — を要求しない限りにおいて）。 ◎ If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

要請を回送している`~proxy$は、 その要請~内のどの `Authorization^h ~headerも，改変してはナラナイ。 ~HTTP~cacheによる `Authorization^h ~headerの取扱い［ の詳細／に課される要件 ］については、 `CACHING$r `認証-済み要請に対する応答の格納-法＠~HTTPcache#caching.authenticated.responses§ を見よ。 ◎ A proxy forwarding a request MUST NOT modify any Authorization header fields in that request. See Section 3.5 of [CACHING] for details of and requirements pertaining to handling of the Authorization header field by HTTP caches.

11.6.3. `Authentication-Info^h

~HTTP`認証~scheme$では、 `~client$の認証用の`資格証$を受容した後に， `Authentication-Info^h 応答~fieldを利用して情報を通信できる。 この情報は~serverからの【認証の】完結~messageを内包し得る（例：~server認証を包含し得る）。 ◎ HTTP authentication schemes can use the "Authentication-Info" response field to communicate information after the client's authentication credentials have been accepted. This information can include a finalization message from the server (e.g., it can contain the server authentication).

その`~field値$は、 `auth-param$p 構文を利用する~parameter（名前, 値が成す~pair）たちが成す~listである。 この仕様は、 汎用な形式のみを述べる — 個々の~parameterは、 `Authentication-Info^h を利用している`認証~scheme$が定義することになる。 一例として， `Digest^c 認証~schemeは、 `7616/3.5$rfc にて複数の~parameterを定義する。 ◎ The field value is a list of parameters (name/value pairs), using the "auth-param" syntax defined in Section 11.3. This specification only describes the generic format; authentication schemes using Authentication-Info will define the individual parameters. The "Digest" Authentication Scheme, for instance, defines multiple parameters in Section 3.5 of [RFC7616].

`Authentication-Info@p
	= #`auth-param$p

`Authentication-Info^h ~fieldは、 `要請~method$や`状態s~code$とは独立に，どの~HTTP応答にも利用できる。 その意味論は、［ それが応対した要請の `Authorization$h ~headerにより指示される`認証~scheme$ ］により定義される。 ◎ The Authentication-Info field can be used in any HTTP response, independently of request method and status code. Its semantics are defined by the authentication scheme indicated by the Authorization header field (Section 11.6.2) of the corresponding request.

応答を回送している`~proxy$には、 どの仕方であろうと，`~field値$を改変することは許容されない。 ◎ A proxy forwarding a response is not allowed to modify the field value in any way.

`Authentication-Info^h は、 `認証~scheme$が明示的に許容するときには，`~trailer$として送信され得る（ `6.5§ ）。 ◎ Authentication-Info can be sent as a trailer field (Section 6.5) when the authentication scheme explicitly allows this.

11.7.1. `Proxy-Authenticate^h

`Proxy-Authenticate^h 【応答】~headerは、 1 個~以上の `challenge$p からなる — 各 `challenge^p は、 この【~~今後の？】要請~用に`~proxy$に適用-可能な［ `認証~scheme$, `認証~parameter$たち ］を指示する。 `~proxy$は、 自身が`生成-$する各 `407$st 応答~内に 1 個~以上の `Proxy-Authenticate^h ~headerを送信しなければナラナイ。 ◎ The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy for this request. A proxy MUST send at least one Proxy-Authenticate header field in each 407 (Proxy Authentication Required) response that it generates.

`Proxy-Authenticate@p
	= #`challenge$p

`WWW-Authenticate$h と違って、 `Proxy-Authenticate^h ~headerが適用されるのは，［ 応答`連鎖$の`外方$にある次の`~client$ ］に限られる — 当の`~proxy$を選んだ`~client$のみが，認証に必要yな`資格証$を有するものと見込まれるので。 しかしながら， 同じ管轄の中で複数の~proxyが利用されるとき — 巨大~企業~networkの中の，各~~部署の~caching~proxyなど — は、［ `~UA$により`生成-$された`資格証$が，消費されるまで階層を通過する ］ことは共通的にある。 よって，そのような環境設定の下では、 各~proxyは同じ `challenge$p 集合を送信することになり， `Proxy-Authenticate^h は回送されているかのように出現することになる。 ◎ Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authenticate is being forwarded because each proxy will send the same challenge set.

`WWW-Authenticate$h ~headerの構文解析に対する考慮点は、 この~fieldにも適用されることに注意。 ◎ Note that the parsing considerations for WWW-Authenticate apply to this header field as well; see Section 11.6.1 for details.

11.7.2. `Proxy-Authorization^h

`Proxy-Authorization@p
	= `credentials$p

`Authorization$h と違って， `Proxy-Authorization^h ~headerが適用されるのは、［ `Proxy-Authenticate$h ~headerを利用して認証を請求した，`内方$にある次の`~proxy$ ］に限られる。 `連鎖$にて複数の~proxyが利用されているときは、 `Proxy-Authorization^h ~headerは，［ `資格証$の受信を期待していた~proxyのうち，`内方$にある最初のもの ］により消費される。 複数の~proxyが，所与の要請を協力的に認証する仕組みを成している場合、 それらに属する~proxyは，~client要請からの`資格証$を 次の~proxyへ中継してもヨイ。 ◎ Unlike Authorization, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the Proxy-Authenticate header field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

11.7.3. `Proxy-Authentication-Info^h

`Proxy-Authentication-Info^h 応答~headerは、 次を除き， `Authentication-Info$h に等価である ⇒ この~headerは，~proxy認証（ `11.3§ ）に適用され、 その意味論は，［ 応対した要請の `Proxy-Authorization$h ~headerに指示される`認証~scheme$ ］により定義される。 ◎ The "Proxy-Authentication-Info" response header field is equivalent to Authentication-Info, except that it applies to proxy authentication (Section 11.3) and its semantics are defined by the authentication scheme indicated by the Proxy-Authorization header field (Section 11.7.2) of the corresponding request:

`Proxy-Authentication-Info@p
	= #`auth-param$p

しかしながら， `Authentication-Info$h と違って、 `Proxy-Authentication-Info^h ~headerが適用されるのは，応答`連鎖$において`外方$にある次の`~client$に限られる — 当の`~proxy$を選んだ`~client$のみが，認証に必要yな`資格証$を有するものと見込まれるので。 しかしながら，同じ管轄の中で複数の~proxyが利用されるときは — 巨大~企業~networkの中の，各~~部署の~caching~proxyなど — `~UA$により`生成-$された`資格証$が，消費されるまで階層を通過することは、 共通的にある。 よって，そのような環境設定の下では、 各~proxyが同じ`~field値$を送信することになり， `Proxy-Authentication-Info^h は回送されているかのように出現することになる。 ◎ However, unlike Authentication-Info, the Proxy-Authentication-Info header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authentication-Info is being forwarded because each proxy will send the same field value.

`Proxy-Authentication-Info^h は、 `認証~scheme$が明示的に許容するときには，`~trailer$として送信され得る（ `6.5§ ）。 ◎ Proxy-Authentication-Info can be sent as a trailer field (Section 6.5) when the authentication scheme explicitly allows this.

12.4.1. 選好の不在

各 内容~折衝~fieldに対し、 それを包含しない要請は，［ 当の~headerが表す［ 折衝の次元 ］に関しては、 `送信者$の選好は無い ］ことを含意する。 ◎ For each of the content negotiation fields, a request that does not contain the field implies that the sender has no preference on that dimension of negotiation.

ある内容~折衝~headerが要請~内に在って，［ 対する応答~用に可用な表現のうち，その~headerに則って受容-可能と見なせるもの ］は無い場合、 `生成元~server$は，［ `406$st 応答を送信して，その~headerを尊守する ］ことも［ 応答を`内容~折衝$の~subjectではないかのように扱って，その~headerを無視rする ］こともできる。 しかしながら，これ【送信者の選好は無いこと】は、［ ~clientは、 その表現を利用-可能になる ］ことを含意するものではない。 ◎ If a content negotiation header field is present in a request and none of the available representations for the response can be considered acceptable according to it, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation for that request header field. This does not imply, however, that the client will be able to use the representation.

注記： ~UAが これらの~headerを送信すると、 ~serverにとっては， ~UAからの要請の特性から各個人を識別することが より容易になる（ `17.13§ ）。 ◎ Note: A user agent sending these header fields makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (Section 17.13).

12.4.2. 品質~値

この仕様が定義する内容~折衝~用の`~field$は、［ 相対的な選好の “重み” を，結付けられる内容の種類にアテガう ］ために，［ `q$c と命名される（文字大小無視な）共通な~parameter ］を利用する。 この重みは、 同じ~parameter名が，~server環境設定の中で［ `資源$用に選定され得る様々な`表現$の，相対的な品質の重み ］をアテガうために利用されることが多いため、 `品質~値@ （ `quality value^en, 略して `qvalue^en ） と称される。 ◎ The content negotiation fields defined by this specification use a common parameter, named "q" (case-insensitive), to assign a relative "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue") because the same parameter name is often used within server configurations to assign a weight to the relative quality of the various representations that can be selected for a resource.

重みは、 0 以上 1 以下の実数【小数部 3 桁以下の 10 進数】に正規化される — ここで，値［ 0.001 は最も選好されない／ 1 は最も選好される／ 0 は “受容-可能でない” ］ことを意味する。 `q$c ~parameterが無い場合の `既定の重み@ は 1 とする。 ◎ The weight is normalized to a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; a value of 0 means "not acceptable". If no "q" parameter is present, the default weight is 1.

`weight@p
	= `OWS$p ";" `OWS$p "`q@c=" `qvalue$p
`qvalue@p
	= ( "0" [ "." 0*3`DIGIT$P ] )
	/ ( "1" [ "." 0*3("0") ] )

`送信者$が，小数点の後に`生成-$する品質値の桁~数は、 3 以下でなければナラナイ。 利用者~環境設定における これらの値も，同じ流儀で制限される~OUGHT。 ◎ A sender of qvalue MUST NOT generate more than three digits after the decimal point. User configuration of these values ought to be limited in the same fashion.

12.4.3. ~wildcard値

これらの~headerのほとんどは、 指示される所では，［ 未指定な値を選定するための，~wildcard値（ "`*^c" ） ］を定義する。 ~wildcardは無い場合、［ ~clientは、 その~field内に明示的に挙げられなかった どの値も受容-不能である ］ものと見なされる。 ただし， `Vary$h の中では、 【挙げられなかった値（~field名）に対する】変動は制限されないことを意味する。 ◎ Most of these header fields, where indicated, define a wildcard value ("*") to select unspecified values. If no wildcard is present, values that are not explicitly mentioned in the field are considered unacceptable. Within Vary, the wildcard value means that the variance is unlimited.

注記： 実施においては、 内容~折衝に利用される~wildcardの実用的な価値は，制限される — 例えば、 “多少を問わず，何か（何らかの特定の値）より `image/*^c を選好します” と言っても，有用になることは滅多にないので。 ~clientは、 `Accept: */*;q=0^c を送信することにより，［ より選好される形式は可用でない場合には、 `406$st0 応答を送信する ］よう明示的に要請できるが、 それでも，他の応答を取扱える必要がある — ~serverには、 ~clientの選好を無視することも許容されるので。 ◎ Note: In practice, using wildcards in content negotiation has limited practical value because it is seldom useful to say, for example, "I prefer image/* more or less than (some other specific value)". By sending Accept: */*;q=0, clients can explicitly request a 406 (Not Acceptable) response if a more preferred format is not available, but they still need to be able to handle a different response since the server is allowed to ignore their preference.

12.5.1. `Accept^h

`~UA$は、 `Accept^h ~headerを利用して，応答の`~MIME型$に関する自身の選好を指定できる。 例えば、 要請が［ 自身が欲する型たちが成す小さな集合に，特定的に制限される ］ことを指示するときに利用できる — ~inline画像~用の要請など。 ◎ The "Accept" header field can be used by user agents to specify their preferences regarding response media types. For example, Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.

~serverにより送信された応答~内の `Accept^h は、［ 同じ`資源$に対する後続な要請 ］の`内容$には［ どの内容~型が選好されるか ］についての情報を供する。 ◎ When sent by a server in a response, Accept provides information about which content types are preferred in the content of a subsequent request to the same resource.

`Accept@p
	= #( `media-range$p [ `weight$p ] )

`media-range@p
	= ( "*/*"
	    / ( `type$p "/" "*" )
	    / ( `type$p "/" `subtype$p )
	  ) `parameters$p

`media-range$p における文字~asterisk "`*^c" は、 `~MIME型$たちをある範囲に~group化するために利用される ⇒＃ "`*/*^c" は，すべての~MIME型を指示する／ "%type`/*^c" は， %type ~MIME型を成すすべての下位型を指示する。 ◎ The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type.＼

`media-range$p には、 その範囲に入る~MIME型に適用-可能な`~MIME型~parameter$も内包できる。 ◎ The media-range can include media type parameters that are applicable to that range.

以前の仕様は、 `weight$p ~parameterの後に，追加的な拡張~parameter（ `accept-params^p, `accept-ext^p ）が出現することを許容していた。 この拡張~文法は、 除去された — それは、 定義を複雑化しており， 実施において利用されておらず， 新たな~headerを通して もっと容易に配備できるので。 `weight$p を利用している`送信者$は、 最後に "`q^c" を送信するベキである （ `media-range$p を成す すべての~parameterより後に）。 `受信者$は、 ~parameterの順序付けを問わず， "`q^c" と命名される~parameterが在るならば `weight$p として処理するベキである。 【 `parameters$p は `weight$p の構文も包摂するので。】 ◎ Previous specifications allowed additional extension parameters to appear after the weight parameter. The accept extension grammar (accept-params, accept-ext) has been removed because it had a complicated definition, was not being used in practice, and is more easily deployed through new header fields. Senders using weights SHOULD send "q" last (after all media-range parameters). Recipients SHOULD process any parameter named "q" as weight, regardless of parameter ordering.

注記： `内容~折衝$を制御するための~parameter名 "`q^c" の利用は、 同じ名前を伴う`~MIME型~parameter$に干渉することになる。 よって、 ~MIME型~registryは， "`q^c" と命名される~parameterを許容しない。 ◎ Note: Use of the "q" parameter name to control content negotiation would interfere with any media type parameter having the same name. Hence, the media type registry disallows parameters named "q".

Accept: audio/*; q=0.2, audio/basic

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

`media-range$p は、 より特定な［ `media-range$p ／ `~MIME型$ ］で上書きできる。 所与の型に，複数の `media-range$p が適用されている場合、 最も特定な参照が優先される。 ◎ Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence.＼

Accept: text/*, text/plain, text/plain;format=flowed, */*

所与の型に結付けられる`~MIME型$の品質~係数は、［ 型に合致する，最も優先される `media-range$p ］を見出すことにより決定される。 ◎ The media type quality factor associated with a given type is determined by finding the media range with the highest precedence that matches the type.＼

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
        text/plain;format=fixed;q=0.4, */*;q=0.5

注記： ~UAは、 ある種の範囲の~media用に，既定の［ `品質~値$たちが成す集合 ］を供するかもしれない。 しかしながら，~UAが［ 他の具現化~agentとヤリトリし得ない閉な~system ］でない限り、 この既定の集合は，利用者により環境設定-可能になる~OUGHT。 ◎ Note: A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent is a closed system that cannot interact with other rendering agents, this default set ought to be configurable by the user.

12.5.2. `Accept-Charset^h

`~UA$は、 `Accept-Charset^h ~headerを送信して，［ ~textな［ 応答の`内容$ ］における`~charset$ ］に対する自身の選好を指示できる。 この~fieldは、 例えば次を~UAに許容する ⇒ ［ より包括的な／より特別な目的~用の ］~charsetを解する能力がある場合に、 その能力を［ そのような~charsetで情報を表現する能力がある`生成元~server$ ］へ通達する。 ◎ The "Accept-Charset" header field can be sent by a user agent to indicate its preferences for charsets in textual response content. For example, this field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets.

`Accept-Charset@p
	= #( ( `token$p / "*" ) [ `weight$p ] )

~charset名（ `token^p ）は、 `8.3.2§ にて定義される。 `~UA$は、 各~charsetに［ 利用者の選好度を指示する`品質~値$ ］を結付けてもヨイ。 ◎ Charset names are defined in Section 8.3.2. A user agent MAY associate a quality value with each charset to indicate the user's relative preference for that charset, as defined in Section 12.4.2.＼

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

`Accept-Charset^h ~headerにおける特別な値 "`*^c" は、 在るならば，その~field内に挙げられていない どの`~charset$にも合致する。 ◎ The special value "*", if present in the Accept-Charset header field, matches every charset that is not mentioned elsewhere in the field.

注記： `Accept-Charset^h は、 非推奨にされた。 ~UTF-8がほぼアタリマエになったことに加え， 利用者が選好する~charsetたちが成す詳細な~listの送信は［ 帯域幅を浪費する, 待時間を増やす, 受動的な指紋収集をずっと容易にする（ `17.13§ ） ］ので。 ほとんどの一般用~UAは、 `Accept-Charset^h を送信しない — そうするよう特定的に環境設定されない限り。 ◎ Note: Accept-Charset is deprecated because UTF-8 has become nearly ubiquitous and sending a detailed list of user-preferred charsets wastes bandwidth, increases latency, and makes passive fingerprinting far too easy (Section 17.13). Most general-purpose user agents do not send Accept-Charset unless specifically configured to do so.

12.5.3. `Accept-Encoding^h

`Accept-Encoding^h ~headerは、 `内容~符号法$に関する選好を指示するために利用できる： ◎ The "Accept-Encoding" header field can be used to indicate preferences regarding the use of content codings (Section 8.4.1).

• `~UA$により送信された要請~内の `Accept-Encoding^h は、 対する応答において受容-可能な`内容~符号法$を指示する。 ◎ When sent by a user agent in a request, Accept-Encoding indicates the content codings acceptable in a response.
• `~server$により送信された応答~内の `Accept-Encoding^h は、［ 同じ`資源$に対する後続な要請 ］の`内容$には［ どの`内容~符号法$が選好されるか ］についての情報を供する。 ◎ When sent by a server in a response, Accept-Encoding provides information about which content codings are preferred in the content of a subsequent request to the same resource.

"`identity@c" ~tokenは、 選好する符号化は無いことを通信するための， “符号化しない” の同義語として利用される。 ◎ An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred.

`Accept-Encoding@p
	= #( `codings$p [ `weight$p ] )
`codings@p
	= `content-coding$p / "`identity$c" / "*"

各 符号法~値（ `codings$p ）には、 `品質~値$（ `weight$p ）を与えてもヨイ — それは、 その符号化法に結付けられる選好~度を表現する。 `Accept-Encoding^h ~header内の記号~asterisk "`*^c" は、 可用な`内容~符号法$のうち［ 当の~field内に明示的に~listされなかったもの ］すべてに合致する。†a ◎ Each codings value MAY be given an associated quality value (weight) representing the preference for that encoding, as defined in Section 12.4.2. The asterisk "*" symbol in an Accept-Encoding field matches any available content coding not explicitly listed in the field.

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

12.5.4. `Accept-Language^h

`~UA$は、 `Accept-Language^h ~headerを利用して，次を指示できる ⇒ 応答にて選好される自然~言語（`言語~tag$）たちが成す集合 ◎ The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Language tags are defined in Section 8.5.1.

`Accept-Language@p
	= #( `language-range$p [ `weight$p ] )
`language-range@p
	= <language-range, `4647/2.1$rfc>

各 `language-range$p には、 次を与えれる ⇒ ［ それが指定する言語~範囲 ］に結付けられる［ 利用者の選好についての見積もり ］を表現する`品質~値$ ◎ Each language-range can be given an associated quality value representing an estimate of the user's preference for the languages specified by that range, as defined in Section 12.4.2.＼

Accept-Language: da, en-gb;q=0.8, en;q=0.7

一部の`受信者$は — 特に，等しい`品質~値$がアテガわれた`言語~tag$たちに対し — `言語~tag$が~listされた順序を，優先度~順の指示として扱うことに注意 （どの~tagの品質値も 1 でなくなる）。 しかしながら、 この挙動には依拠できない。 多くの~UAは、 一貫性を得るため, および 相互運用能を最大化するため、 各`言語~tag$に一意な`品質~値$をアテガった上で，それらを品質の降順で~listする。 言語~優先度~listについての追加的な論点は、 `4647/2.3$rfc に見出せる。 ◎ Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon. For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also listing them in order of decreasing quality. Additional discussion of language priority lists can be found in Section 2.3 of [RFC4647].

`4647/3$rfc は、 数種の照合~schemeを，照合~用に定義している。 実装は、 自身の要件に最も適切な照合~schemeを提供できる。 "Basic Filtering" ~scheme（ `4647/3.3.1$rfc ）は、 以前に［ `2616/14.4$rfc にて，~HTTP用として定義された照合~scheme ］と一致する。 ◎ For matching, Section 3 of [RFC4647] defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is identical to the matching scheme that was previously defined for HTTP in Section 14.4 of [RFC2616].

毎~要請ごとに［ 完全な，利用者の言語上の選好 ］を伴う `Accept-Language^h ~headerを送信するのは、 利用者が期待する~privacyに反し得る（ `17.13§ ）。 ◎ It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic preferences of the user in every request (Section 17.13).

言語の理解度は，個々の利用者に大きく依存するので、 `~UA$は，言語上の選好を制御することを利用者に許容する必要がある （~UAの環境設定を通して, あるいは 利用者が制御できる~system設定による既定により）。 そのような制御を利用者に供さない`~UA$は、 `Accept-Language^h ~headerを送信してはナラナイ。 ◎ Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic preference (either through configuration of the user agent itself or by defaulting to a user controllable system setting). A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field.

注記： `~UA$は、 選好の設定~時に，利用者~向けの指導を供する~OUGHT — 利用者が，上に述べた言語~照合の詳細~に~~馴染んでいることは、 稀なので。 例えば，利用者は、［ "`en-gb^c" を選定すれば、 英国~英語が可用でなくても，どの種類の英語~文書であれ~serveされるようになる ］ものと見做すかもしれない。 ~UAは，そのような事例では、 照合の挙動を もっと良くするためとして， ~listに "`en^c" を追加するよう示唆できる。 ◎ Note: User agents ought to provide guidance to users when setting a preference, since users are rarely familiar with the details of language matching as described above. For example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest, in such a case, to add "en" to the list for better matching behavior.

12.5.5. `Vary^h

応答~内の `Vary^h ~headerは、［ ~method／`~target~URI$ ］の他に，応対した要請~messageを成すどの部分が［ `生成元~server$による，この応答の`内容$を選定するための処理n ］に波及し得たかを述べる。 ◎ The "Vary" header field in a response describes what parts of a request message, aside from the method and target URI, might have influenced the origin server's process for selecting the content of this response.

`Vary@p
	= #( "*" / `field-name$p )

`Vary^h の`~field値$は，`~listに基づく~field$であり、 それを成す各~memberは， ~wildcard "`*^c" または［ `選定用~header@ （ `selecting header field^en ）とも呼ばれる，この応答~用の`表現$を選定する役割を担い得た要請~field名 ］を与える。 選定用~headerになり得るものは、 この仕様が定義する~fieldに制限されない。 ◎ A Vary field value is either the wildcard member "*" or a list of request field names, known as the selecting header fields, that might have had a role in selecting the representation for this response. Potential selecting header fields are not limited to fields defined by this specification.

この~listが "`*^c" を包含する場合、 要請の他の側面 — 場合によっては、 ~message構文の外側にある側面も含む （例：~clientの~network~address） — が，応答の`表現$を選定する役割を担い得たことを通達する。 `受信者$は、 この応答が今後の【以前の要請と一致する】要請にも適切になるかどうかを — 要請を`生成元~server$へ回送しない限り — 決定できないことになる。 `~proxy$は、 `Vary^h の`~field値$内に "`*^c" を`生成-$してはナラナイ。 ◎ A list containing the member "*" signals that other aspects of the request might have played a role in selecting the response representation, possibly including aspects outside the message syntax (e.g., the client's network address). A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server. A proxy MUST NOT generate "*" in a Vary field value.

Vary: accept-encoding, accept-language

`~field名$たちが成す~listを包含している `Vary^h ~fieldには、 次に挙げる 2 つの目的がある： ◎ A Vary field containing a list of field names has two purposes:

• `~cache$たちに，次を伝える ⇒ この応答は、 ~OR↓ が満たされない限り， 今後の要請を満足するために利用してはナラナイ： ◎ To inform cache recipients that they MUST NOT use this response to satisfy a later request unless

  • 要請は、 ~listされた~headerについて，元の要請と同じ値をとる （ `CACHING$r `4.1＠~HTTPcache#caching.negotiated.responses§ ） ◎ the later request has the same values for the listed header fields as the original request (Section 4.1 of [CACHING]) or＼
  • 当の応答の再利用は、`生成元~server$により検証-済みである ◎ reuse of the response has been validated by the origin server.＼

  言い換えれば `Vary^h は、［ 新たな要請が，格納-済みな~cache~entryに合致する ］ために要求される~cache~keyを拡げる。 ◎ In other words, Vary expands the cache key required to match a new request to the stored cache entry.

• `~UA$に，次を伝える ⇒ この応答は，`内容~折衝$の~subjectであったので、 ~listされたいずれかの~header内に他の値が供される場合には， 後続な要請に対し異なる`表現$が送信され得る（`~proactive折衝$）。 ◎ To inform user agent recipients that this response was subject to content negotiation (Section 12) and a different representation might be sent in a subsequent request if other values are provided in the listed header fields (proactive negotiation).

`生成元~server$は、［ `~cache可能$な応答に対し，後続な要請~用にも選択的に再利用するよう望む ］ときは， `Vary^h ~headerを`生成-$するベキである。 これに該当する事例は、 一般に，当の応答の`内容$が［ その`選定用~header$により表出される選好に，より良く収まる ］よう誂えられたときである — 生成元~serverが［ 要請の `Accept-Language$h ~headerに基づいて応答の言語を選定したとき ］など。 ◎ An origin server SHOULD generate a Vary header field on a cacheable response when it wishes that response to be selectively reused for subsequent requests. Generally, that is the case when the response content has been tailored to better fit the preferences expressed by those selecting header fields, such as when an origin server has selected the response's language based on the request's Accept-Language header field.

`Vary^h は、 次に該当する場合には省かれるかもしれない ⇒ `生成元~server$は、［ `Vary^h による~cachingに対する処理能の影響iの方が， 内容~選定における変動より有意である ］と見なすとき — 特に、 応答`~cache指令$により，すでに再利用が制限されているとき。 ◎ Vary might be elided when an origin server considers variance in content selection to be less significant than Vary's performance impact on caching, particularly when reuse is already limited by cache response directives (Section 5.2 of [CACHING]).

`~field名$ `Authorization$h は、［ その定義により，複数~利用者にまたがる応答の再利用が禁制される ］ので， `Vary^h 内に送信する必要はない。 同様に，応答の`内容$は~network領域†により［ 選定された／波及された ］が，`生成元~server$は［ `受信者$が ある領域から別の領域へ移動した場合でも，~cache済み応答が再利用される ］よう求める場合、 生成元~serverは， `Vary^h 内でそのような変動を指示する必要はない。 ◎ There is no need to send the Authorization field name in Vary because reuse of that response for a different user is prohibited by the field definition (Section 11.6.2). Likewise, if the response content has been selected or influenced by network region, but the origin server wants the cached response to be reused even if recipients move from one region to another, then there is no need for the origin server to indicate such variance in Vary.

【† `network region^en — 何らかの正式な定義がある用語なのかどうか，定かでない。 】

13.1.1. `If-Match^h

`If-Match^h ~headerは、 `受信者$である`生成元~server$に対し，`要請~method$を次による条件付きにする： ◎ The "If-Match" header field makes the request method conditional on＼

• `~target資源$の現在の`表現$からなる集合を %S とするとき、 `~field値$に応じて： ◎ the recipient origin server either＼

  • "`*^c" の場合 ⇒ %S は空でない。 ◎ having at least one current representation of the target resource, when the field value is "*", or＼
  • `実体~tag$たちが成す~listである場合 ⇒ %S 内に［ ~list内の ある~memberに合致する`実体~tag$ ］を有するものがある。 ◎ having a current representation of the target resource that has an entity tag matching a member of the list of entity tags provided in the field value.
• `生成元~server$は、 `If-Match^h 用の`実体~tag$を比較するときには，`強い比較~関数$を利用しなければナラナイ — `~client$が この`事前条件$に意図しているのは、［ `表現~data$に何か変化があった場合には，~methodを適用しない ］ことなので。 ◎ An origin server MUST use the strong comparison function when comparing entity tags for If-Match (Section 8.8.3.2), since the client intends this precondition to prevent the method from being applied if there have been any changes to the representation data.

`If-Match@p
	= "*" / #`entity-tag$p

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

`If-Match^h は、［ 同じ`資源$に対し，複数の~UAが並列的に動作し得る ］ときの，偶発的な上書-（すなわち， “`更新喪失$” 問題）を防止するために， 状態変更~method（例：`POST$m, `PUT$m, `DELETE$m ）と伴に利用されることが最も多い。 一般に， `If-Match^h は、 `表現$の［ 選定／改変 ］を孕むような どの~methodと伴にも，次のために利用できる ⇒ `選定された表現$の現在の`実体~tag$が `If-Match^h の`~field値$を成す~memberでない場合には、 当の要請を中止する ◎ If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to prevent the "lost update" problem). In general, it can be used with any method that involves the selection or modification of a representation to abort the request if the selected representation's current entity tag is not a member within the If-Match field value.

`生成元~server$は、 受信した要請が［ ある表現を選定するものであって， `If-Match^h ~headerを内包する ］ときは — 要請の~methodを遂行するに先立って，`事前条件の評価§に従う下で — その~field値に与えられた`前述の条件＠#condition-If-Match$を評価しなければナラナイ — 条件が ~F に評価された場合： ◎ When an origin server receives a request that selects a representation and that request includes an If-Match header field, the origin server MUST evaluate the If-Match condition per Section 13.2 prior to performing the method. ◎ To evaluate a received If-Match header field: • If the field value is "*", the condition is true if the origin server has a current representation for the target resource. • If the field value is a list of entity tags, the condition is true if any of the listed tags match the entity tag of the selected representation. • Otherwise, the condition is false.

• 要請された~methodを遂行してはナラナイ。 ◎ An origin server that evaluates an If-Match condition MUST NOT perform the requested method if the condition evaluates to false.＼
• 代わりに、 `状態s~code$ `412$st で応答して， 当の条件付き要請は失敗したことを指示してもヨイ。 ◎ Instead, the origin server MAY indicate that the conditional request failed by responding with a 412 (Precondition Failed) status code.＼

• ［ 当の要請は状態変更~演算であり、 `選定される表現$には，すでに適用されたように出現している場合 ］には、 前項に代えて，`状態s~code$ `2xx$st で応答してもヨイ （すなわち，~UAから要請された変更はすでに成功したが、 たぶん［ 先立つ応答~messageが失われた／他の~UAにより等価な変更が為された ］ため，~UAは それに気付かなかった）。 ◎ Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a 2xx (Successful) status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent).

  これを許容することで，多くの著作~利用事例は より効率的になるが、［ 複数の~UAが，よく似るが協力的でない変更~要請を為している場合 ］には，~riskも伴われる。 例えば、 複数の~UAが，共通な`資源$に対し~semaphoreとして書込んでいると（例：可分な増分）、 衝突する見込みが高く，重要な状態~遷移が失われかねない。 そのような種類の資源~用には、 厳格に［ ~methodが`安全$でない場合は、 失敗した どの事前条件に対しても `412$st0 を送信する ］方が良い。 他の事例【`安全$な場合】では、 当の資源の現在の状態についての混同を排するよう，成功~応答から `ETag$h ~fieldを除外すれば、 次回の要請として `GET$m を遂行するよう~UAに奨励するかもしれない。 ◎ Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative. For example, multiple user agents writing to a common resource as a semaphore (e.g., a nonatomic increment) are likely to collide and potentially lose important state transitions. For those kinds of resources, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method. In other cases, excluding the ETag field from a success response might encourage the user agent to perform a GET as its next request to eliminate confusion about the resource's current state.

`~client$は、［ `選定された表現$が合致しない場合には， `412$st 応答を選好する ］ことを指示するためとして， `GET$m 要請~内に `If-Match^h ~headerを送信してもヨイ。 しかしながら，これが有用になるのは、［ 以前に受信した部分的な`表現$を完全~化するため，新たな表現は欲されないとき ］の`範囲~要請$に限られる。 ~clientが範囲~要請にて新たな表現を受信する方を選好する場合、 `If-Range$h の方が適する。 ◎ A client MAY send an If-Match header field in a GET request to indicate that it would prefer a 412 (Precondition Failed) response if the selected representation does not match. However, this is only useful in range requests (Section 14) for completing a previously received partial representation when there is no desire for a new representation. If-Range (Section 13.1.5) is better suited for range requests when the client prefers to receive a new representation.

［ `~cache$／`媒介者$ ］は、 `If-Match^h ~headerを無視してもヨイ — その相互運用能を得る特能が必要yであるのは、 `生成元~server$に限られるので。 ◎ A cache or intermediary MAY ignore If-Match because its interoperability features are only necessary for an origin server.

`If-Match^h ~headerに［ "`*^c" と他の値（ "`*^c" も含む） ］を包含している~list値が伴われる場合、 構文として妥当でない（したがって、`生成-$することは許容されない）ことに加え， 相互運用可能にならない見込みが高いことに注意。 ◎ Note that an If-Match header field with a list value containing "*" and other values (including other instances of "*") is syntactically invalid (therefore not allowed to be generated) and furthermore is unlikely to be interoperable.

13.1.2. `If-None-Match^h

`If-None-Match@p
	= "*" / #`entity-tag$p

If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *

`If-None-Match^h は、 首に，条件付き `GET$m 要請にて — ~transactionの~overheadを最小に~~抑えて， ~cache済み情報の効率的な更新を可能化するために — 利用される。 `~client$は、 1 個以上の［ `実体~tag$を有する格納-済み応答 ］の更新を欲するときは， `GET$m 要請を為すときに［ それらの`実体~tag$からなる~listを包含する， `If-None-Match^h ~header ］を`生成-$するベキである — これは、 `受信者$である~serverに次を許容する ⇒ それら格納-済み応答のいずれかが，`選定された表現$に合致したとき、 そのことを指示する `304$st 応答を送信する。 ◎ If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum amount of transaction overhead. When a client desires to update one or more stored responses that have entity tags, the client SHOULD generate an If-None-Match header field containing a list of those entity tags when making a GET request; this allows recipient servers to send a 304 (Not Modified) response to indicate when one of those stored responses matches the selected representation.

`If-None-Match^h は、 `安全$でない`要請~method$（例： `PUT$m ）にも，値 "`*^c" を伴わせて利用できる — これにより，`~client$は、 `資源$が現在の`表現$を有さないものと予見できるときに， `~target資源$の既存の表現を不作為に改変することを防止できる。 これは、［ ~~複数の~clientが，`~target資源$に対する初期~表現を作成するよう試みた ］ときに発生し得る， “`更新喪失$” 問題の一種である。 ◎ If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation (Section 9.2.1). This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation for the target resource.

`生成元~server$は、 受信した要請が［ ある表現を選定するものであって， `If-None-Match^h ~headerを内包する ］ときは — ~methodを遂行するに先立って，`事前条件の評価§に従う下で — その~field値に与えられた`前述の条件＠#condition-If-None-Match$を 評価しなければナラナイ — 条件が ~F に評価された場合： ◎ When an origin server receives a request that selects a representation and that request includes an If-None-Match header field, the origin server MUST evaluate the If-None-Match condition per Section 13.2 prior to performing the method. ◎ To evaluate a received If-None-Match header field: • If the field value is "*", the condition is false if the origin server has a current representation for the target resource. • If the field value is a list of entity tags, the condition is false if one of the listed tags matches the entity tag of the selected representation. • Otherwise, the condition is true.

• 要請された~methodを遂行してはナラナイ。 ◎ An origin server that evaluates an If-None-Match condition MUST NOT perform the requested method if the condition evaluates to false;＼
• 代わりに、 `要請~method$に応じて，［ `GET$m または `HEAD$m ならば `304$st ／ 他の場合は `412$st ］で応答しなければナラナイ。 ◎ instead, the origin server MUST respond with either a) the 304 (Not Modified) status code if the request method is GET or HEAD or b) the 412 (Precondition Failed) status code for all other request methods.

`~cache$が受信した `If-None-Match^h ~headerの取扱いに課される要件は、 `CACHING$r `受信した検証~要請の取扱い＠~HTTPcache#validation.received§ にて定義される。 ◎ Requirements on cache handling of a received If-None-Match header field are defined in Section 4.3.2 of [CACHING].

`If-None-Match^h ~headerに［ "`*^c" と他の値（別の "`*^c" も含む） ］を包含している~list値が伴われる場合、 構文として妥当でない（したがって、`生成-$することは許容されない）ことに加え， 相互運用可能にならない見込みが高いことに注意。 ◎ Note that an If-None-Match header field with a list value containing "*" and other values (including other instances of "*") is syntactically invalid (therefore not allowed to be generated) and furthermore is unlikely to be interoperable.

13.1.3. `If-Modified-Since^h

`If-Modified-Since@p
	= `HTTP-date$p

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

`受信者$は、 要請が `If-None-Match$h ~headerも包含する場合には， `If-Modified-Since^h を無視しなければナラナイ — `If-None-Match$h 内の条件は， `If-Modified-Since^h 内の条件より正確aな置換と見なされるので。 この 2 つが組合されるのは、［ `If-None-Match$h を実装していないかもしれない旧い`媒介者$ ］と相互運用するために限られる。 ◎ A recipient MUST ignore If-Modified-Since if the request contains an If-None-Match header field; the condition in If-None-Match is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-None-Match.

`受信者$は、 `If-Modified-Since^h ~field値の時刻印を，`生成元~server$の`時計$を通して解釈しなければナラナイ。 ◎ A recipient MUST interpret an If-Modified-Since field value's timestamp in terms of the origin server's clock.

上の (B) に利用される場合、 ~UAは，［ 自前の`時計$, または 先立つ応答にて~serverから受信した `Date$h ~header ］に基づいて， `If-Modified-Since^h ~field値を`生成-$することになる。 `生成元~server$が，［ `選定された表現$の `Last-Modified$h ~headerに基づく，時刻印の正確な合致- ］を選んだ場合、［ ~UAが，~data転送を［ 指定された~~時区間~内に変更されたもの ］のみに制限する ］一助にはならなくなることになる。 ◎ When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field value based on either its own clock or a Date header field received from the server in a prior response. Origin servers that choose an exact timestamp match based on the selected representation's Last-Modified header field will not be able to help the user agent limit its data transfers to only those changed during the specified window.

`~cache$が受信した `If-Modified-Since^h ~headerの取扱いに課される要件は、 `CACHING$r `受信した検証~要請の取扱い＠~HTTPcache#validation.received§ にて定義される。 ◎ Requirements on cache handling of a received If-Modified-Since header field are defined in Section 4.3.2 of [CACHING].

13.1.4. `If-Unmodified-Since^h

`If-Unmodified-Since@p
	= `HTTP-date$p

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

`If-Unmodified-Since^h ~headerの`受信者$は、 次のいずれかに該当する場合は，それを無視しなければナラナイ： ◎ ↓

• 当の要請は `If-Match$h ~headerも包含している — `If-Match$h 内の条件は， `If-Unmodified-Since^h 内の条件より正確aな置換と見なされるので。 この 2 つが組合されるのは、［ `If-Match$h を実装していないかもしれない旧い`媒介者$ ］と相互運用するために限られる。 ◎ A recipient MUST ignore If-Unmodified-Since if the request contains an If-Match header field; the condition in If-Match is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-Match.
• その`~field値$は妥当な `HTTP-date$p でない （~field値が日時たちが成す~listとして出現している場合も含む）。 ◎ A recipient MUST ignore the If-Unmodified-Since header field if the received field value is not a valid HTTP-date (including when the field value appears to be a list of dates).
• 当の`資源$にて`改変~日時$は可用でない。 ◎ A recipient MUST ignore the If-Unmodified-Since header field if the resource does not have a modification date available.

`受信者$は、 `If-Unmodified-Since^h ~field値の時刻印を，`生成元~server$の`時計$を通して解釈しなければナラナイ。 ◎ A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.

`If-Unmodified-Since^h は、 状態変更~method（例： `POST$m, `PUT$m, `DELETE$m ）と伴に利用されることが最も多い — ［ その`表現$に`実体~tag$を給さない`資源$ ］に対し複数の~UAが並列的に動作し得るときの， 偶発的な上書-（すなわち， “`更新喪失$” 問題）を防止するために。 一般に， `If-Unmodified-Since^h は、 `表現$の［ 選定／改変 ］を孕むような どの~methodと伴にも，次のために利用できる ⇒ `選定された表現$の最後の`改変~日時$が `If-Unmodified-Since^h の`~field値$にて供された日時から変化した場合には、 当の要請を中止する ◎ If-Unmodified-Since is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity tags with its representations (i.e., to prevent the "lost update" problem). In general, it can be used with any method that involves the selection or modification of a representation to abort the request if the selected representation's last modification date has changed since the date provided in the If-Unmodified-Since field value.

`~client$は、［ `選定された表現$が改変された場合には， `412$st 応答を選好する ］ことを指示するためとして， `GET$m 要請~内に `If-Unmodified-Since^h ~headerを送信してもヨイ。 しかしながら，これが有用になるのは、［ 以前に受信した部分的な`表現$を完全~化するため，新たな表現は欲されないとき ］の`範囲~要請$に限られる。 ~clientが範囲~要請にて新たな表現を受信する方を選好する場合、 `If-Range$h の方が適する。 ◎ A client MAY send an If-Unmodified-Since header field in a GET request to indicate that it would prefer a 412 (Precondition Failed) response if the selected representation has been modified. However, this is only useful in range requests (Section 14) for completing a previously received partial representation when there is no desire for a new representation. If-Range (Section 13.1.5) is better suited for range requests when the client prefers to receive a new representation.

［ `~cache$／`媒介者$ ］は、 `If-Unmodified-Since^h ~headerを無視してもヨイ — その相互運用能を得る特能が必要yであるのは、 `生成元~server$に限られるので。 ◎ A cache or intermediary MAY ignore If-Unmodified-Since because its interoperability features are only necessary for an origin server.

13.1.5. `If-Range^h

`If-Range^h ~headerは、 `If-Match$h や `If-Unmodified-Since$h に~~似るが，［ 検証子が合致しない場合には， `Range$h ~headerを無視する ］よう`受信者$に指図するための［ 特別な`条件付き要請$の仕組み ］を供する。 合致しない場合、 `412$st 応答の代わりに，新たな`選定された表現$が転送されることになる。 ◎ The "If-Range" header field provides a special conditional request mechanism that is similar to the If-Match and If-Unmodified-Since header fields but that instructs the recipient to ignore the Range header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 (Precondition Failed) response.

`~client$は，［ `表現$の`部分的$な複製を有していて, 表現~全体の~~最新な複製を望む ］ならば、 `Range$h ~headerを， （ `If-Unmodified-Since$h, `If-Match$h のいずれか, または両者を利用している） 条件付き `GET$m と伴に利用できる。 しかしながら，表現が改変されたために`事前条件$が失敗した場合、 ~clientは，現在の表現~全体を得するために，もう一度~要請を為さなければならなくなる。 ◎ If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the precondition fails because the representation has been modified, the client would then have to make a second request to obtain the entire current representation.

`If-Range^h ~headerは、 次回の要請を “短絡する” ことを~clientに許容する。 くだけて言えば、 次のような意味になる ⇒ “表現がまだ不変なら， `Range$h にて要請している部位t（たち）を送信してください。 そうでなければ，表現~全体を送信してください。” ◎ The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is as follows: if the representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.

`If-Range@p
	= `entity-tag$p
	/ `HTTP-date$p

妥当な［ `entity-tag^p, `HTTP-date^p ］どちらなのかは、［ 最初の 3 文字について `DQUOTE$P の有無を精査する ］ことにより判別できる。 ◎ A valid entity-tag can be distinguished from a valid HTTP-date by examining the first three characters for a DQUOTE.

`~client$は、 `Range$h ~headerを包含しない要請~内に， `If-Range^h ~headerを`生成-$してはナラナイ。 `~server$は、［ `Range$h ~headerを包含しない要請~内に受信した `If-Range^h ~header ］を無視しなければナラナイ。 `生成元~server$は、［ `Range$h 要請を~supportしない`~target資源$に対する要請~内に受信した `If-Range^h ~header ］を無視しなければナラナイ。 ◎ A client MUST NOT generate an If-Range header field in a request that does not contain a Range header field. A server MUST ignore an If-Range header field received in a request that does not contain a Range header field. An origin server MUST ignore an If-Range header field received in a request for a target resource that does not support Range requests.

`Range$h ~headerを伴う要請~内に `If-Range^h ~headerを受信した`~server$は — ~methodを遂行するに先立って，`事前条件の評価§に従う下で — その条件を評価しなければナラナイ。 評価するときは、 `If-Range^h ~headerの`~field値$として供された`検証子$ %検証子 応じて： ◎ A server that receives an If-Range header field on a Range request MUST evaluate the condition per Section 13.2 prior to performing the method.

• `HTTP-date$p である場合、［ 次が満たされるならば ~T ／ ~ELSE_ ~F ］になるとする ⇒ ［ %検証子 は `8.8.2.2§ にて定義されるイミで`強い検証子$である ］~AND［ %検証子 と［ `選定される表現$用の `Last-Modified$h ~field値 ］は正確に合致する ］ ◎ To evaluate a received If-Range header field containing an HTTP-date: • If the HTTP-date validator provided is not a strong validator in the sense defined by Section 8.8.2.2, the condition is false. • If the HTTP-date validator provided exactly matches the Last-Modified field value for the selected representation, the condition is true. • Otherwise, the condition is false.

• `entity-tag$p である場合、［ 次が満たされるならば ~T ／ ~ELSE_ ~F ］になるとする ⇒ %検証子 と［ `選定される表現$用の `ETag$h ~field値 ］は、 `強い比較~関数$を利用する下で，正確に合致する ◎ To evaluate a received If-Range header field containing an entity-tag: • If the entity-tag validator provided exactly matches the ETag field value for the selected representation using the strong comparison function (Section 8.8.3.2), the condition is true. • Otherwise, the condition is false.

`If-Range^h ~headerの`受信者$は、 その条件を評価した結果に応じて ⇒＃ ~F ならば `Range$h ~headerを無視しなければナラナイ／ ~T ならば `Range$h ~headerを要請されたとおり処理するベキである ◎ A recipient of an If-Range header field MUST ignore the Range header field if the If-Range condition evaluates to false. Otherwise, the recipient SHOULD process the Range header field as requested.

`If-Range^h における比較は、 `検証子$が `HTTP-date$p の場合でも，正確な合致-に基づくことに注意 — なので、 `If-Unmodified-Since$h 条件付きを評価するときの “より近過去【！earlier than or equal to】” に基づく比較とは相違する。 ◎ Note that the If-Range comparison is by exact match, including when the validator is an HTTP-date, and so it differs from the "earlier than or equal to" comparison used when evaluating an If-Unmodified-Since conditional.

13.2.1. いつ評価するか

~protocol拡張は、［ `事前条件$が どの条件の下で評価されるか／その評価の帰結 ］を改変し得ることに注意。 例えば， `immutable$sdir `~cache指令$ `RFC8246$r は、［ `新鮮$な応答を保持するときは、 `条件付き要請$を回送するのを差控える ］よう，~cacheに指図する。 ◎ Note that protocol extensions can modify the conditions under which preconditions are evaluated or the consequences of their evaluation. For example, the immutable cache directive (defined by [RFC8246]) instructs caches to forgo forwarding conditional requests when they hold a fresh response.

`条件付き要請~header$は， （ `HEAD$m, `GET$m の間で意味論の整合性を保つため） `HEAD$m ~methodと伴用できるものと定義されるが、 条件付き `HEAD$m を送信することに~~利点はない — 何故なら，成功裡な応答は、 `304$st 応答と~~大体~同じ~sizeになり， `412$st 応答よりも有用なので。 ◎ Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD because a successful response is around the same size as a 304 (Not Modified) response and more useful than a 412 (Precondition Failed) response.

13.2.2. 事前条件の優先順

`受信者$である［ `~cache$／`生成元~server$ ］は、 要請における［ この仕様にて定義される各種`事前条件$ ］を，次の順序で評価しなければナラナイ： ◎ A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order:

【 以下における “応答する” は、 そこで評価~~手続きを終えることも意味する。 】

1. ~AND↓ が満たされるならば…

   • `受信者$は`生成元~server$である

   • ~OR↓ ：

     • 要請には `If-Match$h が在って，その事前条件を評価した結果 ~EQ ~F

     • ~AND↓

       • 要請には `If-Match$h は無い
       • 要請には `If-Unmodified-Since$h が在って，その事前条件を評価した結果 ~EQ ~F
   • 次に該当しない ⇒ 要請は状態変更~methodであって，すでに成功したものと決定できた （詳細は前項の各~fieldの記述を見よ）

   …ならば ⇒ `412$st で応答する

   ◎ When recipient is the origin server and If-Match is present, evaluate the If-Match precondition: • if true, continue to step 3 • if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 13.1.1) ◎ When recipient is the origin server, If-Match is not present, and If-Unmodified-Since is present, evaluate the If-Unmodified-Since precondition: • if true, continue to step 3 • if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 13.1.4)

2. 要請の~methodに応じて：

   `GET$m

   `HEAD$m

   ~OR↓ が満たされるならば…

   • 要請には `If-None-Match$h が在って，その事前条件を評価した結果 ~EQ ~F

   • ~AND↓

     • 要請には `If-None-Match$h は無い
     • 要請には `If-Modified-Since$h が在って，その事前条件を評価した結果 ~EQ ~F

   …ならば ⇒ `304$st で応答する

   その他

   要請には `If-None-Match$h が在って，その事前条件を評価した結果 ~EQ ~F ならば ⇒ `412$st で応答する

   ◎ When If-None-Match is present, evaluate the If-None-Match precondition: • if true, continue to step 5 • if false for GET/HEAD, respond 304 (Not Modified) • if false for other methods, respond 412 (Precondition Failed) ◎ When the method is GET or HEAD, If-None-Match is not present, and If-Modified-Since is present, evaluate the If-Modified-Since precondition: • if true, continue to step 5 • if false, respond 304 (Not Modified)

3. ~AND↓ が満たされるならば…

   • 要請の~methodは `GET$m である
   • 要請には `Range$h が在る
   • 要請には `If-Range$h が在る

   …ならば：

   • ~AND↓ が満たされるならば…

     • `If-Range$h 事前条件を評価した結果 ~EQ ~T
     • `Range$h は`選定された表現$に適用-可能である

     …ならば ⇒ `206$st で応答する

   • 他の場合 ⇒ `Range$h ~headerを無視して， `200$st で応答する
   ◎ When the method is GET and both Range and If-Range are present, evaluate the If-Range precondition: • if true and the Range is applicable to the selected representation, respond 206 (Partial Content) • otherwise, ignore the Range header field and respond 200 (OK)
4. 要請された~methodを遂行した上で，その［ 成功／失敗 ］に則って応答する ◎ Otherwise, • perform the requested method and respond according to its success or failure.

~HTTPに対する拡張は、 追加的な`条件付き要請~header$を定義するならば， そのような~fieldと他の`条件付き要請~header$ — この文書にて定義されるものに加え、 実施において見出され得る他のものも含む — を評価する順序を定義する~OUGHT。 ◎ Any extension to HTTP that defines additional conditional request header fields ought to define the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.

14.1.1. 範囲~指定子

範囲は、 範囲~指定子（ `range-spec$p ）たちが成す集合（ `range-set$p ）, それと~pairにされた`範囲~単位$の用語で表出される。 範囲~単位を成す名前は、［ 自前の指定子において，どの種類の `range-spec$p が適用-可能になるか ］を決定する。 よって，次に与える文法は汎用である — 各~範囲~単位は、［ `int-range$p, `suffix-range$p, `other-range$p ］がいつ許容されるかに関する要件を指定するものと期待される。 ◎ Ranges are expressed in terms of a range unit paired with a set of range specifiers. The range unit name determines what kinds of range-spec are applicable to its own specifiers. Hence, the following grammar is generic: each range unit is expected to specify requirements on when int-range, suffix-range, and other-range are allowed.

`範囲~要請$は、［ 単独の表現の中の， 1 個以上の範囲が成す集合 ］を指定できる。 ◎ A range request can specify a single range or a set of ranges within a single representation.

`ranges-specifier@p
	= `range-unit$p "=" `range-set$p
`range-set@p
	= 1#`range-spec$p
`range-spec@p
	= `int-range$p
	/ `suffix-range$p
	/ `other-range$p

【 `7306$errata（Verified）： "`=^c" と `range-set^p の合間に `OWS^p を挿入する必要がある。 】

`int-range$p は、 範囲を［ 2 個の負でない整数 ］または［ 1 個の負でない整数から`表現~data$の終端まで ］として表出する。 `範囲~単位$は、 これらの整数が何を意味するかを指定する （例： 先頭からの単位~offset, その~offsetも範囲に含まれるかどうか, 等々を指示することもあろう）。 ◎ An int-range is a range expressed as two non-negative integers or as one non-negative integer through to the end of the representation data. The range unit specifies what the integers mean (e.g., they might indicate unit offsets from the beginning, inclusive numbered parts, etc.).

`int-range@p
	= `first-pos$p "-" [ `last-pos$p ]
`first-pos@p
	= 1*`DIGIT$P
`last-pos@p
	= 1*`DIGIT$P

`int-range$p は、［ `last-pos$p 値が在って, その値は `first-pos$p 未満である ］ならば，妥当でない。 ◎ An int-range is invalid if the last-pos value is present and less than the first-pos.

`suffix-range$p は、 `表現~data$の~~尾部を［ 供された負でない（`範囲~単位$による）整数による最大~長さ ］で表出する範囲である。 言い換えれば、 表現~dataを成す最後から %N 個の単位を表す。 ◎ A suffix-range is a range expressed as a suffix of the representation data with the provided non-negative integer maximum length (in range units). In other words, the last N units of the representation data.

`suffix-range@p
	= "-" `suffix-length$p
`suffix-length@p
	= 1*`DIGIT$P

`other-range$p 規則の文法は、 ほぼ拘束されない — 次を許容する拡張能を供するためにあるので ⇒＃ 応用に特有な`範囲~単位$／ 追加的な範囲~指定子を定義する将来の`範囲~単位$ ◎ To provide for extensibility, the other-range rule is a mostly unconstrained grammar that allows application-specific or future range units to define additional range specifiers.

`other-range@p
	= 1*( `21-2B^X / `2D-7E^X )
	; 1*(~comma以外の `VCHAR$P)

所与の `ranges-specifier$p は： ◎ ↓

• 次を満たす場合に限り， `妥当^dfn とされる ⇒ それが包含する `range-spec$p は、 どれも次を満たす ⇒ 指示された `range-unit$p 用に定義-済みかつ妥当である。 ◎ A ranges-specifier is invalid if it contains any range-spec that is invalid or undefined for the indicated range-unit.
• 妥当かつ次を満たす場合に限り， `満足可能@ （ `satisfiable^en ）とされる ⇒ それが包含する `range-spec$p のうち，どれかが次を満たす ⇒ 指示された `range-unit$p により定義されるとおり `満足可能@1 である。 ◎ A valid ranges-specifier is "satisfiable" if it contains at least one range-spec that is satisfiable, as defined by the indicated range-unit. Otherwise, the ranges-specifier is "unsatisfiable".

14.1.2. ~byte範囲

`範囲~単位$ `bytes@c は、 `~byte範囲@ — `表現~data$の~octet列を成す下位範囲 — を表出するために利用される。 各~byte範囲は、 `表現~data$の［ 先頭から ( `int-range$p ）または終端から ( `suffix-range$p ） ］の，ある~offsetを指す整数~範囲として表出される。 ~byte範囲は `other-range$p 指定子を利用しない。 ◎ The "bytes" range unit is used to express subranges of a representation data's octet sequence. Each byte range is expressed as an integer range at some offset, relative to either the beginning (int-range) or end (suffix-range) of the representation data. Byte ranges do not use the other-range specifier.

`bytes$c における `int-range$p を成す［ `first-pos$p 値, `last-pos$p 値 ］は、 順に，範囲の［ 最初の~offset, 最後の~offset ］を 0 から数えた~byte数で与える。 すなわち、 指定された~byte~~位置は範囲に含まれ， "`0^c" は先頭~byteを~~指す。 ◎ The first-pos value in a bytes int-range gives the offset of the first byte in a range. The last-pos value gives the offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets start at zero.

`表現~data$に`内容~符号法$が適用されている場合、 各~byte範囲は，符号化された~byte列を~~基準に計算される — 復号して得される下層の~byte列ではなく。 ◎ If the representation data has a content coding applied, each byte range is calculated with respect to the encoded sequence of bytes, not the sequence of underlying bytes that would be obtained after decoding.

`~client$は、 `選定される表現$の~sizeを知ることなく， 要請される~byte数を制限できる。 ［ `last-pos$p 値が無い, または，その値が`表現~data$の現在の長さ以上 ］の場合の`~byte範囲$は、 `表現$の `first-pos$p 以降の~~部分として解釈される （すなわち，`~server$は、 `last-pos$p の値を ( `選定された表現$の現在の長さ − 1 ) に置換する）。 ◎ A client can limit the number of bytes requested without knowing the size of the selected representation. If the last-pos value is absent, or if the value is greater than or equal to the current length of the representation data, the byte range is interpreted as the remainder of the representation (i.e., the server replaces the value of last-pos with a value that is one less than the current length of the selected representation).

`suffix-range$p を利用すれば、 `~client$は，`選定される表現$の最後の %N ~byte（ %N ~GT 0 ）を参照rできる： `選定された表現$が指定された `suffix-length$p より短い場合、 `表現$~全体が利用される。 ◎ A client can refer to the last N bytes (N > 0) of the selected representation using a suffix-range. If the selected representation is shorter than the specified suffix-length, the entire representation is used.

`GET$m 要請~用には、 `bytes$c において妥当な `range-spec$p は， ~OR↓ を満たすならば`満足可能$1とされる： ◎ For a GET request, a valid bytes range-spec is satisfiable if it is either:

• `int-range$p であって， それを成す `first-pos$p は`選定された表現$の現在の長さ未満である ◎ an int-range with a first-pos that is less than the current length of the selected representation or
• `suffix-range$p であって， それを成す `suffix-length$p は 0 でない ◎ a suffix-range with a non-zero suffix-length.

`選定された表現$の長さが 0 の場合、 `GET$m 要請において`満足可能$1な形を成す `range-spec$p は，上の後者に限られる。 ◎ When a selected representation has zero length, the only satisfiable form of range-spec in a GET request is a suffix-range with a non-zero suffix-length.

~byte範囲 構文における［ `first-pos$p, `last-pos$p, `suffix-length$p ］は、 ~octet数を 10 進~数で表出する。 `内容$の長さには定義済み上限は無いので、 `受信者$は，［ ~decimal数字列が巨大になり得ること, 整数~変換の桁溢れ ］を見越して，それらによる~errorを防止しなければナラナイ。 ◎ In the byte-range syntax, first-pos, last-pos, and suffix-length are expressed as decimal number of octets. Since there is no predefined limit to the length of content, recipients MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.

15.2.1. `100^st

`状態s~code$ `100^st は、 次を指示する ⇒ 要請の初期~部分が受信され、 まだ，`~server$により却下されていない。 ◎ The 100 (Continue) status code indicates that the initial part of a request has been received and has not yet been rejected by the server.＼

すなわち、 ~serverは次を意図している ⇒ 要請を全部的に受信して, それに対し動作した後に、 `最終-応答$を送信する ◎ The server intends to send a final response after the request has been fully received and acted upon.

`100^st0 応答が応対した要請が： ◎ When the request＼

• `100-continue$c `期待$を内包する `Expect$h ~headerを包含していた場合 ⇒ `~server$は、 要請の`内容$の受信を望んでいることを指示する。 `~client$は、 この `100^st0 応答は破棄して，要請の送信を継続する~OUGHT。 ◎ contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request content, as described in Section 10.1.1.＼ The client ought to continue sending the request and discard the 100 response.
• 他の場合 ⇒ `~client$は、 この`非最終-応答$を単純に破棄できる。 ◎ If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response.

15.2.2. `101^st

`状態s~code$ `101^st は、 次を指示する ⇒ `~server$は、 `~client$の要請を解したことに加え，［ この接続に利用されている応用~protocolを変更する ］ために `Upgrade$h ~headerを介して要請に準拠する用意がある。 ◎ The 101 (Switching Protocols) status code indicates that the server understands and is willing to comply with the client's request, via the Upgrade header field (Section 7.8), for a change in the application protocol being used on this connection.＼

`~server$は、 `101^st0 応答においては，［ この応答の後に効果を発揮することになる~protocol（たち） ］を指示する `Upgrade$h ~headerを`生成-$しなければナラナイ。 ◎ The server MUST generate an Upgrade header field in the response that indicates which protocol(s) will be in effect after this response.

~serverが~protocolの切替に同意するのは、 その方が有利なときに限られるものと見做されている。 例えば ⇒＃ より新しい~versionの~HTTPへの切替は、旧い~versionより有利かもしれない／ ~real-timeかつ同期的な~protocolへの切替は、そのような特能を利用する資源を送達するときに有利かもしれない ◎ It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.

15.3.1. `200^st

`状態s~code$ `200^st は、 次を指示する ⇒ 要請は成功した。 ◎ The 200 (OK) status code indicates that the request has succeeded.＼

`200^st0 応答~内に送信される`内容$は、 `要請~method$に依存する。 この仕様が定義する~methodに対しては、 `内容$に意図される意味は，次の表tに要約できる： ◎ The content sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the content can be summarized as: ◎ Table 6

`CONNECT$m に対する応答は別として、 `200^st0 応答は，`内容$を包含するものと期待される — ~message~frame法が明示的に`内容$の長さは 0 であるものと指示していない限り。 要請の何らかの側面が，成功に際し無`内容$な応答の選好を指示する場合、 `生成元~server$は，代わりに `204$st 応答を送信する~OUGHT。 `CONNECT$m 用には、 `内容$は無い — その成功裡な結果は`~tunnel$であり、 `200^st0 応答の`~header節$の直後から始まるので。 ◎ Aside from responses to CONNECT, a 200 response is expected to contain message content unless the message framing explicitly indicates that the content has zero length. If some aspect of the request indicates a preference for no content upon success, the origin server ought to send a 204 (No Content) response instead. For CONNECT, there is no content because the successful result is a tunnel, which begins immediately after the 200 response header section.

`200^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 200 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

`生成元~server$は、［ `GET$m ／ `HEAD$m ］に対する `200^st0 応答~内に， 当の`選定された表現$用に可用な`検証子~field$を（もしあれば）送信するベキである — `強い$`実体~tag$, `Last-Modified$h 日時どちらも伴わせることが選好される。 ◎ In 200 responses to GET or HEAD, an origin server SHOULD send any available validator fields (Section 8.8) for the selected representation, with both a strong entity tag and a Last-Modified date being preferred.

［ 状態変更~methodに対する `200^st0 応答 ］内に送信された`検証子~field$は、［ 当の応答が応対した要請の意味論を成功裡に適用した結果として形成される，新たな`表現$ ］用の現在の`検証子$を伝達する。 `PUT$m ~methodには、［ そのような検証子の送信を予め除外するかもしれない，追加的な要件 ］があることに注意。 ◎ In 200 responses to state-changing methods, any validator fields (Section 8.8) sent in the response convey the current validators for the new representation formed as a result of successfully applying the request semantics. Note that the PUT method (Section 9.3.4) has additional requirements that might preclude sending such validators.

15.3.2. `201^st

`状態s~code$ `201^st は、 次を指示する ⇒ 要請は履行され、 その結果，新たな`資源$として［ `首な資源@ が 1 個, 他の資源が 0 個以上 ］作成された。 ◎ The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created.＼

【 例えば，［ ある~HTML文書, それが参照する何個かの下位資源 ］が作成されたなら、 当の~HTML文書が`首な資源$に該当することになろう。 】

要請により作成された`首な資源$は、 次により識別される ⇒＃ 応答~内に `Location$h ~headerを受信したならば その値 ／ ~ELSE_ `~target~URI$ ◎ The primary resource created by the request is identified by either a Location header field in the response or, if no Location header field is received, by the target URI.

`201^st0 応答の`内容$は、 概して，作成された`資源$（たち）を述べると伴に, それらへ~linkする。 この応答~内に送信された`検証子~field$は、［ 当の応答が応対した要請により作成された新たな`表現$ ］用の現在の`検証子$を伝達する。 `PUT$m ~methodには、［ そのような検証子の送信を予め除外するかもしれない，追加的な要件 ］があることに注意。 ◎ The 201 response content typically describes and links to the resource(s) created. Any validator fields (Section 8.8) sent in the response convey the current validators for a new representation created by the request. Note that the PUT method (Section 9.3.4) has additional requirements that might preclude sending such validators.

15.3.3. `202^st

`状態s~code$ `202^st は、 次を指示する ⇒ 要請は処理~用に受容されたが、 処理はまだ完了していない。 ◎ The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed.＼

最終的に要請が動作するかどうかは、 実際の処理に入るときに許容されなくなることもあるので，~~確定していない。 ~HTTPには、［ 非同期的な演算から【その進捗や完了を指示する】状態s~codeを送信し直す ］ような便宜性はない。 ◎ The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.

`202^st0 応答は、 意図的にどっちつかず（ `noncommittal^en ）にされている。 その目的は、［ `~server$が，何らかの処理n（たぶん，日に一度だけ稼働する一括的な処理n）用の要請を — その処理の完了まで~serverへの接続を持続するよう，`~UA$に要求することなく — 受容する ］ことを許容することにある。 この応答に伴って送信される`表現$は、 要請の現在の状態sを述べることに加え，［ 要請がいつ履行されるかの見積もりを，利用者に供せる ］ような状態s監視器を指す（または埋込む）~OUGHT。 ◎ The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.

15.3.4. `203^st

`状態s~code$ `203^st は、 次を指示する ⇒ 要請は成功したが、 同封された`内容$は，ある`形式変換ng~proxy$【！7.7§】により［ `生成元~server$の `200^st 応答の`内容$ ］から改変された。 ◎ The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed content has been modified from that of the origin server's 200 (OK) response by a transforming proxy (Section 7.7).＼

この状態s~codeは、［ `形式変換$を適用した~proxyが，その旨を`受信者$たちに通知する ］ことを許容する — その知識は、 内容に関する【受信者による】今後の裁定に影響iするかもしれない。 例えば，［ 内容に対する，未来の`~cache検証~要請$ ］が適用-可能になるのは、 同じ要請~経路に沿うもの（同じ~proxyたちを通して）に限られるようになり得る。 ◎ This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).

`203^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.3.5. `204^st

`状態s~code$ `204^st は、 次を指示する ⇒ `~server$は、 要請を成功裡に履行した。 加えて、 対する応答の`内容$内に送信する追加的な内容は無い。 ◎ The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response content.＼

`応答~header$内の~metadataは、 `~target資源$, および［ 要請された動作が適用された後に`選定された表現$ ］を指す。 ◎ Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.

`204^st0 応答は、［ `~UA$に対し，次を指示する ］ことを`~server$に許容する ⇒ 当の動作は，`~target資源$に成功裡に適用され、 そのことは［ ~UAは，自身の現在の “文書~view” （もしあれば）から離れて他へ辿る必要はない ］ことも含意する。 ◎終 `~server$は、［ ~UAが，次を行うことになる ］ものと見做している ⇒ 自身の~interfaceに則って，利用者に何らかの成功の指示を供した上で、 応答~内の［ 新たな／更新された ］~metadataを［ ~UAにて作動中な`表現$ ］に適用する。 ◎ The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any).＼ The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.

`204^st0 応答は、 `~header節$が終端するに伴い終了する — それは、 `内容$も`~trailer節$も包含し得ない。 ◎ A 204 response is terminated by the end of the header section; it cannot contain content or trailers.

`204^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 204 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.3.6. `205^st

`状態s~code$ `205^st は、 次を指示する ⇒ `~server$は、 要請を履行した。 加えて，~serverは、 `~UA$が次を行うよう欲している ⇒ 要請を送信させた “文書~view” を［ `生成元~server$から受信した，その元の状態 ］に設定し直す ◎ The 205 (Reset Content) status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.

この応答は、［ 次のような共通的な~data手入力の利用事例 ］を~supportすることが意図されている ⇒ ［［ ~data手入力（~form, ~notepad, ~canvas, 等々）を~supportする内容 ］を受信した利用者が，その場で手入力したり操作した~data ］が要請にて提出されたとき、 利用者が別の入力~動作に容易に取り掛かれるよう，次回の手入力~用に，~data手入力の仕組みを設定し直す。 ◎ This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.

状態s~code `205^st0 は，追加的な内容は供されないことを含意するので、 `~server$は， `205^st0 応答~内に`内容$を`生成-$してはナラナイ。 ◎ Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate content in a 205 response.

15.3.7. `206^st

`状態s~code$ `206^st — `部分的な応答^dfn — は、 次を指示する ⇒ `~server$は、［ `選定された表現$を成す， 1 個~以上の部位t ］を転送することにより， `~target資源$に対する`範囲~要請$を成功裡に履行した ◎ The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation.

`範囲~要請$【！（`14§）】を~supportする`~server$は、 通例的には要請された範囲~すべてを満足するよう試みる — より少ない~dataを送信すると，~clientが残りを得るために別の要請を為す見込みが高いので。 しかしながら，~serverは、 自前の理由 — 一時的に可用でない, ~cache効率, 負荷分散, 等々 — により， 要請された~dataの下位集合に限り送信するよう求めるかもしれない。 `206^st0 応答は`自己-記述的$なので、 当の応答が範囲~要請を部分的にしか満足しない場合でも， ~clientはそれを解せる。 ◎ A server that supports range requests (Section 14) will usually attempt to satisfy all of the requested ranges, since sending less data will likely result in another client request for the remainder. However, a server might want to send only a subset of the data requested for reasons of its own, such as temporary unavailability, cache efficiency, load balancing, etc. Since a 206 response is self-descriptive, the client can still understand a response that only partially satisfies its range request.

`~client$は、 `206^st0 応答の［ `Content-Type$h, `Content-Range$h ］~fieldを検分して，［ どの部位tが同封されたか，および 追加的な要請は必要になるかどうか ］を決定しなければナラナイ。 ◎ A client MUST inspect a 206 response's Content-Type and Content-Range field(s) to determine what parts are enclosed and whether additional requests are needed.

`~server$は， `206^st0 応答を`生成-$するときは、 以下の下位節にて要求されるものに加えて， 次に挙げる~headerのうち［ 同じ要請に対する `200$st 応答~内に送信することになるもの ］を`生成-$しなければナラナイ ⇒＃ `Date$h, `Cache-Control$h , `ETag$h, `Expires$h, `Content-Location$h, `Vary$h ◎ A server that generates a 206 response MUST generate the following header fields, in addition to those required in the subsections below, if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary.

`206^st0 応答~内に在る `Content-Length$h ~headerは、 当の応答の`内容$を成す~octetの個数を指示する — それは、 通例的には，`選定された表現$の完全な長さにはならない。 各 `Content-Range$h ~headerが［ 選定された表現の完全な長さについての情報 ］を内包する。 ◎ A Content-Length header field present in a 206 response indicates the number of octets in the content of this message, which is usually not the complete length of the selected representation. Each Content-Range header field includes information about the selected representation's complete length.

`206^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 206 response is heuristically cacheable; i.e., unless otherwise indicated by explicit cache controls (see Section 4.2.2 of [CACHING]).

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

15.4.1. `300^st

言い換えれば、 `~server$は，［ `~UA$が、 `~reactive折衝$に携わって， 自身の必要性に最も適切な表現（たち）を選定する ］よう欲している。 ◎ In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs (Section 12).

`~server$は、 それらの選択肢のうち選好するものがあるならば，［ その選択肢の`~URI参照$を包含する `Location$h ~header ］を`生成-$するベキである。 `~UA$は、 その`~field値$を自動的な~redirectionに利用してもヨイ。 ◎ If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.

`300^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 300 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

注記： `300^st0 用の元の提案では、 `URI^h ~headerを［［ `200$st0 ／ `300^st0 ／ `406$st0 ］応答に利用でき，［ `HEAD$m ~methodに対する応答~内に転送される，代替~表現たちが成す~list ］を供するもの ］として，定義していた。 しかしながら，［ 配備の欠如と，構文について合意が得られなかった ］ため、［ `URI^h, 後続な提案 `Alternates^h ］は，この仕様から落とされることになった。 配備については鶏と卵の問題であるが、 `Link$h ~header `RFC8288$r の`~field値$として — その~memberたちに関係性 "`alternate^c" 【 “代替する” 】を伴わせて — ~listを通信することはアリである。 ◎ Note: The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list as a Link header field value [RFC8288] whose members have a relationship of "alternate", though deployment is a chicken-and-egg problem.

15.4.2. `301^st

注記： 歴史的な理由から、 ~UAは，後続な要請~用の`要請~method$を `POST$m から `GET$m へ変更してもヨイ。 この挙動が欲されない場合、 代わりに `308$st を利用できる。 ◎ Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead.

`301^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.4.3. `302^st

`状態s~code$ `302^st は、 次を指示する ⇒ `~target資源$は、 一時的に，異なる~URIの下に居る。 ◎ The 302 (Found) status code indicates that the target resource resides temporarily under a different URI.＼

~redirectionは，その時々で改められ得るので、 `~client$は，未来の要請には`~target~URI$を利用し続ける~OUGHT。 ◎ Since the redirection might be altered on occasion, the client ought to continue to use the target URI for future requests.

`~server$は、 `302^st0 応答~内には，［［ その異なる~URI用の`~URI参照$ ］を包含する， `Location$h ~header ］を`生成-$するベキである。 `~UA$は、 その`~field値$を自動的な~redirectionに利用してもヨイ。 ~serverからの応答の`内容$は、 通例的に，［ 異なる~URI（たち）への~hyperlinkを伴う，短い~hypertext ］を包含する。 ◎ The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response content usually contains a short hypertext note with a hyperlink to the different URI(s).

注記： 歴史的な理由から、 `~UA$は，後続な要請~用の`要請~method$を `POST$m から `GET$m へ変更してもヨイ。 この挙動が欲されない場合、 代わりに `307$st を利用できる。 ◎ Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.

15.4.4. `303^st

`状態s~code$ `303^st は、 次を指示する ⇒ `~server$は、［ `Location$h ~header内の~URIにより指示される，異なる`資源$ ］へ，~UAを~redirectしている。 ◎ The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field,＼

その意図は、［ 元の要請に対する間接的な応答を供する ］ことである。 `~UA$は、［ その~URIを~targetにする検索取得~要請 （~HTTPを利用しているなら `GET$m または `HEAD$m 要請） ］を遂行できる — それは、［ 元の要請に対する回答として最終的な結果を呈示する ］ために，また~redirectされ得る。 `Location$h ~header内の新たな~URIは、 `~target~URI$に等価なものとは見なされないことに注意。 ◎ which is intended to provide an indirect response to the original request.＼ A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the target URI.

この状態s~codeは、 どの~HTTP~methodにも適用-可能である。 これは、 首に，［ `POST$m 動作の出力に応じて，`~UA$を異なる`資源$へ~redirectする ］ことを許容するために利用される — そうすることで、 `POST$m 応答に対応している情報は，別々に［ 識別-／~bookmark／~cache ］できる`資源$として供されるようになるので。 ◎ This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a different resource, since doing so provides the information corresponding to the POST response as a resource that can be separately identified, bookmarked, and cached.

`HEAD$m 要請に対する応答を除き， `303^st0 応答の`表現$は、 次を包含する~OUGHT ⇒ ［ `Location$h ~header内に供されたものと同じ`~URI参照$ ］への~hyperlinkを伴う，短い~hypertext ◎ Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the Location header field.

15.4.5. `304^st

`状態s~code$ `304^st は、 次を指示する ⇒ 条件付き［ `GET$m ／ `HEAD$m ］要請が受信されたこと，および、 仮に［ その条件が ~F に`評価-$される事実がなかった ］とするならば， `200$st で応答することになる。 ◎ The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.＼

言い換えれば、 `~server$にとっては，`~target資源$の`表現$を転送する必要はない — 何故なら，そのような要請は、［ その要請を条件付きにした`~client$が，妥当な表現をすでに有している ］ことを指示するので。 すなわち，~serverは、［ ~clientに格納-済みな その表現を， `200$st 応答の`内容$であったかのように用立ててもらう ］べく，~clientを~redirectしている。 ◎ In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response.

`304^st 応答を`生成-$している~serverは、 次に挙げる~headerのうち［ 同じ要請に対し `200$st 応答~内に送信されることになるもの ］すべてを`生成-$しなければナラナイ ⇒＃ `Content-Location$h, `Date$h, `ETag$h, `Vary$h, `Cache-Control$h `CACHING$r, `Expires$h `CACHING$r ◎ The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: • Content-Location, Date, ETag, and Vary • Cache-Control and Expires (see [CACHING])

`304^st0 応答の目標は，［ `受信者$がすでに 1 個以上の~cache済み`表現$を有するときに，転送する情報を最小限にする ］ことなので、 `送信者$は，上に挙げた~field以外の`表現~metadata$を`生成-$するベキでない — その種の~metadataが~cache更新を手引きする目的で存在するのでない限り（例： `Last-Modified$h は、 応答が `ETag$h ~fieldを有さない場合には，有用になり得る）。 ◎ Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field).

`304^st0 応答を受信した`~cache$に課される要件は、 `CACHING$r `検証に際しての，格納-済み応答の新鮮~化法＠~HTTPcache#freshening.responses§ にて定義される。 `条件付き要請$が`外方$にある`~client$ — 自前の~cacheを備え，共用~proxyに向けて条件付き `GET$m を送信する~UAなど — により出生された場合、 `~proxy$は， `304^st0 応答を その~clientに向けて回送するベキである。 ◎ Requirements on a cache that receives a 304 response are defined in Section 4.3.4 of [CACHING]. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy SHOULD forward the 304 response to that client.

`304^st0 応答は、 `~header節$が終端するに伴い終了する — それは、 `内容$も`~trailer節$も包含し得ない。 ◎ A 304 response is terminated by the end of the header section; it cannot contain content or trailers.

15.4.6. `305^st

`状態s~code$ `305^st は、 この仕様の以前の~versionにて定義されていたが，今や非推奨にされた （ `RFC7231$r `~RFC 2616 からの変更点＠~RFC7231#appendix-B§ ）。 ◎ The 305 (Use Proxy) status code was defined in a previous version of this specification and is now deprecated (Appendix B of [RFC7231]).

15.4.7. `306^st0 （利用されない）

`状態s~code$ `306^st0 は、 この仕様の以前の~versionにて定義されていたが，もはや利用されない — この~codeは予約-済みにされた。 ◎ The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.

15.4.8. `307^st

`状態s~code$ `307^st は、 次を指示する ⇒ ［ `~target資源$は，一時的に異なる~URIの下に居る ］こと, および［ `~UA$は、 その~URIへの自動的な~redirectionを遂行する場合， `要請~method$を変更してはナラナイ ］。 ◎ The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.＼

~redirectionは，時間~越しに変化し得るので、 `~client$は，未来の要請にも元の`~target~URI$を利用し続ける~OUGHT。 ◎ Since the redirection can change over time, the client ought to continue using the original target URI for future requests.

`~server$は、 応答~内に，［ その異なる~URI用の`~URI参照$を包含する， `Location$h ~header ］を`生成-$するベキである。 `~UA$は、 その`~field値$を自動的な~redirectionに利用してもヨイ。 ~serverからの応答の`内容$は、 通例的に，［ その異なる~URI（たち）への~hyperlinkを伴う，短い~hypertext ］を包含する。 ◎ The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response content usually contains a short hypertext note with a hyperlink to the different URI(s).

15.4.9. `308^st

`~server$は、 応答~内に［ 新たな恒久的~URI用に選好される`~URI参照$を包含している `Location$h ~header ］を`生成-$するベキである。 `~UA$は、 `Location^h `~field値$を自動的な~redirection用に利用してもヨイ。 応答の`内容$は、 通例的に［ 新たな~URI（たち）への~hyperlinkを伴う，短い~hypertext ］を包含する。 ◎ The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response content usually contains a short hypertext note with a hyperlink to the new URI(s).

`308^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 308 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

GET / HTTP/1.1
Host: example.com

HTTP/1.1 308 Permanent Redirect
Content-Type: text/html; charset=UTF-8
Location: http://example.com/new
Content-Length: 356

<!DOCTYPE HTML>
<html>
   <head>
      <title>Permanent Redirect</title>
      <meta http-equiv="refresh" 
            content="0; url=http://example.com/new">
   </head>
   <body>
      <p>
         The document has been moved to
         <a href="http://example.com/new"
         >http://example.com/new</a>.
      </p>
   </body>
</html>

15.5.1. `400^st

`状態s~code$ `400^st は、 次を指示する ⇒ `~server$は、 ~client~errorに知覚される何かに因り，要請を処理できないか, するつもりがない （例： 要請の構文が~~正しくない ／ 要請~message~frame法が妥当でない ／ 要請の~route法が~~誤認を誘うものである，など）。 ◎ The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

15.5.2. `401^st

`状態s~code$ `401^st は、 次を指示する ⇒ 要請は、 `~target資源$用の妥当な認証用の`資格証$を欠如するため， まだ適用されていない。 ◎ The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.＼

`401^st0 応答を`生成-$している`~server$は、 次を包含する `WWW-Authenticate$h ~headerを送信しなければナラナイ ⇒ `~target資源$に適用-可能な， 1 個~以上の `challenge$p ◎ The server generating a 401 response MUST send a WWW-Authenticate header field (Section 11.6.1) containing at least one challenge applicable to the target resource.

15.5.3. `402^st

`状態s~code$ `402^st は、 将来~利用のために予約-済みにされる。 ◎ The 402 (Payment Required) status code is reserved for future use.

15.5.4. `403^st

`状態s~code$ `403^st は、 次を指示する ⇒ `~server$は、 要請を解したが，その履行-を拒否している。 ◎ The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it.＼

`~server$は、 要請が何故 禁止されたか 公にするよう望むならば，［ その事由を，応答の`内容$（もしあれば）内に述べる ］ことができる。 ◎ A server that wishes to make public why the request has been forbidden can describe that reason in the response content (if any).

［ 要請~内に認証用の`資格証$が供されていた ］場合、 ~serverは，［ それは，~accessを是認するには足らない ］と見なしている。 `~client$は、［ 同じ資格証を伴わせた要請 ］を，自動的に繰返すベキでない。 ~clientは、［ 新たな／異なる ］資格証を伴わせるのであれば，要請を繰返してもヨイ。 しかしながら、 資格証に無関係な理由により，要請が禁止されることもある。 ◎ If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

`生成元~server$は、 禁止された`~target資源$の現在の存在を “隠したい” と望むときは， 代わりに `404$st で応答してもヨイ。 ◎ An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

15.5.5. `404^st

`状態s~code$ `404^st は、 次を指示する ⇒ `生成元~server$は、 `~target資源$用の現在の`表現$を見出せなかったか， それが存在するとしても それを開示する用意はない。 ◎ The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.＼

`404^st0 は、 この［ 表現の欠如 ］は［ 一時的, 恒久的 ］どちらなのかは，指示しない。 `生成元~server$が，その条件は恒久的になる見込みが高いことを — 大概は，何らかの環境設定-可能な手段を通して — 知る場合、 `404^st0 よりも `410$st が選好される。 ◎ A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.

`404^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 404 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.5.6. `405^st

`状態s~code$ `405^st は、 次を指示する ⇒ 【！`request-line$p 内に】 受信した~methodは、 `生成元~server$に既知ではあるが， `~target資源$においては~supportされない。 ◎ The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource.＼

`生成元~server$は、 `405^st0 応答~内に， 次を包含する `Allow$h ~headerを`生成-$しなければナラナイ ⇒ ~target資源が現在~supportしている~methodたちが成す~list ◎ The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.

`405^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 405 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.5.7. `406^st

`状態s~code$ `406^st は、 次を指示する ⇒ `~target資源$の現在の`表現$には，［ 要請~内に受信された`~proactive折衝~header$に則って，`~UA$に受容-可能になるもの ］は無いことに加え、 `~server$は，既定の表現を給する用意はない。 ◎ The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request (Section 12.1), and the server is unwilling to supply a default representation.

`~server$は、 次を包含する`内容$を`生成-$するベキである ⇒ ［ 利用者／`~UA$ ］が最も適切なものを選べるような，一群の［ 可用な`表現$の特性, それに対応する資源~識別子 ］からなる~list ◎ The server SHOULD generate content containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate.＼

`~UA$は、 この~listから，最も適切な選択肢を自動的に選定してもヨイ。 しかしながら，状態s~code `300$st にて述べたとおり、 この仕様は，そのような自動~選定~用の標準は何も定義しない。 ◎ A user agent MAY automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in Section 15.4.1.

15.5.8. `407^st

`状態s~code$ `407^st は、 `401$st に類似するが，次を指示する ⇒ `~client$は、 【！this】当の要請~用に`~proxy$を利用するためには，自身を認証してもらう必要がある。 ◎ The 407 (Proxy Authentication Required) status code is similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy for this request.＼

• `~proxy$は、 当の要請~用に `Proxy-Authenticate$h ~headerを — 自身に適用-可能な `challenge$p を包含して — 送信しなければナラナイ。 ◎ The proxy MUST send a Proxy-Authenticate header field (Section 11.7.1) containing a challenge applicable to that proxy for the request.＼
• `~client$は、 次を伴わせた上で，同じ要請を繰返してもヨイ ⇒ 新たな, または他の値に置換された， `Proxy-Authorization$h ~header ◎ The client MAY repeat the request with a new or replaced Proxy-Authorization header field (Section 11.7.2).

15.5.9. `408^st

`状態s~code$ `408^st は、 次を指示する ⇒ `~server$は、 待機するよう準備された時間~内に，要請~messageを`完全$に受信しなかった。 ◎ The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait.

`~client$は、 応答待ち要請があれば，同じ要請を繰返してもヨイ。 現在の接続は利用-不能な場合 （例：~HTTP11において，要請の区切りが失われたときなど）、 新たな接続が利用されることになる。 ◎ If the client has an outstanding request in transit, it MAY repeat that request. If the current connection is not usable (e.g., as it would be in HTTP/1.1 because request delimitation is lost), a new connection will be used.

15.5.10. `409^st

`状態s~code$ `409^st は、 次を指示する ⇒ `~target資源$の現在の状態との競合に因り，要請を完了できなかった。 ◎ The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource.＼

この~codeは、［ 利用者は、 競合を解決-可能で，要請を提出し直せる ］かもしれない状況で利用される。 `~server$は、［ 利用者が競合の~sourceを認識するに十分な情報 ］を内包する`内容$を`生成-$するベキである。 ◎ This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate content that includes enough information for a user to recognize the source of the conflict.

競合は、 `PUT$m 要請に対する応答にて生じる見込みが最も高い。 例えば，`生成元~server$は、［ `資源$に~version法が利用されている下で， `PUT$m している`表現$が［ ~~以前に（第三者-主体からの）要請により為されたもの ］と競合するような［ 資源に対する変更 ］を含む ］場合に，［ 要請を完了できないことを指示する `409^st0 応答 ］を利用できる。 この事例では、 応答の`表現$は，［ 改訂~履歴に基づいて，相違点を併合するために有用になる情報 ］を包含することになる見込みが高い。 ◎ Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.

15.5.11. `410^st

`状態s~code$ `410^st は、 次を指示する ⇒ `生成元~server$における`~target資源$への~accessは，もはや可用でなく、 その条件は恒久的になる見込みが高い。 ◎ The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.＼

`生成元~server$は、 条件が恒久的になるかどうか判らない場合は， 代わりに `404$st を利用する~OUGHT。 ◎ If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.

`410^st0 応答は、 首に，~web保守の~taskを支援するために意図されている — それは、 当の`資源$は意図的に可用でなくされ，~server所有者は［ 当の資源への~remote~linkは除去する ］よう欲していることを`受信者$に通知する。 そのような~eventは、 臨時の販促~serviceや, ［ 各個人に所属する資源が，もはや `生成元~server$の~siteに結付けられなくなったとき ］に，共通的にある。 恒久的に可用でない資源すべてを［ “~~消失した” ものと~markしたり，その~markをいつまでも保つ ］ことは、 必要yでない — それは、 ~server所有者の裁量に~~委ねられる。 ◎ The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

`410^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 410 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.5.12. `411^st

`状態s~code$ `411^st は、 次を指示する ⇒ `~server$は、 `Content-Length$h が定義されてない要請の受容-を拒否した。 ◎ The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length (Section 8.6).＼

`~client$は、 同じ要請を，次を追加した上で繰返してもヨイ ⇒ 要請の`内容$の長さを包含している，妥当な `Content-Length$h ~header ◎ The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the request content.

15.5.13. `412^st

`状態s~code$ `412^st は、 次を指示する ⇒ ある`条件付き要請~header$にて与えられた条件が， `~server$上で~testされたときに ~F に`評価-$された。 ◎ The 412 (Precondition Failed) status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server (Section 13).＼

この応答~状態s~codeは、 `~client$に次を許容する ⇒ 現在の`資源$の状態（資源の現在の`表現$と~metadata）に対し，`事前条件$を設置して、 `~target資源$が期待されない状態にある場合には，`要請~method$は適用されないようにする。 ◎ This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.

15.5.14. `413^st

`状態s~code$ `413^st は、 次を指示する ⇒ 要請の`内容$は，`~server$が［ 処理-可能な／処理する用意がある ］ものより巨大なため、 ~serverは，要請を処理するのを拒否している。 ◎ The 413 (Content Too Large) status code indicates that the server is refusing to process a request because the request content is larger than the server is willing or able to process.＼

`~server$は ⇒＃ 利用-中にある`~protocol~version$が許容するならば，要請を終了してもヨイ／ 他の場合、接続を~closeしてもヨイ ◎ The server MAY terminate the request, if the protocol version in use allows it; otherwise, the server MAY close the connection.

条件が一時的である場合，`~server$は、 `Retry-After$h ~headerを`生成-$して，次を指示するベキである ⇒ 条件は一時的であること, および`~client$は いつ再び試行してよいか ◎ If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.

15.5.15. `414^st

`状態s~code$ `414^st は、 次を指示する ⇒ `~target~URI$は，`~server$が解釈する用意がある~~長さより長いため、 ~serverは，要請に対する~serviceを拒否している。 ◎ The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the target URI is longer than the server is willing to interpret.＼

この稀な条件が生じるのは、 ほぼ，次のときに限られる： ◎ This rare condition is only likely to occur＼

• ~clientが `POST$m 要請を，不適正に，長い `query$p 情報を伴う `GET$m 要請に変換した。 ◎ when a client has improperly converted a POST request to a GET request with long query information,＼
• ~clientが~redirectionの無限~loopに陥った （例：~URI接頭辞の~redirect先が，接頭辞~自身に接尾辞を付加したものになっている）。 ◎ when the client has descended into an infinite loop of redirection (e.g., a redirected URI prefix that points to a suffix of itself) or＼
• ~clientが~~可能性のある~securityの穴を悪用するよう，~serverを攻撃している。 ◎ when the server is under attack by a client attempting to exploit potential security holes.

`414^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 414 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.5.16. `415^st

`状態s~code$ `415^st は、 次を指示する ⇒ `~target資源$に対しては，［ 要請の`内容$は，要請の~methodが~supportする形式ではない ］ため、 `生成元~server$は，要請に対する~serviceを拒否している。 ◎ The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the content is in a format not supported by this method on the target resource.

形式の問題は、［ 要請が指示した `Content-Type$h ／ `Content-Encoding$h ］に因ることも, ［ 要請の~dataを直に検分した結果 ］に因ることもある — 当の問題が： ◎ The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

• ~supportされない`内容~符号法$によるものである場合 ⇒ `Accept-Encoding$h 応答~headerを利用して， どの`内容~符号法$が（もし在れば）要請~内に受容されるかを指示する~OUGHT。 ◎ If the problem was caused by an unsupported content coding, the Accept-Encoding response header field (Section 12.5.3) ought to be used to indicate which (if any) content codings would have been accepted in the request.
• ~supportされない`~MIME型$によるものである場合 ⇒ `Accept$h 応答~headerを利用して， どの~MIME型が要請~内に受容されるかを指示できる。 ◎ On the other hand, if the cause was an unsupported media type, the Accept response header field (Section 12.5.1) can be used to indicate which media types would have been accepted in the request.

15.5.17. `416^st

`状態s~code$ `416^st は、 次を指示する ⇒ 要請の `Range$h ~header にて要請された範囲たちが成す集合は、 次のいずれかに該当するので却下された ⇒＃ `満足可能$1な範囲は無い／ 過度に［~~細切れであるか重合している］（~DoS攻撃にもなり得る） ◎ The 416 (Range Not Satisfiable) status code indicates that the set of ranges in the request's Range header field (Section 14.2) has been rejected either because none of the requested ranges are satisfiable or because the client has requested an excessive number of small or overlapping ranges (a potential denial of service attack).

各 `範囲~単位$が、［ その単位に基づく各~範囲【！範囲~集合】が`満足可能$1になるためには何が要求されるか ］を定義する。 例えば，`~byte範囲§は、 各~byte範囲【！集合】は何をもって`満足可能$1とされるかを定義する。 ◎ Each range unit defines what is required for its own range sets to be satisfiable. For example, Section 14.1.2 defines what makes a bytes range set satisfiable.

`~server$は、 この`状態s~code$を［ `~byte範囲$の要請に対する応答 ］内に`生成-$するときは，［ `選定された表現$の現在の長さ ］を指定する `Content-Range$h ~headerを`生成-$するベキである。 ◎ A server that generates a 416 response to a byte-range request SHOULD generate a Content-Range header field specifying the current length of the selected representation (Section 14.4).

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

注記： ~serverは `Range$h を無視してかまわないので、 多くの実装は，`選定された表現$全体を伴う `200$st 応答で応答する。 その~~理由の一部は、 ほとんどの~clientが， （たとえ~~効率が劣るとしても） `200$st を受信して~taskを完了するように準備されているためであり、 また，~clientには［ `完全$な表現を受信するまで，妥当でない`範囲~要請$を為すのを停止しない ］ものもあるためである。 したがって，~clientは、 `416$st 応答の受信には — それが最も適切になるときでも — 依存できない。 ◎ Note: Because servers are free to ignore Range, many implementations will respond with the entire selected representation in a 200 (OK) response. That is partly because most clients are prepared to receive a 200 (OK) to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid range request until they have received a complete representation. Thus, clients cannot depend on receiving a 416 (Range Not Satisfiable) response even when it is most appropriate.

15.5.18. `417^st

`状態s~code$ `417^st は、 次を指示する ⇒ `内方$にある いずれかの`~server$にて，［ 要請の `Expect$h ~header内に与えられた期待 ］に応えられなかった。 ◎ The 417 (Expectation Failed) status code indicates that the expectation given in the request's Expect header field (Section 10.1.1) could not be met by at least one of the inbound servers.

15.5.19. `418^st0 （利用されない）

`RFC2324$r は、 ~HTTPを濫用する様々な仕方を~~風刺した `April 1^en RFC であった。 そのような濫用の一つは、 応用に特有な `418^st0 状態s~codeの定義であった — それは、 ~jokeとして配備されていることが あまりに多いため， 将来の利用には利用-不能になっている。 ◎ [RFC2324] was an April 1 RFC that lampooned the various ways HTTP was abused; one such abuse was the definition of an application-specific 418 status code, which has been deployed as a joke often enough for the code to be unusable for any future use.

したがって，状態s~code `418^st0 は、 ~IANA `~HTTP状態s~code~registry$cite にて予約-済みである。 すなわち、 現時点では，この状態s~codeには他の応用はアテガえないことを指示する。 将来の状況下で，その利用が要求された場合 （例： `4xx^st0 状態s~codeが枯渇した）、 別の利用が再びアテガわれ得る。 ◎ Therefore, the 418 status code is reserved in the IANA HTTP Status Code Registry. This indicates that the status code cannot be assigned to other applications currently. If future circumstances require its use (e.g., exhaustion of 4NN status codes), it can be re-assigned to another use.

15.5.20. `421^st

`状態s~code$ `421$st0 は、 次を指示する ⇒ 要請の~direct先である`~server$は、 `~target~URI$に対し`権限的な応答$を生産-可能でないか, そうする用意はない。 ◎ The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI.＼

`生成元~server$ （または、 生成元~serverに利するよう動作している`~gateway$） は、 次のいずれかに合致しない`~target~URI$を却下するときに， `421^st0 を送信する ⇒＃ ~serverに環境設定された`生成元$ ／ 当の要請が受信された接続~文脈（ `7.4§ ） ◎ An origin server (or gateway acting on behalf of the origin server) sends 421 to reject a target URI that does not match an origin for which the server has been configured (Section 4.3.1) or does not match the connection context over which the request was received (Section 7.4).

`~client$は、 `421^st0 応答を受信したときは，要請を再試行してもヨイ — 次を問わず ⇒＃ `要請~method$が`冪等$かどうか／ 異なる接続~越しかどうか（`~target資源$の`生成元$に特有な，新鮮な接続など）／ 代替な~service `ALTSVC$r を介するかどうか ◎ A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection, such as a fresh connection specific to the target resource's origin, or via an alternative service [ALTSVC].

`~proxy$は、 `421^st 応答を`生成-$してはナラナイ。 ◎ A proxy MUST NOT generate a 421 response.

15.5.21. `422^st

`状態s~code$ `422^st は、 次を指示する ⇒ ［ `~server$は，要請の`内容$ %内容 の内容~型【`~MIME型$】を解した （よって，状態s~code `415$st は適切でない） ］かつ［ %内容 の構文は正しい ］が、 %内容 が包含する指示書きは処理-不能である。 ◎ The 422 (Unprocessable Content) status code indicates that the server understands the content type of the request content (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request content is correct, but it was unable to process the contained instructions.＼

この状態s~codeは、 例えば，次の場合に生じる ⇒ 要請の`内容$は整形式な~XMLである（すなわち，構文上は正しい）が、 意味論的には~~誤った~XML指示書きである。 ◎ For example, this status code can be sent if an XML request content contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.

15.5.22. `426^st

`状態s~code$ `426^st は、 次を指示する ⇒ `~server$は、［ 現在の~protocolの下では，要請の遂行-を拒否した ］が，［ `~client$が異なる~protocolに昇格した後には，そうする用意がある ］かもしれない。 ◎ The 426 (Upgrade Required) status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol.＼

`~server$は、 `426^st0 応答~内に［ 要求される~protocol（たち）を指示する， `Upgrade$h ~header ］を送信しなければナラナイ。 ◎ The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 7.8).

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.
【この~serviceには HTTP/3.0 ~protocolの利用が要求されます。】

15.6.1. `500^st

`状態s~code$ `500^st は、 次を指示する ⇒ `~server$は、 予期しない条件に遭遇して，要請を履行できなくなった。 ◎ The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

15.6.2. `501^st

`状態s~code$ `501^st は、 次を指示する ⇒ `~server$は、 要請を履行するために要求される機能性を~supportしない。 ◎ The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request.＼

これは、 次のときに適切な応答になる ⇒ ~serverは，当の`要請~method$を認識せず、 どの`資源$にも それを~supportする能力はない ◎ This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

`501^st0 応答は、 `既定では，経験的に~cache可能である$。 ◎ A 501 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

15.6.3. `502^st

`状態s~code$ `502^st は、 次を指示する ⇒ ［ `~gateway$／`~proxy$ ］として動作している`~server$が、 要請を履行するよう試みているときに， 自身が~accessした`内方$にある~serverから妥当でない応答を受信した。 ◎ The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.

15.6.4. `503^st

`状態s~code$ `503^st は、 次を指示する ⇒ `~server$は、 いくばくかの遅延~後に軽減される見込みが高い［ 一時的な過負荷／~scheduleされた保守 ］に因り，現在 要請を取扱えない。 ◎ The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.＼

`~server$は、 `Retry-After$h ~headerを送信して，次を示唆してもヨイ ⇒ `~client$が要請を再試行する前に待機する，適量な時間 ◎ The server MAY send a Retry-After header field (Section 10.2.3) to suggest an appropriate amount of time for the client to wait before retrying the request.

注記： 状態s~code `503^st0 の存在は、［ 過負荷~時には，その利用が~serverに要求される ］ことを含意するわけではない。 単純に接続を拒否する~serverもあり得る。 ◎ Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection.

15.6.5. `504^st

`状態s~code$ `504^st は、 次を指示する ⇒ ［ `~gateway$／`~proxy$ ］として動作している~serverが，［ 要請を完了するために~accessする必要がある，`上流$にある~server ］から適時に応答を受信できなかった。 ◎ The 504 (Gateway Timeout) status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.

15.6.6. `505^st

`状態s~code$ `505^st は、 次を指示する ⇒ `~server$は、［ 要請~message内に利用された~HTTP`~major~version$ ］を［ ~supportしない／~supportを拒否した ］。 ◎ The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message.＼

`~server$は、 `~client$と同じ`~major~version$を利用するどの要請に対しても， この~error~message以外では［ 完了できない／する用意はない ］ことを指示している（ `2.5§ を見よ）。 ~serverは、 `505^st0 応答においては，次について述べる`表現$を`生成-$するベキである ⇒＃ その~versionが何故~supportされないか, および 自身が~supportする他の~protocol ◎ The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in Section 2.5, other than with this error message. The server SHOULD generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.