HTTP/1.1 — 意味論と内容

3.1.1. 表現~dataの処理

`media-type@p
	= `type$p "/" `subtype$p *( `OWS$p ";" `OWS$p `parameter$p )
`type@p
	= `token$p
`subtype@p
	= `token$p

`parameter@p
	= `token$p "=" ( `token$p / `quoted-string$p )

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

`charset@p
	= `token$p

`Content-Type@p
	= `media-type$p

Content-Type: text/html; charset=ISO-8859-4

3.1.2. 圧縮／完全性のための符号化法

`content-coding@p
	= `token$p

`Content-Encoding@p
	= 1#`content-coding$p

Content-Encoding: gzip

3.1.3. 視聴者~言語

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

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

`Content-Language@p
	= 1#`language-tag$p

Content-Language: da

Content-Language: mi, en

3.1.4. 識別

`Content-Location@p
	= `absolute-URI$p
	/ `partial-URI$p

3.4.1. ~proactive折衝

~proactive折衝には、深刻な不利がある： ◎ Proactive negotiation has serious disadvantages:

• `~server$にとっては、［ 任意の利用者にとって，何が “最良” になるか ］を正確aに決定することは，不可能である — そのためには、［ ~UAに備わる能力, 応答に対し意図される利用（例： 利用者は，~screen上, 紙への印刷のどっちを求めているか？） ］の両者について，完全な知識を要求することになるので。 ◎ • It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?);
• ~UAが 毎~要請ごとに，自身に備わる能力を述べるとするなら、とても非効率になり得る（ごく小さな割合の応答のみが複数の`表現$を持つ下では）。 更に、利用者の~privacyに対する~riskも高める。 ◎ • Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential risk to the user's privacy;
• ［ `生成元~server$, および 要請に対する応答を生成する~algo ］の実装が複雑化する。 ◎ • It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,
• 共用~cachingにおける応答の再利用性が，制限される。 ◎ • It limits the reusability of responses for shared caching.

`~UA$は、［ ~proactive折衝による選好が一貫して尊守される ］ことに依拠できない — `生成元~server$は、要請された`資源$用には ~proactive折衝を実装していなかったり，［ ~UAの選好に適合しない応答を送信する方が， `406$st 応答を送信するより良い ］と裁定することもあるので。 ◎ A user agent cannot rely on proactive negotiation preferences being consistently honored, since the origin server might not implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to the user agent's preferences is better than sending a 406 (Not Acceptable) response.

`Vary$h ~headerは、［ 要請のどの部分の情報が，選定~algoに利用されるか ］を指示するために，［ ~proactive折衝を~subjectとする応答 ］内に送信されることが多い。 ◎ A Vary header field (Section 7.1.4) is often sent in a response subject to proactive negotiation to indicate what parts of the request information were used in the selection algorithm.

3.4.2. ~reactive折衝

`~server$は、［ 代替~list以外の初期~表現を送信しない — すなわち，`~UA$による~reactive折衝を選好することを指示する ］ことを選択してもよい。 例えば，［ `300$st ／ `406$st を伴う応答 ］内に~listされる代替は、［ 利用者または~UAが~reactiveに選定を行い得るような，可用な`表現$ ］についての情報を内包する。 ◎ A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred. For example, the alternatives listed in responses with the 300 (Multiple Choices) and 406 (Not Acceptable) status codes include information about the available representations so that the user or user agent can react by making a selection.

~reactive折衝には、代替~listを~UAへ伝送する手間を要する不利がある — それは、［ ~listを`~header節$~内に伝送し，代替-表現を得するために 2 度目の要請を要する ］場合に，利用者に知覚される待時間を~~増やす。 更には、この仕様は，自動的な選定を~supportする仕組みは定義しない — そのような仕組みを拡張として開発することも~~止めないが。 ◎ Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation. Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension.

4.2.1. 安全な~method

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

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

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

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

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

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

4.2.2. 冪等~method

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

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

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

4.2.3. ~cache可能な~method

`要請~method$には、 `~cache可能^dfn と定義されるものもある — それは、［［ その要請に対する応答を未来の再利用のために格納する ］ことが許容されている ］ことを指示する。 特有な要件については、`7234$Rを見よ。 一般に，［［ 現在の／権限的な ］応答に依存しない，`安全な$~method ］は、~cache可能として定義される — この仕様は、［ `GET$m, `HEAD$m, `POST$m ］を~cache可能として定義する — ほとんどの~cache実装は、 `GET$m, `HEAD$m のみを~supportしているが。 ◎ Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see [RFC7234]. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.

4.3.1. `GET^m

`GET^m ~methodは、［ 現在の，`~target資源$用に`選定される表現$ ］を転送するよう要請する。 `GET^m は、情報を検索取得する首な仕組みであり，ほぼすべての処理能 最適化の力点が置かれる所である。 よって、誰かが［ ~HTTPを介して識別できる何らかの情報を検索取得する ］ことについて話すとき，たいていは `GET^m 要請を為すことを指している。 ◎ The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.

資源~識別子は ~remote~file~systemの~pathnameで，`表現$は そのような~file内容の複製であると、~~考えられがちである。 事実、多くの資源が実装されている方法でもある（関係する~securityの考慮点については`9.1$secを見よ）。 しかしながら、実施においてそのような制限は無い。 資源~用の~HTTP~interfaceは、単に［ 内容~objの~tree ／ 様々な~database~record上の~programmatic~view ／ 他の情報~systemへの~gateway ］などとして実装される見込みも高い。 `~URI$対応付けの仕組みが，~file~systemに縛られているときでも、`生成元~server$は，［ ~fileを直に転送するのではなく，［ 要請を入力に~fileを実行して、その出力として，表現を送信する ］ように環境設定される ］こともある。 いずれにせよ、 `GET^m に対する応答において，［ その各~資源~識別子を，どの実装に対応させるか ］や, ［ 各~実装が［ `~target資源$の現在の表現を選定して送信すること ］を，どう管理するか ］を知る必要があるのは、生成元~serverのみである。 ◎ It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of such files. In fact, that is how many resources are implemented (see Section 9.1 for related security considerations). However, there are no such limitations in practice. The HTTP interface for a resource is just as likely to be implemented as a tree of content objects, a programmatic view on various database records, or a gateway to other information systems. Even when the URI mapping mechanism is tied to a file system, an origin server might be configured to execute the files with the request as input and send the output as the representation rather than transfer the files directly. Regardless, only the origin server needs to know how each of its resource identifiers corresponds to an implementation and how each implementation manages to select and send a current representation of the target resource in a response to GET.

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

`GET^m 要請~messageの~payloadには、意味論は定義されない — 既存の実装には、`~payload本体$を伴って送信されてきた `GET^m 要請を却下するものもある。 ◎ A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

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

4.3.2. `HEAD^m

`HEAD^m ~methodは、［ ~serverが，応答~内に`~message本体$を送信してはナラナイ（すなわち，応答は、`~header節$の終端で終了する） ］ことを除いて、 `GET$m と一致する。 `~server$は、 `HEAD^m 要請に対する応答~内に，［ 要請が `GET$m であったときに送信することになる~headerたち ］と同じ~headerたちを送信するベキである — ただし、それらのうち`~payload~header$は省略されてヨイ。 この~methodは、［ `表現~data$を転送する ］ことなく，［ `選定された表現$についての~metadataを得する ］ために利用でき、また，［［ 妥当性 ／ ~accessibility ／ 近過去の改変 ］のために~hypertext~linkを~testする ］ときに，利用されることが多い。 ◎ The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section). The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted. This method can be used for obtaining metadata about the selected representation without transferring the representation data and is often used for testing hypertext links for validity, accessibility, and recent modification.

`HEAD^m 要請~messageの~payloadには、意味論は定義されない — 既存の実装には、`~payload本体$を伴って送信されてきた `HEAD^m 要請を，却下するものもある。 ◎ A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request.

`HEAD^m 要請に対する応答は，`~cache可能$である — `Cache-Control$h ~headerから指示されない限り、［ 後続な `HEAD^m 要請を充足する ］ために~cacheが利用されてヨイ。 `HEAD^m 応答も，［ 以前に~cacheされた `GET$m に対する応答 ］に効果を持つことがある — `7234-4.3.5$rfcを見よ。 ◎ The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [RFC7234]). A HEAD response might also have an effect on previously cached responses to GET; see Section 4.3.5 of [RFC7234].

4.3.3. `POST^m

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

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

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

`POST^m 要請に対する応答は、［ それが，明示的な`鮮度~情報$を内包する ］ときに限り，`~cache可能$である。 しかしながら， `POST^m に対する~cachingは、まだ広範には実装されてはいない。 `生成元~server$は、［ `~client$が，今後の `GET$m により再利用し得るような仕方で［ `POST^m の結果 ］を~cacheできる ］ようにしたいと望むならば、［［ `POST^m の`実効~要請~URI$と同じ値をとる， `Content-Location$h ~header ］を包含している `200$st 応答 ］を送信してもヨイ。 ◎ Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).

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

4.3.4. `PUT^m

`PUT^m ~methodは、［ `~target資源$の状態を，［ 要請~message~payload内に同封された`表現$により定義される状態 ］として作成する, あるいはその状態に置換する ］ことを要請する。 ［ 所与の表現に対する成功裡な `PUT^m ］は、［ 同じ~target資源に対する後続な `GET$m の結果が， `200$st 応答~内に送信されている表現と等価になる ］ことを示唆する。 しかしながら，［ そのような状態~変化が観測-可能になる ］ことは保証されない — ~target資源は、［ 後続な `GET$m が受信される前に，並列的な 他の~UAにより動作されたり ］, ［ `生成元~server$による動的~処理の~subjectである ］こともあるので。 成功裡な応答は、その処理~時点で［ ~UAの意図が，生成元~serverにより達成された ］ことのみを含意する。 ◎ The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server.

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

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

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

• `PUT^m 要請~内に受信された，未認識~headerは、無視する（すなわち，資源~状態の一部として保存しない）ベキである。 ◎ An origin server SHOULD ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state).

• ［ `~target資源$に備わる［ `PUT^m により変更できない／されることにはならない ］ようにする，どの拘束 ］にも， `P^var が整合することを検証yするベキである。 これは特に、`生成元~server$が［ `~URI$に関係する内部 環境設定~情報を利用して， `GET$m 応答~上の`表現~metadata$用の値を設定している ］ときに，重要になる。 ◎ An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information related to the URI in order to set the values for representation metadata on GET responses.＼

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

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

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

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

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

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

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

