HTTP 意味論（ § 7 〜 § 15 ）

`From@p
	= `mailbox$p

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

From: [email protected]

`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" は，~MIME型 %type を成すすべての下位型を指示する。 ◎ 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 は、 末尾に `parameters$p — 0 個以上の，その範囲に入る~MIME型に適用-可能な`~MIME型~parameter$（ `parameter$p ） （例： "`charset^c" ） — を内包し得る。 ◎ The media-range can include media type parameters that are applicable to that range. ◎ Each media-range might be followed by optional applicable media type parameters (e.g., charset),＼

各 `media-range$p には、 省略可能な（ `weight$p を成す） `q$c ~parameterが後続し得る — これは、 相対的な重み（`品質~値$）を指示する。 ◎ followed by an optional "q" parameter for indicating a relative weight (Section 12.4.2).

以前の仕様は、 `weight$p ~parameterの後に，追加的な拡張~parameter（ `accept-params^p, `accept-ext^p ）が出現することを許容していた。 この拡張~文法は、 除去された — それは、 定義を複雑化しており， 実施において利用されておらず， 新たな~headerを通して もっと容易に配備できるので。 ◎ 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.＼

【 `parameters$p は `weight$p の構文も包摂するので、】 `weight$p を利用している`送信者$は、 最後に "`q^c" を送信するベキである （ `media-range$p を成す すべての~parameterよりも後に）。 `受信者$は、 ~parameterの順序付けを問わず， "`q^c" と命名される~parameterが在るならば `weight$p として処理するベキである。 ◎ 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に基づく，時刻印の正確な合致- ］を選んだ場合、 【 `If-Modified-Since^h は，】［ ~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. 事前条件の優先順

~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.