[http] Rewrite Identifying HTTPS Servers httpwg/http-core#437

http-messaging-ja.html

@@ -13,8 +13,8 @@
 ●●options
 
 spec_title:HTTP/1.1: Messaging
-spec_date:2020-08-24
-trans_update:2020-08-17
+spec_date:2020-08-27
+trans_update:2020-08-28
 source_checked:200204
 page_state_key:HTTP
 original_url:https://httpwg.org/http-core/draft-ietf-httpbis-messaging-latest.html
@@ -85,8 +85,8 @@
 A:#collected.abnf
 B:#differences.between.http.and.mime
 C.2:#changes.from.rfc.7230
-D.10:#change.log
-	D.10:#changes.since.08
+D.13:#change.log
+	D.13:#changes.since.11
 著作者の~address:#rfc.authors
 
 Semantics/4.2:~HTTPsem#protocol.version
@@ -95,7 +95,7 @@
 Semantics/5.5:~HTTPsem#abnf.extension
 Semantics/5.6:~HTTPsem#trailer.fields
 Semantics/6.3:~HTTPsem#routing.inbound
-Semantics/6.7:~HTTPsem#message.forwarding
+Semantics/6.6:~HTTPsem#message.forwarding
 Semantics/7.1.1.2:~HTTPsem#canonicalization.and.text.defaults
 Semantics/8.2.2:~HTTPrq#idempotent.methods
 Semantics/5.4.1.5:~HTTPsem#http.date
@@ -162,6 +162,8 @@
 9.4:#persistent.concurrency
 9.5:#persistent.failures
 9.6:#persistent.tear-down
+9.7:#tls.connection.initiation
+9.8:#tls.connection.closure
 10:#enclosing.messages
 10.1:#media.type.message.http
 10.2:#media.type.application.http
@@ -263,6 +265,7 @@
 alert:
 peer:
 reset::::リセット
+handshake::::ハンドシェイク
 再符号され:recode::符号し直され::コードし直され
 時間制限:timeout::~::タイムアウト
 梱包:packaging:~
@@ -273,6 +276,9 @@
 自動訂正:autocorrect:~
 解体:tear-down:~
 	^en:head-of-line blocking
+起動:initiation:~
+
+	^i:ClientHello
 
 	●構文
 space:
@@ -338,6 +344,7 @@
 	伝送し直:retransmit
 	格納-:storage
 	書込み側のみ~close:half-close
+	場合:potential
 
 	●他の語
 	一度:once
@@ -499,9 +506,9 @@ <h2 title="Editorial Note">編集上の注記</h2>
 </p>
 
 <p>
-この草案における変更点は、 `D.10$sec に要約されている。
+この草案における変更点は、 `D.13$sec に要約されている。
 ◎
-The changes in this draft are summarized in Appendix D.10.
+The changes in this draft are summarized in Appendix D.13.
 </p>
 
 	</section>
@@ -1278,7 +1285,7 @@ <h4 title="origin-form">3.2.1. `origin-form^p</h4>
 を送信しなければナラナイ。
 また、 `Host$h ~headerも，その定義に従って送信することになる。
 ◎
-When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. A Host header field is also sent, as defined in Section 6.6 of [Semantics].
+When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. A Host header field is also sent, as defined in Section 6.5 of [Semantics].
 </p>
 
 <div class="example">
@@ -1343,10 +1350,10 @@ <h4 title="absolute-form">3.2.2. `absolute-form^p</h4>
 `request-target$p が指示する`生成元~server$へ向けて，直に
 ］同じ要請を為す。
 そのような~messageの “回送-法” に課される要件は、
-`Semantics/6.7$sec
+`Semantics/6.6$sec
 にて定義される。
 ◎
-The proxy is requested to either service that request from a valid cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in Section 6.7 of [Semantics].
+The proxy is requested to either service that request from a valid cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in Section 6.6 of [Semantics].
 </p>
 
 <div class="example">
@@ -1573,7 +1580,7 @@ <h3 title="Reconstructing the Target URI">3.3. ~target~URIの再構築-法</h3>
 </li>
 			<li>
 他の場合，要請は［
-~TLSで~secure化された~TCP接続
+~secure化された接続
 ］越しに受信されたならば
 ⇒
 "`https$c"