4.3.5. `DELETE^m

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

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

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

`DELETE^m 要請~messageの~payloadには、意味論は定義されない — 既存の実装には、`~payload本体$を伴って送信されてきた `DELETE^m 要請を却下するものもある。 ◎ A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.

`DELETE^m ~methodに対する応答は、`~cache可能$でない。 成功裡な† `DELETE^m 要請が［ `実効~要請~URI$用に格納-済みな応答を，一つ以上~持つ~cache ］を通して渡される場合、それらの格納-済み応答は，無効化することになる。 【† `4689$errataによる挿入（ Held for Document Update: 2018-11-01 ）】 ◎ Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).

4.3.6. `CONNECT^m

`CONNECT^m ~methodは、`受信者$に，［［ `request-target$p により識別される，行先の生成元~server ］への`~tunnel$を確立する ］こと, および［ それに成功したならば、~tunnelが~closeされるまで，受信者の挙動を［ 両~方向とも，~packetの盲目的~回送 ］に制約する ］ことを要請する。 ~tunnelは、［ 一つ以上の~proxyを通して，端点間の仮想~接続を作成する ］ときに共通的に利用される — しかる後、 ~TLS（ Transport Layer Security, `5246$R）を利用して~secure化できるようになる。 ◎ The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, [RFC5246]).

`CONNECT^m は、~proxyへの要請に利用するためのみに意図されている。 `生成元~server$は，［ 自身に向けられた `CONNECT^m 要請を受信した ］ときは、接続が確立されたことを指示するために， `2xx$stで応答してもヨイ。 しかしながら，ほとんどの生成元~serverは、 `CONNECT^m を実装しない。 ◎ CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself MAY respond with a 2xx (Successful) status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.

`~client$が［ `CONNECT^m 要請を送信する ］ときは、［ `authority-form$p による `request-target$p ］を送信しなければナラナイ — すなわち，`request-target$p は、~colonで分離された，［ `~tunnel$の行先の~host名＆~port番号 ］のみからなる。 ◎ A client sending a CONNECT request MUST send the authority form of request-target (Section 5.3 of [RFC7230]); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.＼

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

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

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

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

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

`CONNECT^m 要請~messageの~payloadには、意味論は定義されない — 既存の実装には、`~payload本体$を伴って送信されてきた `CONNECT^m 要請を却下するものもある。 ◎ A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request.

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

4.3.7. `OPTIONS^m

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

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

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

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

`~client$は、［ `~payload本体$を包含する `OPTIONS^m 要請 ］を`生成する$ときは，［ `表現$の`~MIME型$を述べる妥当な `Content-Type$h ~header ］を送信しなければナラナイ。 この仕様は，そのような~payloadのいかなる利用も定義しないが、 ~HTTPの将来の拡張は，［ `~target資源$について，より詳細な~queryを為す ］ために `OPTIONS^m 要請の本体を利用し得る。 ◎ A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing the representation media type. Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.

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

4.3.8. `TRACE^m

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

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

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

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

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

5.1.1. `Expect^h

要請~内の `Expect^h ~headerは、 `期待@ — ［ 当の要請を適正に取扱うために，~serverにより~supportされる必要がある ］ような，一定の挙動の集合 — を指示する。 この仕様で定義される，そのような唯一の`期待$は、 "`100-continue^c" である： ◎ The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request. The only such expectation defined by this specification is 100-continue.

`Expect@p
	= "100-continue"

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

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

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

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

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

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

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

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

• ~HTTP10要請~内に受信された`~100cont 期待$は、無視しなければナラナイ。 ◎ • A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore that expectation.
• ［ 対応する要請の`~message本体$の一部をすでに受信している ］, または［ ~frame法が，~message本体が無いことを指示している ］場合、`100$st 応答の送信を省略してもヨイ。 ◎ • A server MAY omit sending a 100 (Continue) response if it has already received some or all of the message body for the corresponding request, or if the framing indicates that there is no message body.
• `100$st 応答を送信した後、`~message本体$を受信して処理したなら、接続が尚早に~closeされない限り，最終的には，最終~状態s~codeを送信しなければナラナイ。 ◎ • A server that sends a 100 (Continue) response MUST ultimately send a final status code, once the message body is received and processed, unless the connection is closed prematurely.
• ~message本体 全体を読取る前に，最終~状態s~codeで応答するときは、その応答~内にて，［ 接続を~closeするのか, 読取りを継続するのか ］どちらを意図するか, および［ 要請~messageを破棄するかどうか【！＊】 ］について指示するベキである（`7230-6.6$rfcを見よ）。 ◎ • A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message (see Section 6.6 of [RFC7230]).

［ `生成元~server$／`~proxy$ ］は、［ `~HTTP11$（以上の~versionの） `request-line$p, および 完全な`~header節$ ］を受信したときに，それが［ `~100cont 期待$を包含していて，要請~message本体が後続することを指示している ］場合は： ◎ ↓

• 生成元~serverは、次のいずれかをしなければナラナイ： ◎ An origin server MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either＼

  • ［ `request-line$p と各~headerを精査するだけで，状態sを決定できる ］ならば、即時に 最終~状態s~codeを伴う応答を送信する。 ◎ send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or＼
  • `100$st 応答を送信して，~clientに要請の~message本体を送信してもらうよう奨励する — この場合、この応答を送信する前に，~message本体を待機してはナラナイ。 ◎ send an immediate 100 (Continue) response to encourage the client to send the request's message body. The origin server MUST NOT wait for the message body before sending the 100 (Continue) response.

• ~proxyは、次のいずれかをしなければナラナイ： ◎ A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either＼

  • ［ `request-line$p と各~headerを精査するだけで，状態sを決定できる ］ならば、即時に 最終~状態s~codeを伴う応答を送信する。 ◎ send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or＼

  • 次の`内方$~serverへ［ 対応する `request-line$p と~header節を送信する ］ことにより、`生成元~server$へ向けて，その要請の回送を始める。 ◎ begin forwarding the request toward the origin server by sending a corresponding request-line and header section to the next inbound server.＼

    ［ 次の内方~serverが~HTTP10のみを~supportする ］ことを（環境設定または過去のやりとりから）予見できるならば、~clientに~message本体を送信し始めてもらうよう，即時に `100$st 応答を`生成し$てもヨイ。 ◎ If the proxy believes (from configuration or past interaction) that the next inbound server only supports HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) response to encourage the client to begin sending the message body.

注記： `Expect^h ~headerは、 ~~元々の~HTTP11`2068$Rが公表された後に，［ 暫定的 `100$st 応答を要請する手段 ］と［ 解することが要求される拡張を指示するための一般的な仕組み ］の両者として追加された。 しかしながら，この拡張の仕組みは、未だ~clientたちから利用されておらず，また その要件は，多くの~serverにて実装されていないため、拡張の仕組みの具現化は，無用と化している。 ~100cont の定義とその処理を単純~化するため、この仕様は，その拡張の仕組みを除去した。 ◎ Note: The Expect header field was added after the original publication of HTTP/1.1 [RFC2068] as both the means to request an interim 100 (Continue) response and the general mechanism for indicating must-understand extensions. However, the extension mechanism has not been used by clients and the must-understand requirements have not been implemented by many servers, rendering the extension mechanism useless. This specification has removed the extension mechanism in order to simplify the definition and processing of 100-continue.

5.1.2. `Max-Forwards^h

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

`Max-Forwards@p
	= 1*DIGIT

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

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

5.3.1. 品質~値

［ `~proactive折衝$用の`要請~header$ ］の多くは、［ 相対的な選好の “重み” を，結付けられる内容の種類にアテガう ］ために，［ `q$c と命名される（文字大小無視な）共通な~parameter ］を利用する。 この重みは、同じ~parameter名が，~server環境設定の中で［ 資源~用に選定され得る様々な`表現$の，相対的な品質の重み ］をアテガうために 利用されることが多いため、 `品質~値^dfn （ あるいは “qvalue” ）と呼ばれる。 ◎ Many of the request header fields for proactive negotiation 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 の実数に正規化される — ここで，［ 値 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*3DIGIT ] )
	/ ( "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.

5.3.2. `Accept^h

`~UA$は、［ 応答の`~MIME型$として受容-可能なもの ］を指定するために， `Accept^h ~headerを利用できる。 `Accept^h ~headerは、［ 要請が，欲される型からなる小さな集合に特に制限される ］ことを指示するときに利用できる — 例えば，~in-line画像に対する要請など。 ◎ The "Accept" header field can be used by user agents to specify response media types that are acceptable. 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.

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

`media-range@p
	= ( "*/*"
		/ ( `type$p "/" "*" )
		/ ( `type$p "/" `subtype$p )
	  ) *( `OWS$p ";" `OWS$p `parameter$p )
`accept-params@p
	= `weight$p *( `accept-ext$p )
`accept-ext@p
	= `OWS$p ";" `OWS$p `token$p [ "=" ( `token$p / `quoted-string$p ) ]

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

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

注記： ［ `Accept^h の拡張~parameterから`~MIME型~parameter$を分離する，~parameter名 "`q^c" ］の利用は、歴史的な実施に因る。 これにより， `media-range$p においては［ "`q^c" と命名される`~MIME型~parameter$ ］は利用できなくなるが、［ ~IANA~MIME型~registryにおける `q$c ~parameterの欠如 ］, および［ `Accept^h 内での`~MIME型~parameter$の稀な利用e ］の下では、そのような出来事は，まずないと予見されている。 将来の~MIME型においては、"`q^c" と命名されるどのような~parameterも登録しないことが奨励される。 ◎ Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q".

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

`Accept^h ~headerを伴わない要請は、［ `~UA$が、どの`~MIME型$も，応答~内に受容することになる ］ことを含意する。 この~headerが要請~内に在るが，［ 応答~用に可用な どの表現の~MIME型も，受容-可能として~listされていない ］場合、`生成元~server$は，［ `406$st 応答を送信して，この~headerを尊守する ］, あるいは［ 応答を，`内容~折衝$の~subjectではないかのように扱って，この~headerを無視rする ］ことができる。 ◎ A request without any Accept header field implies that the user agent will accept any media type in response. If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, 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.

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/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

   +-------------------+---------------+
   | Media Type        | Quality Value |
   +-------------------+---------------+
   | text/html;level=1 | 1             |
   | text/html         | 0.7           |
   | text/plain        | 0.3           |
   | image/jpeg        | 0.5           |
   | text/html;level=2 | 0.4           |
   | text/html;level=3 | 0.7           |
   +-------------------+---------------+

注記： ~UAは、一定~範囲の~MIME型~用に，`品質~値$の既定の集合を供し得る。 しかしながら，~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.

