[http](RFC9205) 諸々の編集

Author: triple-underscore

http-app-bcp-ja.html

@@ -121,6 +121,7 @@
 	HTTPcookieExt:http-cookie-ext-ja.html
 RFC6454:RFC6454-ja.html
 CAPABILITY-URLS:capability-urls-ja.html
+HTTPquery:http-query-method-ja.html
 
 ●●words_table
 
@@ -167,6 +168,7 @@
 優先度:priority::~
 	優先度をどう選ぶか:how 〜 chooses to prioritize
 早期:early::~
+	~transport用の~port:transport port
 
 	●保安
 ambient:
@@ -244,7 +246,7 @@
 機能:function:~
 信頼性:reliability:~
 節約-:save:~
-解法:solution:~
+解決策:solution:~
 努める:striveする:~
 多岐:diverse:~
 	~~多岐に渡る:vary widely
@@ -886,7 +888,7 @@ <h2 title="Is HTTP Being Used?">2. ~HTTPは利用されているか？</h2>
 </p>
 <ul>
 	<li>
-~transport~portに［
+~transport用の~portに［
 80 ／ 443
 ］【すなわち， `http$c ／ `https$c 用の既定の~port番号】を利用するもの。
 ◎
@@ -970,7 +972,7 @@ <h3 title="Non-HTTP Protocols">2.1. 非~HTTP~protocol</h3>
 そのような仕様は、
 ~HTTPの［
 ~URI~scheme／
-~transport~port／
+~transport用の~port／
 ~ALPN~protocol~ID／
 ~IANA~registry
 ］を利用してはナラナイ
@@ -1394,7 +1396,7 @@ <h3 title="Specifying Server Behaviour">4.2. ~serverの挙動の指定-法</h3>
 <p>
 応用は、［
 `~link関係$により識別され，指定された挙動を実装する`資源$
-］の集合を［
+］たちが成す集合を［
 これらの~protocol要素で構成して定義する
 ］ことにより，自身の運用を定義できる
 — 次に挙げるものを含め：
@@ -1596,20 +1598,31 @@ <h3 title="Specifying URLs">4.4. ~URLの指定-法</h3>
 </p>
 
 <p>
-したがって，仕様の書き手は、［
-`~client$が応用の~URLを発見する
-］ことを許容するための何らかの仕組みが必要になる。
-加えて、［
+したがって，仕様の書き手は、
+次を指定する必要がある：
+◎
+Therefore, the specification writer needs＼
+</p>
+<ul>
+	<li>
+応用の~URLを発見することを`~client$に許容するための，何らかの仕組み
+◎
+some mechanism to allow clients to discover an application's URLs.＼
+</li>
+	<li>
 応用に利用されるべき~URL~scheme（たち）
-］および［
+◎
+Additionally, they need to specify which URL scheme(s) the application should be used with＼
+</li>
+	<li>
 応用は［
 専用な~port,
 ~HTTP用の既定の~port【！reuse HTTP's port(s)】
 ］どちらを利用するか
-］も指定する必要がある。
 ◎
-Therefore, the specification writer needs some mechanism to allow clients to discover an application's URLs. Additionally, they need to specify which URL scheme(s) the application should be used with and whether to use a dedicated port or to reuse HTTP's port(s).
-</p>
+and whether to use a dedicated port or to reuse HTTP's port(s).
+</li>
+</ul>
 
 			<section id="discovering-an-applications-urls">
 <h4 title="Discovering an Application's URLs">4.4.1. 応用の~URLの発見-法</h4>
@@ -1720,11 +1733,9 @@ <h4 title="Considering URI Schemes">4.4.2. ~URI~schemeを考慮するとき</h4>
 ］を使役することになる。
 ［
 認証, 完全性, 機密性
-］を供する, および
-大規模な監視~攻撃を軽減するには、
-"`https^c" が`推奨される^2119
-`RFC7258$r 
-。
+］を供するため, および
+大規模な監視~攻撃 `RFC7258$r を軽減するためには、
+"`https^c" が`推奨される^2119。
 ◎
 Applications that use HTTP will typically employ the "http" and/or "https" URI schemes. "https" is RECOMMENDED to provide authentication, integrity, and confidentiality, as well as to mitigate pervasive monitoring attacks [RFC7258].
 </p>
@@ -1742,7 +1753,7 @@ <h4 title="Considering URI Schemes">4.4.2. ~URI~schemeを考慮するとき</h4>
 ~Web~browserは、
 改変されない限り，新たな~schemeを~supportしない。
 ~Web~browserで新たな~URI~schemeを登録することはアリであるが