@@ -1586,7 +1593,9 @@ <h3 title="Reconstructing the Target URI">3.3. ~target~URIの再構築-法</h3>
 		</ol>
 
 ◎
-If the server's configuration (or outbound gateway) provides a fixed URI scheme, that scheme is used for the target URI. Otherwise, if the request is received over a TLS-secured TCP connection, the target URI's scheme is "https"; if not, the scheme is "http".
+If the server's configuration (or outbound gateway) provides a fixed URI scheme, that scheme is used for the target URI. Otherwise, if the request is received over a secured connection, the target URI's scheme is "https"; if not, the scheme is "http".
+
+received over a TLS-secured TCP connection, 
 </li>
 	<li>
 <p>
@@ -1690,9 +1699,9 @@ <h3 title="Reconstructing the Target URI">3.3. ~target~URIの再構築-法</h3>
 </pre>
 
 <p>
-~TLSで~secure化された~TCP接続~越しに受信された，次の~messageの：
+~secure化された接続~越しに受信された，次の~messageの：
 ◎
-Example 2: the following message received over a TLS-secured TCP connection
+Example 2: the following message received over a secured connection
 </p>
 
 <pre class="lang-http">
@@ -1881,7 +1890,7 @@ <h2 title="Field Syntax">5. ~fieldの構文</h2>
 — その名前を~HTTP~headerとして利用すると、
 `Connection$h ~headerの "`close$c" `接続~option$と競合するかもしれないので。
 ◎
-Furthermore, the field name "Close" is reserved, since using that name as an HTTP header field might conflict with the "close" connection option of the Connection header field (Section 6.9 of [Semantics]).
+Furthermore, the field name "Close" is reserved, since using that name as an HTTP header field might conflict with the "close" connection option of the Connection header field (Section 6.8 of [Semantics]).
 ◎
 Table 2
 Field Name 	Status 	Ref. 	Comments
@@ -3238,7 +3247,7 @@ <h3 title="Negotiating Transfer Codings">7.4. 転送~符号法の折衝-法</h3>
 ］を防ぐため —
 `Connection$h ~headerの中に "`TE^c" `接続~option$も送信しなければナラナイ。
 ◎
-Since the TE header field only applies to the immediate connection, a sender of TE MUST also send a "TE" connection option within the Connection header field (Section 6.9 of [Semantics]) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
+Since the TE header field only applies to the immediate connection, a sender of TE MUST also send a "TE" connection option within the Connection header field (Section 6.8 of [Semantics]) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
 </p>
 
 		</section>
@@ -3482,7 +3491,7 @@ <h3 title="Persistence">9.3. 持続性</h3>
 【！ or not based on = or not, based on 】
 ］を決定する：
 ◎
-A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and Connection header field (Section 6.9 of [Semantics]), if any:
+A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and Connection header field (Section 6.8 of [Semantics]), if any:
 </p>
 <ol>
 	<li>
@@ -3798,7 +3807,7 @@ <h3 title="Tear-down">9.6. 解体</h3>
 ］~pair
 ］の後に，接続を~closeしたいと望むとき それを送信するベキである。
 ◎
-The Connection header field (Section 6.9 of [Semantics]) provides a "close" connection option that a sender SHOULD send when it wishes to close the connection after the current request/response pair.
+The Connection header field (Section 6.8 of [Semantics]) provides a "close" connection option that a sender SHOULD send when it wishes to close the connection after the current request/response pair.
 </p>
 
 <div class="p">
@@ -3976,11 +3985,33 @@ <h3 title="Tear-down">9.6. 解体</h3>
 — ~HTTP11は、~transportからは独立なので。
 ◎
 Note that a TCP connection that is half-closed by the client does not delimit a request message, nor does it imply that the client is no longer interested in a response. In general, transport signals cannot be relied upon to signal edge cases, since HTTP/1.1 is independent of transport.