5.3.3. `Accept-Charset^h

`~UA$は、 `Accept-Charset^h ~headerを送信して，［ ~textな応答~内容として受容-可能な，`~charset$ ］を指示できる。 この~headerにより、~UAは，［ より［ 包括的な／特殊用途の ］~charsetを解する能力を備える ］ならば，その能力を［ それらの~charsetで情報を表現する能力を備えている生成元~server ］へ通達できるようになる。 ◎ The "Accept-Charset" header field can be sent by a user agent to indicate what charsets are acceptable in textual response content. 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
	= 1#( ( `charset$p / "*" ) [ `weight$p ] )

各~charset名は、`3.1.1.2$secにて定義される。 `~UA$は、各~charsetに［ 利用者の相対的~選好を指示する`品質~値$ ］を結付けてヨイ。 ◎ Charset names are defined in Section 3.1.1.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 5.3.1.＼

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

要請に `Accept-Charset^h ~headerが伴われないことは、［ `~UA$が，応答~内に どの`~charset$も受容する ］ことを含意する。 ほとんどの一般用~UAは、特に環境設定されない限り， `Accept-Charset^h を送信しない — ~serverにとっては，［ ~supportされる`~charset$の詳細な~list ］があれば、~UAの要請の特性から，各個人を識別することがより容易になる（`9.7$sec）ので。 ◎ A request without any Accept-Charset header field implies that the user agent will accept any charset in response. Most general-purpose user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (Section 9.7).

［ 要請~内に `Accept-Charset^h ~headerが在る ］かつ［ 応答に可用な どの`表現$も，受容-可能として~listされた`~charset$を持たない ］場合、`生成元~server$は，［ `406$st 応答を送信して，その~headerを尊守する ］か, あるいは［ 資源を`内容~折衝$の~subjectではないかのように扱って，その~headerを無視rする ］こともできる。 ◎ If an Accept-Charset header field is present in a request and none of the available representations for the response has a charset that is listed as acceptable, the origin server can either honor the header field, by sending a 406 (Not Acceptable) response, or disregard the header field by treating the resource as if it is not subject to content negotiation.

5.3.4. `Accept-Encoding^h

`~UA$は、 `Accept-Encoding^h ~headerを利用して，［ 応答にて受容-可能な，`内容~符号法$ ］を指示できる。 "`identity@c" ~tokenは、符号化が選好されないときに通信するための， “符号化しない” の同義語として利用される。 ◎ The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (Section 3.1.2.1) are acceptable in the response. 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 ）には、［ その符号化法に結付けられる選好~度を表現する，`品質~値$ ］も与えられてヨイ。 `Accept-Encoding^h ~header内の記号~asterisk "`*^c" は、［ その~header内に明示的に~listされていない ］ような，可用な どの`内容~符号法$にも，合致する。†a ◎ Each codings value MAY be given an associated quality value representing the preference for that encoding, as defined in Section 5.3.1. The asterisk "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 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

`Accept-Encoding^h ~headerを伴わない要請は、［ `~UA$が`内容~符号法$に関する選好を持たない ］ことを含意する。 これにより，［ `~server$は，応答~内に 任意の`内容~符号法$を利用できる ］ようになるが、［ ~UAが，どの符号化法も正しく処理できる ］ことを含意するわけではない。 ◎ A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings. Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able to correctly process all encodings.

`~server$は、次の規則を利用して，［ 所与の`表現$用の`内容~符号法$ ］が 【~UAにとって】 受容-可能になるかどうかを~testする： ◎ A server tests whether a content-coding for a given representation is acceptable using these rules:

1. 要請~内に `Accept-Encoding^h ~headerが無い場合： `~UA$は，どの`内容~符号法$も受容-可能である、と見なされる。†b ◎ 1. If no Accept-Encoding field is in the request, any content-coding is considered acceptable by the user agent.

2. `表現$が`内容~符号法$を持たない場合、 `Accept-Encoding^h ~header値が次のいずれかを充足する場合を除き，既定で受容-可能である†c： ◎ 2. If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding field stating either＼

   • "`identity;q=0^c" を伴う。 ◎ "identity;q=0" or＼
   • "`*;q=0^c" を伴う, かつ［ 明示的な品質値を伴う `identity^c ］は伴わない。 ◎ "*;q=0" without a more specific entry for "identity".

   【 "`identity$c" も内容~符号法の一種（恒等変換）と見なした上で、表現が内容~符号法を持たないことを， “表現は内容~符号法 "`identity^c" を持つ” と解釈すれば、この規則は，次項による規則の特別な場合と見なせる。 】

3. `表現$の`内容~符号法$が，［ `Accept-Encoding^h ~header内に~listされた`内容~符号法$ ］のうち，いずれかである場合： それに`品質値$ 0 が付随していない限り，受容-可能である。 （`5.3.1$secの定義により，品質値 0 は “受容-可能でない”ことを意味する）。†d ◎ 3. If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
4. 複数の `内容~符号法$が受容-可能である場合、［ 最も高い非 0 `品質値$を伴う受容-可能な`内容~符号法$ ］が選好される。†e ◎ 4. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.

注記： ほとんどの~HTTP10~appは、`内容~符号法$に結付けられた`品質値$を［ 認識しない／順守しない ］。 これは、`品質値$が，おそらく働かず，［ `x-gzip^c や `x-compress^c ］との併用も許可されないことを意味する。 ◎ Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues might not work and are not permitted with x-gzip or x-compress.

5.3.5. `Accept-Language^h

`~UA$は、 `Accept-Language^h ~headerを利用して［ 応答において選好される自然言語（`言語~tag$）の集合 ］を指示できる。 【！言語~tagは、3.1.3.1にて定義される。】 ◎ 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 3.1.3.1.

`Accept-Language@p
	= 1#( `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 5.3.1.＼

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は、数種の照合スキームを，照合~用に定義している。 実装は、自身の要件に最も適切な照合スキームを提供できる。 "Basic Filtering" スキーム（ `4647-3.3.1$rfc ）は、以前に［ `2616-14.4$rfcにて，~HTTP用として定義された照合スキーム ］と一致する。 ◎ 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に反し得る（`9.7$sec）。 ◎ 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 9.7).

言語の理解度は，個々の利用者に大きく依存するので、`~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.

5.5.1. `From^h

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

`From@p
	= `mailbox$p

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

From: webmaster@example.org

`From^h ~headerが非~robotic~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.

~robotic~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制御や認証 ］用に利用するベキでない — ほとんどの受信者は、この~headerの値を公な情報であると見做すことになるので。 ◎ A server SHOULD NOT use the From header field for access control or authentication, since most recipients will assume that the field value is public information.

5.5.2. `Referer^h

`Referer^h ~headerにより、`~UA$は［ `~target~URI$を得した所の資源 ］用に，`~URI$参照を指定できるようになる（すなわち， “referrer（~~参照元）” — ~header名の綴りは誤っているが）。 `~UA$は、 `Referer^h `~header値$を`生成する$際に，~URI参照に［ `fragment$p ／ `userinfo$p ］成分`3986$Rを内包してはナラナイ。 ◎ 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). A user agent MUST NOT include the fragment and userinfo components of the URI reference [RFC3986], if any, when generating the Referer field value.

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

`Referer^h ~headerにより、`~server$は，［ 単純~解析, ~log取り, 最適化された~caching, 等々 ］のために，他の資源へ戻れる~linkを生成できるようになる。 それはまた、保守~用に［ 廃用にされた／誤入力された ］~linkを見出すことも可能にする。 一部の~serverは、 `Referer^h ~headerを，［ 他~siteからの~link（いわゆる “deep linking” ）を否認したり, CSRF （ cross-site request forgery ）を制約する ］ための手段として利用するが、すべての要請がそれを包含するわけではない。 ◎ 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 field or send it with a value of "about:blank".

`Referer^h ~headerが［ 要請の文脈や, 利用者の閲覧~履歴についての情報 ］を露呈し得る場合、それは，［ 参照元~資源の識別子が（~account名などの）個人-情報を露呈したり ］, あるいは［ 資源が機密的と想定される（~firewallの背後や, ~secure化された~serviceの内部など） ］場合に，~privacy上の懸念になる。 ほとんどの一般用~UAは、［ 参照元~資源が局所的な［ "file" ／ "data" ］`~URI$である ］ときには， `Referer^h ~headerを送信しない。 `~UA$は、［ 参照元~pageが~secure~protocolで受信されていた ］場合には，~secure化されてない~HTTP要請~内に `Referer^h ~headerを送信してはナラナイ。 追加的な~securityの考慮点については `9.4$secを見よ。 ◎ The Referer field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol. See Section 9.4 for additional security considerations.

一部の`中継者$は，［ 外向けの要請から `Referer^h ~headerを無差別に除去する ］ことが、既知である。 これは、 CSRF 攻撃に対する保護に干渉するような，~~望ましくない副作用を及ぼす — それは、利用者にとり，はるかに有害になる。 `Referer^h 内への情報~開示を制限したいと望む［ `中継者$／`~UA$拡張 ］は、それらの変更を［ 内部~domain名を `pseudonym$p に置換したり， `query$p や`path$p 成分を切落す ］などの，特定の編集-に制約する~OUGHT。 `中継者$は、［ ~header値が，`要請~target$と同じ `scheme$p ＆ `host$p を共有する ］ときは， `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 request target.