-（例：`HTML$r における `registerProtocolHandler()^c,
+（例：`HTML$r における `registerProtocolHandler()＠~HTMLnavigator#custom-handlers$c,
 あるいは いくつかの~proprietaryな~approachで）、
 これらの仕組み用の~supportは、
 すべての~browserから共有されるとは限らず，それらの能力は~browserごとに変わり得る。
@@ -1765,8 +1776,9 @@ <h4 title="Considering URI Schemes">4.4.2. ~URI~schemeを考慮するとき</h4>
 	<li>
 ~URLは、
 ~HTTPによる産物~内で共通的に生じることに加え，
-自動的に（例： `Location$h 応答~header内で）`生成-$されることが多いので、
-新たな~schemeが一貫して利用されることを確保するのは，困難にもなり得る。
+自動的に（例： `Location$h 応答~header内で）`生成-$されることが多いので、［
+新たな~schemeが一貫して利用される
+］ことを確保することは，困難にもなり得る。
 ◎
 Because URLs commonly occur in HTTP artefacts and are often generated automatically (e.g., in the Location response header field), it can be difficult to ensure that the new scheme is used consistently. 
 </li>
@@ -1776,10 +1788,10 @@ <h4 title="Considering URI Schemes">4.4.2. ~URI~schemeを考慮するとき</h4>
 ］~URLを利用して可用になる。
 それらの~URLは、［
 ~security／運用能
-］の課題が在り得るような利用に “漏洩し得る”。
+］の課題が在り得るような利用に “漏洩-” し得る。
 例えば，新たな~schemeを利用しても、［
 要請が “通常の” ~Web~siteへは送信されない
-］ことを確保するのは，失敗する見込みが高い。
+］ことを確保することは，失敗する見込みが高い。
 ◎
 The resources identified by the new scheme will still be available using "http" and/or "https" URLs. Those URLs can "leak" into use, which can present security and operability issues. For example, using a new scheme to ensure that requests don't get sent to a "normal" Web site is likely to fail.
 </li>
@@ -1834,8 +1846,8 @@ <h4 title="Choosing Transport Ports">4.4.3. ~transport用の~portを選ぶとき
 — あるいは、
 他の~portにも配備できる。
 この裁定は、
-配備~時点に下されることもあれば，応用の仕様により奨励されることもあろう
-（例：ある~portを，その応用~用として登録することにより）。
+配備~時点に為されることもあれば，応用の仕様により奨励されることもあろう
+（例：ある~portを，当の応用~用として登録することにより）。
 ◎
 Applications can use the applicable default port (80 for HTTP, 443 for HTTPS), or they can be deployed upon other ports. This decision can be made at deployment time or might be encouraged by the application's specification (e.g., by registering a port for that application).
 </p>
@@ -1906,7 +1918,7 @@ <h3 title="Using HTTP Methods">4.5. ~HTTP~methodの利用-法</h3>
 </p>
 
 <p>
-歴史的に，一部の応用（例： `RFC4791$r ）は応用に特有な~methodを定義したが、
+歴史的に，一部の応用（例： `RFC4791$r ）は自身に特有な~methodを定義したが、
 `HTTP$r は，今やこれを禁止する。
 ◎
 While historically some applications (e.g., [RFC4791]) have defined application-specific methods, [HTTP] now forbids this.
@@ -1930,9 +1942,7 @@ <h4 title="GET">4.5.1. `GET^m</h4>
 
 <p>
 `GET$m は、
-最も［
-共通的な, かつ有用な
-］~HTTP~methodである。
+最も共通的な, かつ最も有用な~HTTP~methodである。
 その検索取得の意味論は、［
 ~caching, 副作用が無い~link法
 ］を許容する
@@ -1950,7 +1960,7 @@ <h4 title="GET">4.5.1. `GET^m</h4>
 これは，~Web閲覧において馴染みな~patternであり、
 その結果は~cacheできるので，高価になることが多い処理nの効率を改善する。
 しかしながら，~URIの構文は制限されているので、
-`GET$m で~queryを表出するのは手に余る事例もあるかもしれない
+`GET$m で~queryを表出することは手に余る事例もあるかもしれない
 — 特に、
 ~queryを成すある項が~binary~dataで形成される場合，
 ~URI構文に適合するよう符号化する必要がある。