+</p>
+
+		</section>
+		<section id="tls.connection.initiation">
+<h3 title="TLS Connection Initiation">9.7. ~TLS接続の起動</h3>
+
+<p>
+概念的に，~TLS越しの~HTTPは、単純に，~HTTP~messageを［
+~TLSを介して~secure化された接続
+`RFC8446$r
+］越しに送信する。
+◎
+Conceptually, HTTP/TLS is simply sending HTTP messages over a connection secured via TLS [RFC8446].
+</p>
+
+<p>
+~HTTP~clientは、~TLS~clientとしても動作する。
+`~client$は、適切な~port上で`~server$への接続を起動して，~TLS~handshakeを始めるために~TLS `ClientHello^i を送信する。
+~TLS~handshakeが完遂したとき、~clientは，最初の~HTTP要請を起動できる。
+すべての~HTTP~dataは，~TLS “応用~data” として送信されなければナラナイが、他の~~点では，~HTTP用の通常の接続の様に扱われる（`持続的な接続$として再利用される場合も含めて）。
+◎
+The HTTP client also acts as the TLS client. It initiates a connection to the server on the appropriate port and sends the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished, the client may then initiate the first HTTP request. All HTTP data MUST be sent as TLS "application data", but is otherwise treated like a normal connection for HTTP (including potential reuse as a persistent connection).
 </p>
 
 		</section>
 		<section id="tls.connection.closure">
-<h3 title="TLS Connection Closure">9.7. ~TLS接続の~closure</h3>
+<h3 title="TLS Connection Closure">9.8. ~TLS接続の~closure</h3>
 
 <p>
 ~TLSは、~secure接続の~closure用の便宜性を供する。
@@ -4826,7 +4857,7 @@ <h4 title="Multihomed Web Servers">C.1.1. ~multihomed~web~server</h4>
 </li>
 </ul>
 ◎
-The requirements that clients and servers support the Host header field (Section 6.6 of [Semantics]), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are among the most important changes defined by HTTP/1.1.
+The requirements that clients and servers support the Host header field (Section 6.5 of [Semantics]), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are among the most important changes defined by HTTP/1.1.
 </div>
 
 <p>

http-request-ja.html

@@ -1906,7 +1906,7 @@ <h4>8.3.8. `TRACE^m</h4>
 ~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 6.7.1) 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.
+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 6.6.1) 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.
 </p>
 
 <p>
@@ -2137,7 +2137,7 @@ <h3 title="Controls">9.1. 制御</h3>
 Field Name 	Ref.
 • Cache-Control 	Section 5.2 of [Caching]
 • Expect 	9.1.1
-• Host 	6.6
+• Host 	6.5
 • Max-Forwards 	9.1.2
 • Pragma 	Section 5.4 of [Caching]
 • TE 	5.6.5

http-response-ja.html

@@ -137,7 +137,7 @@
 
 4.2:~HTTPsem#protocol.version
 5.6:~HTTPsem#trailer.fields
-6.9:~HTTPsem#field.connection
+6.8:~HTTPsem#field.connection
 7.3.2:~HTTPsem#identifying.payload
 9.4:~HTTPrq#request.conneg
 9.5.1:~HTTPrq#challenge.and.response
@@ -676,7 +676,7 @@ <h4>10.2.2. `101^st</h4>
 ⇒
 その応答を終了させる`空~行l$の直後から切替わることになる，~protocol（たち）
 ◎
-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.8), 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.
+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), 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.
 </p>
 
 【！ `101^st0 は HTTP/2 では~supportされないので、この節の一部の記述は `Messaging$r の用語に基づいている。】
@@ -850,7 +850,7 @@ <h4>10.3.4. `203^st</h4>
 内容に対する，未来の`~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 6.7.2). 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).
+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 6.6.2). 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).
 </p>
 
 <p>
@@ -1379,9 +1379,9 @@ <h3 title="Redirection 3xx">10.4. `3xx^st</h3>
 </p>
 		<ul>
 			<li>
-接続に特有な~header（ `6.9$sec ）
+接続に特有な~header（ `6.8$sec ）
 ◎
-Connection-specific header fields (see Section 6.9),
+Connection-specific header fields (see Section 6.8),
 </li>
 			<li>
 ~clientの~proxy環境設定に特有な~header
@@ -2453,7 +2453,7 @@ <h4>10.5.21. `426^st</h4>
 要求される~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.8).
+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).
 </p>
 
 <div class="example">