5.5.3. `User-Agent^h

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

`User-Agent^h `~header値$は、 1 個~以上の［ `製品~識別子@ （ `product$p ）と, 後続する 0 個以上の `comment$p ］からなる。 それらは組で，［ ~UA~software, および その有意な下位製品 ］を識別する。 慣行により，製品~識別子は、~UA~softwareを識別するために［ それらの有意度の降順 ］で~listされる。 各 `製品~識別子$は、名前, および~version（ `product-version$p, 省略可能）からなる。 ◎ The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (Section 3.2 of [RFC7230]), 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を，互換性を宣言するために利用する ］ことは奨励されない — そうすると，この~headerの目的を~~無為にするので。 別の~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.

6.2.1. `100^st

状態s~code `100^stは、［ 要請の初期~部分が受信され，まだ，~serverにより却下されていない ］ことを指示する。 ~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. The server intends to send a final response after the request has been fully received and acted upon.

［ `~100cont 期待$を内包する `Expect$h ~header ］を包含する要請に対する `100^st0 応答は、［ ~serverが要請`~payload本体$の受信を望んでいる ］ことを指示する — `~client$は、要請の送信を継続する~OUGHT — `100^st0 応答は破棄して。 この暫定的~応答が，そうでない要請に対するものであれば、`~client$は，単純にそれを破棄できる。 ◎ When the request contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in Section 5.1.1. The client ought to continue sending the request and discard the 100 response. ◎ If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response.

6.2.2. `101^st

状態s~code `101^stは、［ `~server$が`~client$の要請を解すること, および［ この接続に利用されている応用~protocol ］を変更するために， `Upgrade$h ~header を介して，要請に準拠する用意がある ］ことを指示する。 `~server$は、 `101^st0 応答~内に，［［ その応答を終了させる空~行lの直後から 切替わることになる，~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 6.7 of [RFC7230]), for a change in the application protocol being used on this connection. The server MUST generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 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.

6.3.1. `200^st

状態s~code `200^stは、［ 要請が~成功した ］ことを指示する。 `200^st0 応答~内に送信される~payloadは、`要請~method$に依存する。 この仕様で定義される~methodに対しては、~payloadに意図される意味は，次の様に要約できる： ◎ The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:

`CONNECT$m に対する応答は別として、 `200^st0 応答は，常に~payloadを持つ — `生成元~server$は、長さ 0 の`~payload本体$を`生成し$てヨイが。 ~payloadが欲されていない場合、生成元~serverは代わりに `204$st を送信する~OUGHT。 `CONNECT$m に対しては，~payloadは許容されない — その成功裡な結果は、`~tunnel$であり， `200^st0 応答の`~header節$の直後から始まるので。 ◎ Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 (No Content) instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section.

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

6.3.2. `201^st

状態s~code `201^stは、［ 要請は履行され，その結果 一つ以上の新たな`資源$が作成されている ］ことを指示する。 ［ 要請により作成された`首な資源$ ］は、［ 応答~内に `Location$h ~headerが受信されたならば その値 ／ 他の場合は `実効~要請~URI$ ］により識別される。 ◎ The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.

`201^st0 応答の~payloadは、概して，作成された`資源$（たち）を述べ, それらへ~linkする。 `201^st0 応答~内の［ `ETag$h や `Last-Modified$h などの`検証子~header$ ］の意味と目的についての論点は、`7.2$secを見よ。 ◎ The 201 response payload typically describes and links to the resource(s) created. See Section 7.2 for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response.

6.3.3. `202^st

状態s~code `202^stは、［ 要請は処理~用に受容されたが，処理はまだ完了していない ］ことを指示する。 最終的に要請が動作するかどうかは、実際の処理に入るときに許容されなくなることもあるので，~~確定していない。 ~HTTPには、［ 非同期的な~~処理から状態s~codeを再~送信する ］ような便宜性はない。 ◎ The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. 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 ）にされている。 その目的は、`~server$が［ 何らかの処理n（たぶん，日に一度だけ稼働する~~一括~処理n）用の要請 ］を，［ `~UA$に，その処理の完了まで~serverへの接続を持続する ］ことを要求することなく，受容できるようにすることである。 この応答に伴って送信される`表現$は、要請の現在の状態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.

6.3.4. `203^st

状態s~code `203^stは、［ 要請は成功したが、同封された~payloadは，`形式変換ng~proxy$により［ 生成元~serverの `200^st 応答のそれ ］から改変されている（`7230-5.7.2$rfc） ］ことを指示する。 この状態s~codeにより、`形式変換$を適用した~proxyは，その旨を受信者たちに通知できるようになる — その知識は，内容に関する今後の裁定に影響iすることがある。 例えば，［ 内容に対する，未来の~cache検証~要請 ］が適用-可能になるのは、同じ要請~経路に沿うもの（同じ~proxyたちを通して）に限られるようになり得る。 ◎ The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy (Section 5.7.2 of [RFC7230]). 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 応答は、［［ どの状態s~codeを伴う応答にも適用-可能である利点 ］を持つ `Warning$h ~code `214$wc ］に類似する。 ◎ The 203 response is similar to the Warning code of 214 Transformation Applied (Section 5.5 of [RFC7234]), which has the advantage of being applicable to responses with any status code.

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

6.3.5. `204^st

状態s~code `204^stは、［ `~server$が，要請を成功裡に履行した ］こと, および［ その応答`~payload本体$~内に送信する追加的な内容は無い ］ことを指示する。 `応答~header$内の~metadataは、`~target資源$, および［ 要請された動作が適用された後に`選定された表現$ ］を指す。 ◎ 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 payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.

例えば、 `PUT$m 要請に対する応答~内に `204^st0が受信され，応答が `ETag$h ~headerを包含する場合、 `PUT$m は成功していて， `ETag$h `~header値$が，［ その`~target資源$の新たな`表現$用の `entity-tag$p ］を包含する。 ◎ For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.

`204^st0 応答により、`~server$は，`~UA$に向けて［［ ~UAは，自身の現在の “文書~view” （もしあれば）から離れて他へ辿る必要はない ］ことを含意しつつ，動作が`~target資源$に成功裡に適用された ］ことを指示できるようになる。 `~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は、［ “保存” 動作に対応する文書~編集~interface ］と伴に共通的に利用され，［ 保存した文書が，利用者による編集~用に可用であり続ける ］ようにする。 それはまた、分散型の~version制御~systemの中など，［ 自動化された~data転送が主流になると予期される~interface ］と伴に利用されることが多い。 ◎ For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.

`204^st0 応答は、`~message本体$を包含できない。 そのため、`~header節$の後の最初の空~行lで終了される。 ◎ A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.

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

6.3.6. `205^st

状態s~code `205^stは、［ `~server$は，要請を履行した ］こと, および［ `~UA$は，［ 要請を送信させた “文書~view” ］を［ その，`生成元~server$から受信された元の状態に~resetする ］ことを欲している ］ことを指示する。 ◎ 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手入力の仕組みを~resetさせる ］ような。 ◎ 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.

6.4.1. `300^st

状態s~code `300^stは、［ `~target資源$は複数の`表現$を持ち，そのそれぞれが［ 自前の，より特定な識別子 ］を伴う ］こと，および［ それらの代替についての情報が供されていて、利用者（または~UA）は，［ それらの識別子のうち 一つ以上のものへ，要請を~redirectする ］ことにより，選好する表現を選定できる ］ことを指示する。 言い換えれば、`~server$は，［ `~UA$が`~reactive折衝$に参加して，その必要性に合わせて，最も適切な表現（たち）を選定する ］ことを欲している。 ◎ The 300 (Multiple Choices) status code indicates that the target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. 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 3.4).

`~server$は、それらの選択肢のうち 選好するものがあるならば，［ その選択肢の~URI参照を包含する `Location$h ~header ］を`生成する$ベキである。 `~UA$は、その `Location$h ~headerの値を，自動的な~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.

［ `HEAD$m 以外の`要請~method$ ］に対しては、`~server$は， `300^st0 応答~内に［［ 利用者や~UAが，最も選好するものを選択できる ］ような，［ `表現~metadata$と~URI参照（たち） ］の~list ］を包含する~payloadを`生成する$ベキである。 `~UA$は、供された`~MIME型$を解するならば，その~listから自動的に選定してもヨイ。 ［ 自動的な選定~用の特定の形式 ］は、この仕様では，定義されない。 何故なら、~HTTPは，~payloadの定義に直交的であろうとし続けるので。 実施においては、`表現$は，［ 共有されている 設計や`内容~折衝$により決定され，~UAに受容-可能と予見される，何らかの容易に構文解析できる形式 ］か, あるいは［ 何らかの共通的に受容される~hypertext形式 ］により，供される。 ◎ For request methods other than HEAD, the server SHOULD generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent MAY make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.

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

注記： `300^st0に対する元の提案では、 `URI^h ~headerを［［ `200$st0 ／ `300^st0 ／ `406$st0 ］応答に利用でき，［ `HEAD$m ~methodに対する応答~内に転送される，代替~表現の~list ］を供するもの ］として，定義していた。 しかしながら，［ 配備の欠如と，構文について合意が得られなかった ］ため、 `URI^h, および `Alternates^h（後続な提案）のいずれも，この仕様からは落とされることになった。 配備については 鶏と卵の問題であるが、［ 互いを “代替する” 関係性にある，一連の `Link$h ~header `5988$R ］を利用して，~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 using a set of Link header fields [RFC5988], each with a relationship of "alternate", though deployment is a chicken-and-egg problem.

6.4.2. `301^st

状態s~code `301^stは、［ `~target資源$に，新たな恒久的~URIがアテガわれていて、この資源への未来の参照は，同封された いずれかの~URIを利用する~OUGHT ］ことを指示する。 ~link編集~能力を備えている`~client$は、アリな所では，［ `実効~要請~URI$への参照 ］を［ ~serverから送信されてきた，一つ以上の新たな参照 ］に，自動的に~linkし直す~OUGHT。 ◎ The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.

`~server$は、応答~内に，［［ 新たな恒久的~URIとして選好される，~URI参照 ］を包含する， `Location$h ~header ］を`生成する$ベキである。 `~UA$は、その`~header値$を自動的な~redirectionに利用してもヨイ。 ~serverの応答~payloadは、通例的に，［ 新たな~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 payload usually contains a short hypertext note with a hyperlink to the new 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.

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

6.4.3. `302^st