@@ -1993,6 +2003,12 @@ <h4 title="GET">4.5.1. `GET^m</h4>
 In these cases, an application using HTTP might consider using POST to express queries in the request's content; doing so avoids encoding overhead and URL length limits in implementations. However, in doing so, it should be noted that the benefits of GET such as caching and linking to query results are lost. Therefore, applications using HTTP that require support for POST queries ought to consider allowing both methods.
 </p>
 
+<p class="trans-note">【
+参考：
+これらの課題に取組む~methodとして，
+`QUERY＠~HTTPquery#query$m が提案されている。
+】</p>
+
 <p>
 `GET$m 要請の処理により，当の応用の状態が変更される, その他の［
 `~client$にとって有意になり得る副作用
@@ -2095,7 +2111,7 @@ <h4 title="OPTIONS">4.5.2. `OPTIONS^m</h4>
 	<li>
 ~server-wide~metadata用に、
 `周知な~URI^cite【 "`/.well-known/^c" 】 `WELL-KNOWN-URI$r を作成するか，
-適切になるなら既存のものを利用する（例： host-meta `RFC6415$r ）。
+適切になるなら既存のそれ（例： host-meta【 "`/.well-known/host-meta^c" 】 `RFC6415$r ）を利用する。
 ◎
 For server-wide metadata, create a well-known URI [WELL-KNOWN-URI] or use an already existing one if appropriate (e.g., host-meta [RFC6415]).
 </li>
@@ -2123,12 +2139,13 @@ <h4 title="OPTIONS">4.5.2. `OPTIONS^m</h4>
 <h3 title="Using HTTP Status Codes">4.6. ~HTTP状態s~codeの利用-法</h3>
 
 <p>
-`状態s~code$は、
+`状態s~code$は、［
 汎用な~HTTP~component
 — `~cache$, `媒介者$, `~client$など —
-の便益, および応用~自身のために意味論を伝達する。
+および，応用~自身
+］の便益のために意味論を伝達する。
 しかしながら、
-それらの利用にあたって応用が遭遇し得る陥穽がいくつかある。
+それらの利用にあたっては，応用が遭遇し得る陥穽もいくつかある。
 ◎
 HTTP status codes convey semantics both for the benefit of generic HTTP components -- such as caches, intermediaries, and clients -- and applications themselves. However, applications can encounter a number of pitfalls in their use.
 </p>
@@ -2164,8 +2181,8 @@ <h3 title="Using HTTP Status Codes">4.6. ~HTTP状態s~codeの利用-法</h3>
 適用-可能な状態s~codeの有限な空間が枯渇する状況に至ることが多い。
 これは転じて，例えば次のような不良な実施へ導く
 ⇒＃
-新たな，応用に特有な状態s~codeを創出すること／
-既存の状態s~codeを，その意味論と当の応用の意味論との~~関連性が希薄でしかないのに利用すること
+新たな，応用に特有な状態s~codeを創出する／
+既存の状態s~codeを，その意味論と当の応用の意味論との~~関連性が希薄でしかないのに利用する
 ◎
 Furthermore, mapping application errors to individual HTTP status codes one-to-one often leads to a situation where the finite space of applicable HTTP status codes is exhausted. This, in turn, leads to a number of bad practices -- including minting new, application-specific status codes or using existing status codes even though the link between their semantics and the application's is tenuous at best.
 </p>
@@ -2289,7 +2306,7 @@ <h4 title="Redirection">4.6.1. ~redirection</h4>
 Whether they are permanent or temporary. Permanent redirects can be used to update links stored in the client (e.g., bookmarks), whereas temporary ones cannot. Note that this has no effect on HTTP caching; it is completely separate.
 </li>
 	<li>
-~redirectされた要請の~methodを `POST$m から `GET$m に変更するのを許容するかどうか。
+~redirectされた要請の~methodを `POST$m から `GET$m に変更することを許容するかどうか。
 ~Web~browserは、
 一般に，［
 `301$st0, `302$st0
@@ -2334,7 +2351,9 @@ <h4 title="Redirection">4.6.1. ~redirection</h4>
 <p>
 状態s~code `303$st は、［
 演算の結果は、
-異なる所在にて `GET$m を利用して可用である
+異なる所在にて
+— `GET$m を利用して —
+可用である
 ］ことを~clientに伝えるために利用できる。
 ◎
 The 303 (See Other) status code can be used to inform the client that the result of an operation is available at a different location using GET.
@@ -2539,7 +2558,7 @@ <h3 title="Defining Message Content">4.8. ~message内容の定義-法</h3>
 応用は、
 自身が定義する各~形式ごとに，別個な`~MIME型$を登録するべきである。
 そうすれば、
-それらは一義的に識別され，それらを利用するために折衝するのもアリになる。
+それらは一義的に識別され，それらを利用するために折衝することもアリになる。
 更なる情報は、
 `RFC6838$r を見よ。
 ◎