状態s~code `302^stは、［ `~target資源$が，一時的に，異なる~URIの下に居る ］ことを指示する。 ~redirectionは，その時々で改められ得るので、`~client$は，未来の要請には `実効~要請~URI$を利用し続ける~OUGHT。 ◎ The 302 (Found) status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.

`~server$は、応答~内に，［［ その異なる~URI用の~URI参照 ］を包含する `Location$h ~header ］を`生成する$ベキである。 `~UA$は、その`~header値$を自動的な~redirectionに利用してもヨイ。 ~serverの応答~payloadは、通例的に，［ 異なる~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 payload 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.

6.4.4. `303^st

状態s~code `303^stは、［ ~serverが，~UAを［ `Location$h ~header内の~URIにより指示される，異なる`資源$ ］へ~redirectしている ］ことを指示する — その意図は、［ 元の要請に対する間接的な応答を供する ］ことである。 `~UA$は、［ その~URIを~targetにする検索取得~要請（ ~HTTPを利用しているなら `GET$m または `HEAD$m 要請） ］を遂行できる — それは、［ 元の要請に対する回答として最終的な結果を呈示する ］ために，また~redirectされ得る。 `Location$h ~header内の新たな~URIは、`実効~要請~URI$に等価なものとは見なされないことに注意。 ◎ 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, 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 effective request URI.

この状態s~codeは、どの~HTTP~methodにも適用-可能である。 これは首に、［ `POST$m 動作の出力により，`~UA$を選定された`資源$へ~redirectできるようにする ］ために利用される — そうすることにより、［ ~formにおける `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 selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.

`GET$m 要請に対する `303^st0 応答は、［ `生成元~server$は［ ~serverにより~HTTP越しに転送できるような［ `~target資源$の`表現$ ］を持たないが、 `Location$h `~header値$は［ 元の~target資源 `A^var を~~記述するものである，資源 `B^var ］を指している ］ことを指示する — その資源 `B^var への検索取得~要請を為した結果が、資源 `A^var を表現することを含意することなく，受信者に有用な表現になり得るような。 ［ 何を表現し得るか？ ／ どのような表現であれば必要十分になるか？ ／ 何が有用な~~記述になり得るか？ ］に対する回答は、~HTTPの視野から外れることに注意。 ◎ A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.

`HEAD$m 要請に対する応答を除いて、［ `303^st0 応答の`表現$ ］は、［［ `Location$h ~header内に供されたものと同じ~URI参照 ］への~hyperlinkを伴う，短い~hypertext ］を包含する~OUGHT。 ◎ 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.

6.4.5. `305^st

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

6.4.6. `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.

6.4.7. `307^st

状態s~code `307^stは、［ `~target資源$が，一時的に異なる~URIの下に居る ］ことに加えて, ［ `~UA$は、［ その~URIへの自動的な~redirectionを遂行する ］ときに，`要請~method$を変更してはナラナイ ］ことを指示する。 ~redirectionは，時間~越し変化し得るので、`~client$は，未来の要請にも 元の`実効~要請~URI$を利用し続ける~OUGHT。 ◎ 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. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.

`~server$は、応答~内に，［ その異なる~URI用の~URI参照を包含する， `Location$h ~header ］を`生成する$ベキである。 `~UA$は、その`~header値$を自動的な~redirectionに利用してもヨイ。 ~serverの応答~payloadは、通例的に，［ その異なる~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 payload usually contains a short hypertext note with a hyperlink to the different URI(s).

注記： この状態s~codeは， `302$st に似るが、［ その`要請~method$を `POST$m から `GET$m へ変更する ］ことは許容されない。 この仕様は、 `301$st に対しては，~~相当するものを定義しない （しかしながら、 `7238$R が，この目的に `308＠~HTTPsem#status.308$st を定義する）。 ◎ Note: This status code is similar to 302 (Found), except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for 301 (Moved Permanently) ([RFC7238], however, defines the status code 308 (Permanent Redirect) for this purpose).

6.5.1. `400^st

状態s~code `400^stは、［ ~serverは、~client~errorに知覚される何かに因り，要請を処理できない／するつもりがない ］ことを指示する（例： 要請の構文が~~正しくない ／ 要請~message~frame法が妥当でない ／ 要請の経路制御が~~誤認を誘うものである，など）。 ◎ 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).

6.5.2. `402^st

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

6.5.3. `403^st

状態s~code `403^stは、［ ~serverは、要請を解したが，それに対する権限付与-を拒否している ］ことを指示する。 `~server$は、要請が何故 禁止されたか 公にしたいと望むならば，［ その理由を，応答の~payload（もしあれば）内に述べる ］ことができる。 ◎ The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (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).

6.5.4. `404^st

状態s~code `404^stは、［ `生成元~server$は、［ `~target資源$用に現在の`表現$を見出せなかった ］か, ［ ~target資源が存在することを開示するつもりがない ］］ことを指示する。 `404^st0は、［ この，表現の欠如が、［ 一時的, 恒久的 ］のどちらなのか ］は，指示しない。 `生成元~server$が，その条件は恒久的になる見込みが高いことを — 大概は何らかの環境設定し得る手段を通して — 知る場合、 `404^st0よりも`410$stが選好される。 ◎ 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. 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 cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).

6.5.5. `405^st

状態s~code `405^stは、［ `request-line$p 内に受信された~methodは、`生成元~server$に既知ではあるが，`~target資源$においては~supportされない ］ことを指示する。 `生成元~server$は、 `405^st0 応答~内に［［ ~target資源にて現在~supportされる~method ］の~listを包含する， `Allow$h ~header ］を`生成し$なければナラナイ。 ◎ 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. 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 cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).

6.5.6. `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 5.3), and the server is unwilling to supply a default representation.

`~server$は、［［ 利用者や~UAが その中から最も適切なものを選択できる ］ような，［ 可用な表現~特性の~listと，そのそれぞれに対応する資源~識別子 ］］を包含する~payloadを，`生成する$ベキである。 `~UA$は、その~listから［ 最も適切な選択肢 ］を自動的に選定してもヨイ。 しかしながら，`6.4.1$secにて述べたように、この仕様は，そのような自動的な選定~用の どのような標準も，定義しない。 ◎ The server SHOULD generate a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. 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 6.4.1.

6.5.7. `408^st

状態s~code `408^stは、［ ~serverは、待機するよう準備された時間~内に，要請~messageを`完全$に受信しなかった ］ことを指示する。 `~server$は、応答~内に，`~close_接続~option$を送信するベキである — `408^st0 は［ ~serverが，待機し続けずに接続を~closeすると裁定した ］ことを含意するので。 `~client$は、応答待ち要請があれば，その要請を新たな接続~上にて繰返してもヨイ。 ◎ 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. A server SHOULD send the "close" connection option (Section 6.1 of [RFC7230]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.

6.5.8. `409^st

状態s~code `409^stは、［［ `~target資源$の現在の状態との競合 ］に因り，要請を完了できなかった ］ことを指示する。 この~codeは、［ 利用者は、競合を解決して，要請を再~提出し得る ］ような状況で利用される。 `~server$は、［ 利用者が競合の~sourceを認識するに十分な情報 ］を内包する~payloadを，`生成する$ベキである。 ◎ 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. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload 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.

6.5.9. `410^st

状態s~code `410^stは、［ `~target資源$への~accessが，`生成元~server$にて もはや可用でなく、 その条件が恒久的になる見込みが高い ］ことを指示する。 `生成元~server$は、条件が恒久的になるかどうかについて判らない場合は，代わりに `404$stを利用する~OUGHT。 ◎ 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. 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 cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).

6.5.10. `411^st

状態s~code `411^stは、［ ~serverは、 `Content-Length$h が定義されてない要請の受容-を拒否した ］ことを指示する。 `~client$は、要請~message内に［ `~message本体~長さ$を包含する，妥当な `Content-Length$h ~header ］を追加した上で，要請を繰返してもヨイ。 ◎ The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length (Section 3.3.2 of [RFC7230]). The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.

6.5.11. `413^st

状態s~code `413^stは、［ 要請の~payloadが，~serverが処理n［ する用意がある／できる ］ものより巨大なため、~serverは 要請を処理するのを拒否している ］ことを指示する。 `~server$は、`~client$に要請を継続させないように，接続を~closeしてもヨイ。 ◎ The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

条件が一時的である場合，`~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.

6.5.12. `414^st

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

6.5.13. `415^st

状態s~code `415^stは、［ `~target資源$上では，［ 要請の~payloadは，要請の~methodにより~supportされる形式ではない ］ため、`生成元~server$は 要請に対する~serviceを拒否している ］ことを指示する。 形式の問題は、［ 要請が指示した `Content-Type$h ／ `Content-Encoding$h ］に因ることもあれば, ［ 要請の~dataを直に検分した結果 ］に因ることもある。 ◎ The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource. 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.

6.5.14. `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 5.1.1) could not be met by at least one of the inbound servers.

6.5.15. `426^st

状態s~code `426^stは、［ ~serverは、［ 現在の~protocolの下では，要請の遂行-を拒否した ］が，［ ~clientが異なる~protocolに昇格した後には，その用意がある ］であろう ］ことを指示する。 `~server$は、 `426^st0 応答~内に［ 要求される~protocol（たち）を指示する， `Upgrade$h ~header ］を送信しなければナラナイ。 ◎ 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. The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 6.7 of [RFC7230]).

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.

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

6.6.2. `501^st

状態s~code `501^stは、［ ~serverは、要請を履行するために要求される機能性を~supportしない ］ことを指示する。 これは、［ ~serverは、`要請~method$を認識せず，どの資源も それを~supportする能力を備えていない ］ときに適切な応答になる。 ◎ The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. 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 cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).

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

6.6.4. `503^st

状態s~code `503^stは、［ ~serverは、［ いくばくかの遅延~後に緩和される見込みが高いような，一時的な過負荷 または~scheduleされた保守 ］に因り，現在 要請を取扱えない ］ことを指示する。 `~server$は、 `Retry-After$h ~headerを送信して，［ ~clientが要請を再試行する前に待機する，~~適量な時間 ］を示唆してもヨイ。 ◎ 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. The server MAY send a Retry-After header field (Section 7.1.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.

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

6.6.6. `505^st

状態s~code `505^stは、［ ~serverは、［ 要請~message内に利用された~HTTP`~major~version$ ］を~supportしない／~supportを拒否した ］ことを指示する。 ~serverは、［ ~clientと同じ~major~versionを利用するどの要請も，この~error~message以外では 完了できない／するつもりがない ］ことを指示している（ `7230-2.6$rfcを見よ）。 `~server$は、 `505^st0 応答に対しては，［ その~versionが何故~supportされないか, および 自身が~supportする他の~protocol ］について述べる`表現$を`生成する$ベキである。 ◎ 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. 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.6 of [RFC7230], 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.

7.1.1. 出生日時

`HTTP-date@p
	= `IMF-fixdate$p
	/ `obs-date$p

Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate

Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete `850$R format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

`IMF-fixdate@p
	= `day-name$p "," SP `date1$p SP `time-of-day$p SP `GMT$p
; 形式のうち，固定的な［ 長さ／時間帯／大文字頭字 ］による~subset
; `5322-3.3$rfc を見よ

`day-name@p
	= %x4D.6F.6E ; "Mon"`, 文字大小区別, 以下同様^com
	/ %x54.75.65 ; "Tue"
	/ %x57.65.64 ; "Wed"
	/ %x54.68.75 ; "Thu"
	/ %x46.72.69 ; "Fri"
	/ %x53.61.74 ; "Sat"
	/ %x53.75.6E ; "Sun"

`date1@p
	= `day$p SP `month$p SP `year$p
	; `例：^com 02 Jun 1982

`day@p
	= 2DIGIT
`month@p
	= %x4A.61.6E ; "Jan"`, 文字大小区別, 以下同様^com
	/ %x46.65.62 ; "Feb"
	/ %x4D.61.72 ; "Mar"
	/ %x41.70.72 ; "Apr"
	/ %x4D.61.79 ; "May"
	/ %x4A.75.6E ; "Jun"
	/ %x4A.75.6C ; "Jul"
	/ %x41.75.67 ; "Aug"
	/ %x53.65.70 ; "Sep"
	/ %x4F.63.74 ; "Oct"
	/ %x4E.6F.76 ; "Nov"
	/ %x44.65.63 ; "Dec"
`year@p
	= 4DIGIT

`GMT@p
	= %x47.4D.54 ; "GMT"`, 文字大小区別^com

`time-of-day@p
	= `hour$p ":" `minute$p ":" `second$p
	; 00:00:00 - 23:59:60 `（うるう秒（ leap second ））^com

`hour@p
	= 2DIGIT
`minute@p
	= 2DIGIT
`second@p
	= 2DIGIT

`obs-date@p
	= `rfc850-date$p / `asctime-date$p

`rfc850-date@p
	= `day-name-l$p "," SP `date2$p SP `time-of-day$p SP GMT
`date2@p
	= `day$p "-" `month$p "-" 2DIGIT
	; `例：^com 02-Jun-82

`day-name-l@p

	= %x4D.6F.6E.64.61.79          ; "Monday"`, 文字大小区別, 以下同様^com
	/ %x54.75.65.73.64.61.79       ; "Tuesday"
	/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday"
	/ %x54.68.75.72.73.64.61.79    ; "Thursday"
	/ %x46.72.69.64.61.79          ; "Friday"
	/ %x53.61.74.75.72.64.61.79    ; "Saturday"
	/ %x53.75.6E.64.61.79          ; "Sunday"

`asctime-date@p
	= `day-name$p SP `date3$p SP `time-of-day$p SP `year$p
`date3@p
	= `month$p SP ( 2DIGIT / ( SP 1DIGIT ))
	; `例：^com Jun  2

`Date@p
	= `HTTP-date$p

Date: Tue, 15 Nov 1994 08:12:31 GMT

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

~header値は、単独の `URI-reference$p からなる。 値が`相対~参照$（`3986-4.2$rfc）の形をとるときの，最終~値は、`実効~要請~URI$ （`3986-5$rfc）に対し解決して，算出される。 ◎ The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).

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

`3xx$st 応答~内に供される `Location^h 値に 素片~成分（ `fragment$p ）がない場合、`~UA$は，~redirectionを［ その値が［ `要請~target$を`生成する$際に利用した~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 request target (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参照が妥当でない ］ときに，その回復を試みる。 この仕様は，そのような処理を義務化したり定義しないが、堅牢性の~~目的で，それを許容する。 ◎ Note: Some recipients attempt to recover from Location 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.

注記： `Content-Location$h ~headerは、それが［ 同封された`表現$に対応する最も特定な資源 ］を指す点で， `Location^h から相違する。 したがって、応答が `Location^h, `Content-Location$h 両~headerを包含することもアリである。 ◎ Note: The Content-Location header field (Section 3.1.4.2) 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.

7.1.3. `Retry-After^h

~serverは、［ ~UAが後継の要請を為す前に，どのくらい長く待機する~OUGHT ］かを指示するために， `Retry-After^h ~headerを送信する。 ［ `503$st 応答に伴って送信されてきた `Retry-After^h ］は、［ ~serviceが~clientに可用でないと予期される~~長さ ］を指示する。 ［ `3xx$st 応答に伴って送信されてきた `Retry-After^h ］は、［ ~UAが~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.

この~headerの値は、 `HTTP-date$p, または［ 応答を受信した後の遅延~秒数 ］のいずれかをとる。 ◎ The value of this field can be either an HTTP-date or a number of seconds to delay after the response is received.

`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

7.1.4. `Vary^h

応答~内の `Vary^h ~headerは、［ ~method／ `Host$h ~header／`要請~target$ ］の他に，要請~messageのどの部分が［ `生成元~server$による，この応答を選定して表現する処理n ］に波及し得た（し得る）かを述べる。 `~header値$は、［ 1 個の~asterisk （"`*^c"） ］または［ 何個かの`~header名$（文字大小無視）からなる~list ］のいずれかをとる： ◎ The "Vary" header field in a response describes what parts of a request message, aside from the method, Host header field, and request target, might influence the origin server's process for selecting and representing this response. The value consists of either a single asterisk ("*") or a list of header field names (case-insensitive).

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

`Vary^h ~headerに対する値 "`*^c" は、要請のあらゆる部分 — 場合によっては ~message構文の外側の要素も含む（例：~clientの~network~address） — が，応答の`表現$を選定する役割を担い得た（担い得る）ことを通達する。 `受信者$は、［ この応答が，今後の【同じ】要請にも適切になるかどうか ］を［ 要請を`生成元~server$に回送しない限り決定できない ］ことになる。 【したがって、そのような応答は~cacheしても無意味になる。】 `~proxy$は、値に "`*^c" をとる `Vary^h ~headerを，`生成し$てはナラナイ。 ◎ A Vary field value of "*" signals that anything about the request might play a role in selecting the response representation, possibly including elements 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 a Vary field with a "*" value.

`Vary^h ~headerに対する ~commaで分離された名前の~listによる値は、［ ~listされた名前の`要請~header$ — これらは `選定用~header@ と呼ばれる — が，`表現$を選定する役割を担い得た（担い得る） ］ことを指示する。 選定用~headerになり得る~headerは、この仕様で定義されるものに制限されない。 ◎ A Vary field value consisting of a comma-separated list of names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation. The potential selecting header fields are not limited to those defined by this specification.

Vary: accept-encoding, accept-language

`生成元~server$が［ ~header名の~listを伴う `Vary^h ］を送信する目的には、次の 2 つがあり得る： ◎ An origin server might send Vary with a list of fields for two purposes:

• ~cache受信者たちに，次のことを伝える ⇒ 今後の要請において、その要請が［ ~listされた~headerについて，元の要請と同じ値（`7234-4.1$rfc）をとる ］のでない限り，この応答を その要請を充足するために利用してはナラナイ。

  言い換えれば `Vary^h は、［ 新たな要請が，格納-済みな~cache~entryに合致する ］ために要求される~cache~keyを拡げる。

  ◎ 1. To inform cache recipients that they MUST NOT use this response to satisfy a later request unless the later request has the same values for the listed fields as the original request (Section 4.1 of [RFC7234]). In other words, Vary expands the cache key required to match a new request to the stored cache entry.
• ~UA受信者に，次のことを伝える ⇒ この応答は`内容~折衝$の~subjectであり、~listされたいずれかの~header内に 追加的な~parameterが供される場合（`~proactive折衝$）には，後続な要請に対し異なる`表現$が送信され得る。 ◎ 2. To inform user agent recipients that this response is subject to content negotiation (Section 5.3) and that a different representation might be sent in a subsequent request if additional parameters are provided in the listed header fields (proactive negotiation).

7.4.1. `Allow^h

`Allow^h ~headerは、［ `~target資源$が~supportするものとして広告される，~methodの集合 ］を~listする。 この~headerの目的は、［ 資源に結付けられた妥当な`要請~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 ~headerは、［ 資源がどの~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 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を改変してはナラナイ — 汎用~message取扱い規則に則って取扱うときは、値の中に指示された すべての~methodを解する必要はない。 ◎ 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.

7.4.2. `Server^h

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

`Server^h `~header値$は、 1 個~以上の［ `製品~識別子$と, 後続する 0 個以上の `comment$p ］からなる。 それらは組で，［ 生成元~server~software, および その有意な下位製品 ］を識別する。 慣行により，製品~識別子は、生成元~server~softwareを識別するために［ それらの有意度の降順 ］で~listされる。 各~製品~識別子は、`5.5.3$secにて定義されるように，名前, および~version（省略可能）からなる。 ◎ The Server field-value consists of one or more product identifiers, each followed by zero or more comments (Section 3.2 of [RFC7230]), 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 5.5.3.

Server: CERN/3.0 libwww/2.17

`生成元~server$は、［ ~~不必要に木目細かな詳細を包含する `Server^h ~header ］を`生成する$ベキでない。 また、［ 第三者-主体による下位製品の追加 ］を制限するベキである。 ~~過度に長く詳細な `Server^h `~header値$は、応答の待時間を増大させる。 また，内部~実装の詳細を露呈する~~可能性もあるので、攻撃者にとっては（少しばかり，）既知な~securityの穴を見出して悪用し易くなる。 ◎ An origin server SHOULD NOT generate a Server 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.

8.1.1. 手続-

~HTTP~method登録は、次の~fieldを内包しなければナラナイ： ◎ HTTP method registrations MUST include the following fields:

• ~method名（`4$sec） ◎ • Method Name (see Section 4)
• `安全$かどうか（ "yes" または "no" ） ◎ • Safe ("yes" or "no", see Section 4.2.1)
• `冪等$かどうか（ "yes" または "no" ） ◎ • Idempotent ("yes" or "no", see Section 4.2.2)
• 仕様~textへの~pointer ◎ • Pointer to specification text

【 `5300$errataに報告あり（ Reported: 2018-03-24 ）： 上の~listには、［ `~cache可能$かどうか（ "yes" または "no" ） ］の~fieldも含めるべき。 それに伴い、 `8.1.3$secの表にも “~cache可能？” の列を追加する（具体的な yes/no は参照先に）。 】

この名前空間に追加される値は、`~IETFによる考査$を要する。 ◎ Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

8.1.2. 新たな~methodに対する考慮点

標準~化された~methodは、汎用である — すなわち，それらは、特定0の［ `~MIME型$／資源の種類／応用 ］のみならず，どの資源にも適用-可能になり得る。 そのような新たな~methodは、［ 単独の［ 応用／~data形式 ］に特有でない，文書 ］内に登録されることが選好される — 直交的な技術は、直交的な仕様に~~価するので。 ◎ Standardized methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, kind of resource, or application. As such, it is preferred that new methods be registered in a document that isn't specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.

~messageの構文解析（`7230-3.3$rfc）は，［ （ `HEAD$m に対する応答は別として）~methodの意味論に依存しない必要がある ］ので、新たな~methodの定義は，要請, 応答いずれの~messageにおいても，構文解析~algoを変更したり, ~message本体が在ることを禁制できない。 新たな~methodの定義は、［ `Content-Length$h ~headerの値に "`0^c" を要求する ］ことにより，［ 長さ 0 の`~message本体$のみが許容される ］ように指定できる。 ◎ Since message parsing (Section 3.3 of [RFC7230]) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a value of "0".

注記： "`M-^c" から開始する~method名は，定義しないこと — その接頭辞は、［ `2774$Rによりアテガわれる意味論を持つ ］ものと誤解釈され易いので。 ◎ Note: Avoid defining a method name that starts with "M-", since that prefix might be misinterpreted as having the semantics assigned to it by [RFC2774].

8.1.3. 登録

"Hypertext Transfer Protocol (HTTP) Method Registry" は、次の登録により拡充された： ◎ The "Hypertext Transfer Protocol (HTTP) Method Registry" has been populated with the registrations below:

   +---------+------+------------+---------------+
   | Method  | Safe | Idempotent | Reference     |
   +---------+------+------------+---------------+
   | CONNECT | no   | no         | Section 4.3.6 |
   | DELETE  | no   | yes        | Section 4.3.5 |
   | GET     | yes  | yes        | Section 4.3.1 |
   | HEAD    | yes  | yes        | Section 4.3.2 |
   | OPTIONS | yes  | yes        | Section 4.3.7 |
   | POST    | no   | no         | Section 4.3.3 |
   | PUT     | no   | yes        | Section 4.3.4 |
   | TRACE   | yes  | yes        | Section 4.3.8 |
   +---------+------+------------+---------------+

8.2.1. 手続-

登録は、次の~fieldを内包しなければナラナイ： ◎ A registration MUST include the following fields:

• `状態s~code$（ 3 桁） ◎ • Status Code (3 digits)
• 短い記述 ◎ • Short Description
• 仕様~textへの~pointer ◎ • Pointer to specification text

~HTTP状態s~code名前空間に追加される値は、 `~IETFによる考査$を要する。 ◎ Values to be added to the HTTP status code namespace require IETF Review (see [RFC5226], Section 4.1).

8.2.2. 新たな状態s~codeに対する考慮点

［ 現在の状態s~codeにより定義されない応答~用の意味論 ］を表出することが必要yなときは、新たな状態s~codeを登録できる。 `状態s~code$は、汎用である — すなわち，それらは、特定0の［ `~MIME型$／資源の種類／~HTTPの応用 ］のみならず，どの資源にも適用-可能になり得る。 そのようなわけで、新たな状態s~codeは，［ 単独の応用 ］に特有でない文書に登録されることが選好される。 ◎ When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can be registered. Status codes are generic; they are potentially applicable to any resource, not just one particular media type, kind of resource, or application of HTTP. As such, it is preferred that new status codes be registered in a document that isn't specific to a single application.

新たな状態s~codeには、`6$secにて定義される類別のいずれかに入ることが要求される。 既存の構文解析器が，応答~messageを処理できるようにするため、新たな状態s~codeは，~payloadを不許可には できない — `~payload本体$を長さ 0 に義務化することはできるが。 ◎ New status codes are required to fall under one of the categories defined in Section 6. To allow existing parsers to process the response message, new status codes cannot disallow a payload, although they can mandate a zero-length payload body.

［ まだ広範に配備されてない，新たな状態s~code ］用の提案は、［ 登録されることになる明瞭な総意が得られる ］まで，［ ~code用に特定の番号を割振ることを避ける ］~OUGHT — 早期の草案は、代わりに，［ 提案される状態s~codeの`応答class$ ］を，尚早に番号を消費することなく指示する［ "`4NN^c" や, "`3N0^c" 〜 "`3N9^c" などの表記法 ］を利用できる。 ◎ Proposals for new status codes that are not yet widely deployed ought to avoid allocating a specific number for the code until there is clear consensus that it will be registered; instead, early drafts can use a notation such as "4NN", or "3N0" .. "3N9", to indicate the class of the proposed status code(s) without consuming a number prematurely.

新たな状態s~codeの定義は、以下について［ 説明する／指定する ］~OUGHT： ◎ ↓

• 要請が［ その状態s~codeを包含する応答を~~生じさせる ］ための条件（例： `要請~header$や~methodの組合nなど）。 ◎ The definition of a new status code ought to explain the request conditions that would cause a response containing that status code (e.g., combinations of request header fields and/or method(s)) along with＼
• `応答~header$との依存関係 — 例えば，その状態s~codeを応答に利用するときに ⇒＃ 要求される~headerは何か？／ どの~headerが意味論を改変し得るか？／ 意味論が更に精緻化される~headerは何か？ ◎ any dependencies on response header fields (e.g., what fields are required, what fields can modify the semantics, and what header field semantics are further refined when used with the new status code).

• `既定で~cache可能である$かどうか。 ◎ The definition of a new status code ought to specify whether or not it is cacheable.＼

  状態s~codeが何であれ、明示的な`鮮度~情報$を伴う応答は，~cacheできることに注意 — しかしながら，［ ~cache可能として定義された状態s~code ］を伴う応答は、［ 明示的な`鮮度~情報$がなくても~cacheする ］ことが許容される。 同様に，状態s~codeの定義は、~cacheの挙動に拘束を設置できる。 更なる情報は`7234$Rを見よ。 ◎ Note that all status codes can be cached if the response they occur in has explicit freshness information; however, status codes that are defined as being cacheable are allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints upon cache behavior. See [RFC7234] for more information.

• ~payloadに，［ 識別される資源（`3.1.4.1$sec）への何らかの結付け ］が含意されるかどうか。 ◎ Finally, the definition of a new status code ought to indicate whether the payload has any implied association with an identified resource (Section 3.1.4.1).

8.2.3. 登録

状態s~code~registryは、次の登録により更新された： ◎ The status code registry has been updated with the registrations below:

   +-------+-------------------------------+----------------+
   | Value | Description                   | Reference      |
   +-------+-------------------------------+----------------+
   | 100   | Continue                      | Section 6.2.1  |
   | 101   | Switching Protocols           | Section 6.2.2  |
   | 200   | OK                            | Section 6.3.1  |
   | 201   | Created                       | Section 6.3.2  |
   | 202   | Accepted                      | Section 6.3.3  |
   | 203   | Non-Authoritative Information | Section 6.3.4  |
   | 204   | No Content                    | Section 6.3.5  |
   | 205   | Reset Content                 | Section 6.3.6  |
   | 300   | Multiple Choices              | Section 6.4.1  |
   | 301   | Moved Permanently             | Section 6.4.2  |
   | 302   | Found                         | Section 6.4.3  |
   | 303   | See Other                     | Section 6.4.4  |
   | 305   | Use Proxy                     | Section 6.4.5  |
   | 306   | (Unused)                      | Section 6.4.6  |
   | 307   | Temporary Redirect            | Section 6.4.7  |
   | 400   | Bad Request                   | Section 6.5.1  |
   | 402   | Payment Required              | Section 6.5.2  |
   | 403   | Forbidden                     | Section 6.5.3  |
   | 404   | Not Found                     | Section 6.5.4  |
   | 405   | Method Not Allowed            | Section 6.5.5  |
   | 406   | Not Acceptable                | Section 6.5.6  |
   | 408   | Request Timeout               | Section 6.5.7  |
   | 409   | Conflict                      | Section 6.5.8  |
   | 410   | Gone                          | Section 6.5.9  |
   | 411   | Length Required               | Section 6.5.10 |
   | 413   | Payload Too Large             | Section 6.5.11 |
   | 414   | URI Too Long                  | Section 6.5.12 |
   | 415   | Unsupported Media Type        | Section 6.5.13 |
   | 417   | Expectation Failed            | Section 6.5.14 |
   | 426   | Upgrade Required              | Section 6.5.15 |
   | 500   | Internal Server Error         | Section 6.6.1  |
   | 501   | Not Implemented               | Section 6.6.2  |
   | 502   | Bad Gateway                   | Section 6.6.3  |
   | 503   | Service Unavailable           | Section 6.6.4  |
   | 504   | Gateway Timeout               | Section 6.6.5  |
   | 505   | HTTP Version Not Supported    | Section 6.6.6  |
   +-------+-------------------------------+----------------+

8.3.1. 新たな~headerに対する考慮点

`~header$は、［ ~message／ その~payload／ `~target資源$／ 接続（すなわち`制御~data$） ］についての~dataを通信するために利用できる，［ ~key:値 ］の ~pairである。 ~HTTP~messageにおける~header構文の一般的な定義は、`7230-3.2$rfcを見よ。 ◎ Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource, or the connection (i.e., control data). See Section 3.2 of [RFC7230] for a general definition of header field syntax in HTTP messages.

`~header名$に課される要件は、`BCP90$rにて定義される。 ◎ The requirements for header field names are defined in [BCP90].

新たな~headerを定義する仕様の策定者には、［ 名前を実用的な短さに保つ ］こと, および［ その~headerが~Internet上で利用されることは 決してないのでない限り，名前に "`X-^c" 接頭辞を付けない ］ことを勧める： "`X-^c" 接頭辞~idiomは、実施において，広範囲に誤用されてきた — それに意図されていた利用は、［ ~proprietary~softwareや~intranet処理の内側における，名前~衝突を避ける仕組み ］に限られていた — その接頭辞により［ 私的な名前が，新たに登録される~Internet名と決して衝突しない ］ことが確保されるので。 更なる情報は`BCP178$rを見よ。 ◎ Authors of specifications defining new fields are advised to keep the name as short as practical and not to prefix the name with "X-" unless the header field will never be used on the Internet. (The "X-" prefix idiom has been extensively misused in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see [BCP178] for further information).

新たな`~header値$の構文は、概して ~ABNF （`5234$R）を利用して — 必要yなら，`7230-7$rfcに定義される拡張も利用して — 定義される。 また、通例的に，US-ASCII 文字の範囲に拘束される。 より広~範囲の文字を必要とする~headerは、`5987$Rにて定義されるものなどの，符号化法を利用できる。 ◎ New header field values typically have their syntax defined using ABNF ([RFC5234]), using the extension defined in Section 7 of [RFC7230] as necessary, and are usually constrained to the range of US-ASCII characters. Header fields needing a greater range of characters can use an encoding such as the one defined in [RFC5987].

生の~header値における頭部／尾部の`空白$は、`~header$を構文解析する際に除去される（`7230-3.2.4$rfc）。 ~header定義において，値において頭部／尾部の`空白$が有意になる所では、 `quoted-string$p などの~container構文を~~要することになる。 ◎ Leading and trailing whitespace in raw field values is removed upon field parsing (Section 3.2.4 of [RFC7230]). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such as quoted-string (Section 3.2.6 of [RFC7230]).

~comma （"`,^c"）は，［ `~header値$の各~entry間の汎用 区切子 ］として利用されるので、`~header値$に許容されるときは，~~注意して扱う必要がある。 ~commaを包含し得る成分は、概して，［ `quoted-string$p ~ABNF生成規則を利用する`二重引用符$ ］で保護される。 ◎ Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed in the field-value. Typically, components that might contain a comma are protected with double-quotes using the quoted-string ABNF production.

Example-URI-Field: "http://example.com/a.html,foo", "http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"

`二重引用符$ 区切子は、ほぼ常に， `quoted-string$p 生成規則と伴に利用されることに注意 — `二重引用符$の内側で異なる構文を利用した場合、不必要な混同をもたらす見込みが高くなる。 ◎ Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside double-quotes will likely cause unnecessary confusion.

多くの~headerは、（文字大小無視な）名前が~~付与された~parameterを内包する形式を利用する（例えば `Content-Type$p ）。 ~parameter値の構文に［ 引用符~無し（ `token$p ）と有り（ `quoted-string$p ） ］の両~形を許容すれば、`受信者$は，既存の構文解析器を利用できるようになる。 【！~componentの利用を可能化し得る＊ 】 その場合、~parameter値の意味は，それに利用される構文 【における引用符の有無】 には依存しない~OUGHT（例えば、`~MIME型$に対する~parameterの取扱いについての注記を見よ）。 ◎ Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in Section 3.1.1.5). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for it (for an example, see the notes on parameter handling for media types in Section 3.1.1.1).