@@ -2572,7 +2591,7 @@ <h3 title="Leveraging HTTP Caching">4.9. ~HTTP~cache法の活用-法</h3>
 
 <p>
 ~HTTPを利用している応用は、
-~cache法の利点を得ようと設計されていないときでも、
+~cache法の利点をとるよう設計されていないときでも、
 `~cache$が応答をどう取扱うかを考慮する必要はある
 — （~network, `~server$, `~client$, 介在している基盤の）どこかに~cachingが差し挟まれても，正しい挙動を保全するため。
 ◎
@@ -2588,7 +2607,8 @@ <h4 title="Freshness">4.9.1. 鮮度</h4>
 複数の`~client$からの要請を満足するために応答を再利用すること／
 単独の~clientが同じ要請を繰返に為すこと
 ］を許容する。
-一般に，再利用しても安全な何かに対しては、
+一般に、
+再利用しても安全なものには，
 鮮度~維持期間をアテガうことを考慮すること。
 ◎
 Assigning even a short freshness lifetime ([HTTP-CACHING], Section 4.2) -- e.g., 5 seconds -- allows a response to be reused to satisfy multiple clients and/or a single client making the same request repeatedly. In general, if it is safe to reuse something, consider assigning a freshness lifetime.
@@ -2609,10 +2629,11 @@ <h4 title="Freshness">4.9.1. 鮮度</h4>
 <p>
 ほとんどの応答に対しては、
 それを~cacheするために `public$sdir 応答~指令を追加することは，必要yでない
-— 必要yであるのは、［
+— 必要yであるのは、
+次に挙げるときに限られる
+⇒＃
 認証された応答を格納するのが望ましいとき／
 応答の`状態s~code$は~cacheにより解されない, かつ明示的な鮮度~情報は可用でないとき
-］に限られる。
 ◎
 It is not necessary to add the public response directive ([HTTP-CACHING], Section 5.2.2.9) to cache most responses; it is only necessary when it's desirable to store an authenticated response, or when the status code isn't understood by the cache and there isn't explicit freshness information available.
 </p>
@@ -3134,7 +3155,7 @@ <h3 title="Maintaining Application Boundaries">4.14. 応用~境界の保守-法<
 </p>
 
 <p>
-これらの課題に対する解法の一つは、
+これらの課題に対する解決策の一つは、
 応用に対し専用な~hostnameを要求して，
 応用が一意な生成元に属するようにすることである。
 しかしながら，［
@@ -3150,15 +3171,16 @@ <h3 title="Maintaining Application Boundaries">4.14. 応用~境界の保守-法<
 
 <p>
 したがって，~HTTPを利用している応用は、
-複数の応用が同じ生成元に属することを許容するよう，努めるべきである。
-特定的には、［
-`Cookie$h や~HTTP認証~realm `HTTP$r その他の，生成元~~全般な~HTTPの仕組み
-］の利用を指定するときには，~HTTPを利用している応用は：
+複数の応用が同じ生成元に属することを許容するよう，努めるべきである
+— 特定的には
+⇒
 ［
+`Cookie$h や~HTTP認証~realm `HTTP$r その他の，生成元~~全般な~HTTPの仕組み
+］の利用を指定するときには、［
 特定0の名前の利用を義務付ける
 ］べきではなく［
 代わりに，各~配備に応用を環境設定してもらうようにする
-］べきであり、［
+］べきであり，［
 応用に指定された仕組みを利用して，応用の視野を当の生成元の一部に絞ること
 ］に関する考慮点を与えるべきである。
 ◎
@@ -3169,7 +3191,7 @@ <h3 title="Maintaining Application Boundaries">4.14. 応用~境界の保守-法<
 現代の~Web~browserは、
 私用な情報が漏洩されるのを避けるため，
 ある生成元に属する内容が別の生成元に属する`資源$へ~accessする能を拘束する。
-したがって，非同一-生成元に属する~dataを~browserに公開するよう望む応用は、
+したがって，非同一-生成元な~dataを~browserに公開するよう望む応用は、
 `~CORS~protocol$ `FETCH$r を実装する必要がある。
 ◎
 Modern Web browsers constrain the ability of content from one origin to access resources from another to avoid leaking private information. As a result, applications that wish to expose cross-origin data to browsers will need to implement the CORS protocol; see [FETCH].