新たな~headerを定義する仕様の策定者には、次を文書化することも考慮することを勧める： ◎ Authors of specifications defining new header fields are advised to consider documenting:

• ~header値は，単独の値をとるか，それとも（~commaで区切られる）~listとり得るか？ — `7230-3.2$rfcを見よ。 ◎ • Whether the field is a single value or whether it can be a list (delimited by commas; see Section 3.2 of [RFC7230]).＼

  ~list構文を利用しない場合は、複数~個の~headerが生じたときに，~messageを扱う方法も（その~headerを無視するのが既定としてイミを成し得るかもしれないが、常に~~正しい選択になるとは限らない）。 ◎ If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default would be to ignore the field, but this might not always be the right choice).＼

  ~headerの定義が~list構文を許容していなくても、中継者や~software~libraryは，［ 複数の~header~instanceを一つに`結合-$し得る ］ことに注意。 堅牢な形式は、受信者がこれらの状況を発見することを可能化する。 例えば： ◎ Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the field's definition not allowing the list syntax. A robust format enables recipients to discover these situations＼

  • 良い例： "`Content-Type$p" — ~commaが出現し得るのは，引用符~付き文字列の内側のみなので ◎ (good example: "Content-Type", as the comma can only appear inside quoted strings;＼
  • 悪い例： "`Location$p" — ~URIの内側に~commaが生じ得る ◎ bad example: "Location", as a comma can occur inside a URI).
• ~headerは，どの条件の下で利用できるか？ — 例： 応答のみ ／ 要請のみ ／ すべての~message ／ 特定0の`要請~method$に対する応答のみ, 等々。 ◎ • Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses to a particular request method, etc.
• ~headerは、 `PUT$m 要請に際して それを解する`生成元~server$により格納されるべきか？ ◎ • Whether the field should be stored by origin servers that understand it upon a PUT request.
• ~headerの意味論は、既存の`要請~method$や状態s~codeなどの文脈の下で，更に精緻化されるか？ ◎ • Whether the field semantics are further refined by the context, such as by existing request methods or status codes.
• ［ `~header名$を，`Connection$h ~header内に~listする ］ことは適切になるか？（すなわち，`隣点間~header$か？）。 ◎ • Whether it is appropriate to list the field-name in the Connection header field (i.e., if the header field is to be hop-by-hop; see Section 6.1 of [RFC7230]).
• `中継者$は、どの条件の下で，~headerの値を［ 挿入する／削除する／改変する ］ことが許容されるか？ ◎ • Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.
• ［ `Vary$h `応答~header$内に，`~header名$を~listする ］ことは適切になるか？（例： `要請~header$が，`生成元~server$の内容~選定~algoにより利用されるときなど）。 ◎ • Whether it is appropriate to list the field-name in a Vary response header field (e.g., when the request header field is used by an origin server's content selection algorithm; see Section 7.1.4).
• ~headerは，`~trailer節$内で［ 有用になる／許容-可能 ］か？ ◎ • Whether the header field is useful or allowable in trailers (see Section 4.1 of [RFC7230]).
• ~headerは，何度かの~redirectにまたがって保全される~OUGHTか？ ◎ • Whether the header field ought to be preserved across redirects.
• ~privacyに関係する~dataの開示など，他の追加的な~securityの考慮点を導入するか？ ◎ • Whether it introduces any additional security considerations, such as disclosure of privacy-related data.

8.3.2. 登録

"Message Headers" ~registryは、 次の恒久的な登録により更新された： ◎ The "Message Headers" registry has been updated with the following permanent registrations:

   +-------------------+----------+----------+-----------------+
   | Header Field Name | Protocol | Status   | Reference       |
   +-------------------+----------+----------+-----------------+
   | Accept            | http     | standard | Section 5.3.2   |
   | Accept-Charset    | http     | standard | Section 5.3.3   |
   | Accept-Encoding   | http     | standard | Section 5.3.4   |
   | Accept-Language   | http     | standard | Section 5.3.5   |
   | Allow             | http     | standard | Section 7.4.1   |
   | Content-Encoding  | http     | standard | Section 3.1.2.2 |
   | Content-Language  | http     | standard | Section 3.1.3.2 |
   | Content-Location  | http     | standard | Section 3.1.4.2 |
   | Content-Type      | http     | standard | Section 3.1.1.5 |
   | Date              | http     | standard | Section 7.1.1.2 |
   | Expect            | http     | standard | Section 5.1.1   |
   | From              | http     | standard | Section 5.5.1   |
   | Location          | http     | standard | Section 7.1.2   |
   | Max-Forwards      | http     | standard | Section 5.1.2   |
   | MIME-Version      | http     | standard | Appendix A.1    |
   | Referer           | http     | standard | Section 5.5.2   |
   | Retry-After       | http     | standard | Section 7.1.3   |
   | Server            | http     | standard | Section 7.4.2   |
   | User-Agent        | http     | standard | Section 5.5.3   |
   | Vary              | http     | standard | Section 7.1.4   |
   +-------------------+----------+----------+-----------------+

上の登録の変更~制御者は~IETF-orgである。 ◎ The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

8.4.1. 手続-

`内容~符号法$の登録にあたっては、次の~fieldを含めなければナラナイ： ◎ Content coding registrations MUST include the following fields:

• 名前 ◎ • Name
• 記述 ◎ • Description
• 仕様~textへの~pointer ◎ • Pointer to specification text

`内容~符号法~名$は、`転送~符号法~名$と重なってはてはナラナイ — 符号化法の形式変換が一致していない限り（ `7230$Rに定義される各種 `圧縮~符号法$に該当するものなど）。 ◎ Names of content codings MUST NOT overlap with names of transfer codings (Section 4 of [RFC7230]), unless the encoding transformation is identical (as is the case for the compression codings defined in Section 4.2 of [RFC7230]).

この名前空間に追加されることになる値は、 `~IETFによる考査$を要する。 また、この節にて定義される`内容~符号法$の目的に適合しなければナラナイ。 ◎ Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]) and MUST conform to the purpose of content coding defined in this section.

8.4.2. 登録

"HTTP Content Coding Registry" は、次の登録により更新された： ◎ The "HTTP Content Coding Registry" has been updated with the registrations below:

   +----------+----------------------------------------+---------------+
   | Name     | Description                            | Reference     |
   +----------+----------------------------------------+---------------+
   | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
   |          | Accept-Encoding)                       |               |
   +----------+----------------------------------------+---------------+