Interpunction (#987)

* interpunction (#987) * interpunction (#987) * interpunction (#987) * interpunction (#987) * interpunction (#987)
httpwg · Jan 3, 2022 · 5bc7e66 · 5bc7e66
1 parent 8754c8c
commit 5bc7e66
Show file tree

Hide file tree

Showing 12 changed files with 377 additions and 1,307 deletions.
diff --git a/auth48/rfc9110-to-be.diff b/auth48/rfc9110-to-be.diff
diff --git a/auth48/rfc9110-to-be.txt.diff b/auth48/rfc9110-to-be.txt.diff
diff --git a/auth48/rfc9111-to-be.diff b/auth48/rfc9111-to-be.diff
diff --git a/auth48/rfc9111-to-be.txt.diff b/auth48/rfc9111-to-be.txt.diff
diff --git a/auth48/rfc9112-to-be.diff b/auth48/rfc9112-to-be.diff
@@ -1,4 +1,4 @@
---- ../build/draft-ietf-httpbis-messaging-latest.redxml	2022-01-03 12:09:37.764713100 +0100
+--- ../build/draft-ietf-httpbis-messaging-latest.redxml	2022-01-03 14:44:56.708857800 +0100
 +++ rfc9112-to-be.xml	2022-01-03 11:55:48.985886200 +0100
 @@ -1,35 +1,39 @@
  <?xml version="1.0" encoding="UTF-8"?>
@@ -132,7 +132,7 @@
     </front>
     <middle>
        <section anchor="introduction" title="Introduction">
-@@ -118,15 +108,15 @@
+@@ -118,10 +108,10 @@
     hypertext information systems. HTTP/1.1 is defined by:
  </t>
           <ul>
@@ -146,12 +146,6 @@
              </li>
           </ul>
           <t>
-    This document specifies how HTTP semantics are conveyed using the
--   HTTP/1.1 message syntax, framing and connection management mechanisms.
-+   HTTP/1.1 message syntax, framing, and connection management mechanisms.
-    Its goal is to define the complete set of requirements for HTTP/1.1
-    message parsers and message-forwarding intermediaries.
- </t>
 @@ -136,20 +126,19 @@
     messaging and connection management, with the changes being summarized in
     <xref target="changes.from.rfc.7230"/>. The other parts of
@@ -262,12 +256,7 @@
     differ only in the start-line, which is either a request-line (for requests)
     or a status-line (for responses), and in the algorithm for determining
     the length of the message body (<xref target="message.body"/>).
-@@ -275,13 +243,13 @@
-    In theory, a client could receive requests and a server could receive
-    responses, distinguishing them by their different start-line formats.
-    In practice, servers are implemented to only expect a request
--   (a response is interpreted as an unknown or invalid request method)
-+   (a response is interpreted as an unknown or invalid request method),
+@@ -279,9 +247,9 @@
     and clients are implemented to only expect a response.
  </t>
              <t>
@@ -719,8 +708,8 @@
     an invalid <xref target="body.content-length" format="none">Content-Length</xref> header field, then the message
     framing is invalid and the recipient <bcp14>MUST</bcp14> treat it as an unrecoverable
     error, unless the field value can be successfully parsed as a
--   comma-separated list (<xref target="HTTP" section="5.6.1"/>), all values in the
--   list are valid, and all values in the list are the same (in which case the
+-   comma-separated list (<xref target="HTTP" section="5.6.1"/>); all values in the
+-   list are valid; and all values in the list are the same (in which case the
 +   comma-separated list (<xref target="RFC9110" section="5.6.1"/>); all values in the
 +   list are valid; and all values in the list are the same (in which case, the
     message is processed with that single value used as the Content-Length field
@@ -775,7 +764,7 @@
              <t>
     A server <bcp14>MAY</bcp14> reject a request that contains a message body but
     not a <xref target="body.content-length" format="none">Content-Length</xref> by responding with
-@@ -1199,9 +1220,23 @@
+@@ -1199,7 +1220,21 @@
     use a valid <xref target="body.content-length" format="none">Content-Length</xref> header field if the message body
     length is known in advance, rather than the chunked transfer coding, since some
     existing services respond to chunked with a 411 (Length Required)
@@ -796,11 +785,8 @@
 +
 +   This
     is typically because such services are implemented via a gateway that
--   requires a content-length in advance of being called and the server
-+   requires a content-length in advance of being called, and the server
+    requires a content-length in advance of being called, and the server
     is unable or unwilling to buffer the entire request before processing.
- </t>
-             <t>
 @@ -1234,11 +1269,11 @@
  </t>
           <t>
@@ -883,18 +869,15 @@
     conform to the purpose of transfer coding defined in this specification.
  </t>
              <t>
-@@ -1446,9 +1481,9 @@
+@@ -1446,7 +1481,7 @@
           <section anchor="transfer.coding.negotiation"
                    title="Negotiating Transfer Codings">
              <t>
 -  The TE field (<xref target="HTTP" section="10.1.4"/>) is used in HTTP/1.1 to indicate
 +  The TE field (<xref target="RFC9110" section="10.1.4"/>) is used in HTTP/1.1 to indicate
    what transfer-codings, besides chunked, the client is willing to accept
--  in the response, and whether the client is willing to preserve
-+  in the response and whether the client is willing to preserve
+   in the response and whether the client is willing to preserve
    trailer fields in a chunked transfer coding.
- </t>
-             <t>
 @@ -1465,7 +1500,7 @@
              <t>
     When multiple transfer codings are acceptable, the client <bcp14>MAY</bcp14> rank the
@@ -943,7 +926,7 @@
  </t>
           <t>
     If a response terminates in the middle of the header section (before the
-@@ -1530,20 +1574,20 @@
+@@ -1530,11 +1574,11 @@
     protocol is outside the scope of this specification.
  </t>
           <t>
@@ -957,24 +940,11 @@
     over IP, with a default TCP port of 80, but the client might be
     configured to use a proxy via some other connection, port, or protocol.
  </t>
-          <t>
-    HTTP implementations are expected to engage in connection management,
--   which includes maintaining the state of current connections,
--   establishing a new connection or reusing an existing connection,
--   processing messages received on a connection, detecting connection
--   failures, and closing each connection.
-+   which includes maintaining the state of current connections;
-+   establishing a new connection or reusing an existing connection;
-+   processing messages received on a connection; detecting connection
-+   failures; and closing each connection.
-    Most clients maintain multiple connections in parallel, including
-    more than one connection per server endpoint.
-    Most servers are designed to maintain thousands of concurrent connections,
 @@ -1565,7 +1609,7 @@
     Hence, it relies on the order of response arrival to correspond exactly
     to the order in which requests are made on the same connection.
     More than one response message per request only occurs when one or more
--   informational responses (1xx, see <xref target="HTTP" section="15.2"/>) precede a
+-   informational responses (1xx; see <xref target="HTTP" section="15.2"/>) precede a
 +   informational responses (1xx; see <xref target="RFC9110" section="15.2"/>) precede a
     final response to the same request.
  </t>
@@ -1046,16 +1016,7 @@
     because they can be automatically retried after a connection failure.
     A user agent <bcp14>SHOULD NOT</bcp14> pipeline requests after a non-idempotent method,
     until the final response status code for that method has been received,
-@@ -1757,7 +1809,7 @@
- </t>
-             <t>
-    A server <bcp14>SHOULD</bcp14> sustain persistent connections, when possible, and allow
--   the underlying transport's flow-control mechanisms to resolve temporary overloads, rather
-+   the underlying transport's flow-control mechanisms to resolve temporary overloads rather
-    than terminate connections with the expectation that clients will retry.
-    The latter technique can exacerbate network congestion or server load.
- </t>
-@@ -1777,14 +1829,14 @@
+@@ -1777,7 +1829,7 @@
     The "close" connection option is defined as a signal that the sender
     will close this connection after completion of the response.
     A sender <bcp14>SHOULD</bcp14> send a Connection header field
@@ -1064,15 +1025,7 @@
     when it intends to close a connection. For example,
  </t>
              <sourcecode type="http-message"><![CDATA[Connection: close
- ]]></sourcecode>
-             <t>
-    as a request header field indicates that this is the last request that
--   the client will send on this connection, while in a response the same
-+   the client will send on this connection, while in a response, the same
-    field indicates that the server is going to close this connection after
-    the response message is complete.
- </t>
-@@ -1854,21 +1906,21 @@
+@@ -1854,7 +1906,7 @@
           <section anchor="tls.connection.initiation" title="TLS Connection Initiation">
              <t>
     Conceptually, HTTP/TLS is simply sending HTTP messages over a connection
@@ -1081,14 +1034,7 @@
  </t>
              <t>
     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 <bcp14>MUST</bcp14> be sent as TLS
--   "application data", but is otherwise treated like a normal connection for
-+   "application data" but is otherwise treated like a normal connection for
-    HTTP (including potential reuse as a persistent connection).
- </t>
-          </section>
+@@ -1868,7 +1920,7 @@
           <section anchor="tls.connection.closure" title="TLS Connection Closure">
              <t>
     TLS uses an exchange of closure alerts prior to (non-error) connection
@@ -1218,29 +1164,11 @@
  </t>
           <section anchor="response.splitting" title="Response Splitting">
              <t>
--   Response splitting (a.k.a., CRLF injection) is a common technique, used in
+-   Response splitting (a.k.a. CRLF injection) is a common technique, used in
 +   Response splitting (a.k.a.&nbsp;CRLF injection) is a common technique, used in
     various attacks on Web usage, that exploits the line-based nature of HTTP
     message framing and the ordered association of requests to responses on
     persistent connections <xref target="Klein"/>. This technique can be
-@@ -2098,7 +2178,7 @@
-    parameter of the request that is later decoded and echoed within any of the
-    response header fields of the response. If the decoded data is crafted to
-    look like the response has ended and a subsequent response has begun, the
--   response has been split and the content within the apparent second response
-+   response has been split, and the content within the apparent second response
-    is controlled by the attacker. The attacker can then make any other request
-    on the same persistent connection and trick the recipients (including
-    intermediaries) into believing that the second half of the split is an
-@@ -2116,7 +2196,7 @@
-             <t>
-    A common defense against response splitting is to filter requests for data
-    that looks like encoded CR and LF (e.g., "%0D" and "%0A"). However, that
--   assumes the application server is only performing URI decoding, rather
-+   assumes the application server is only performing URI decoding rather
-    than more obscure data transformations like charset transcoding, XML entity
-    translation, base64 decoding, sprintf reformatting, etc.  A more effective
-    mitigation is to prevent anything other than the server's core protocol
 @@ -2128,7 +2208,7 @@
           </section>
           <section anchor="request.smuggling" title="Request Smuggling">
@@ -1250,15 +1178,6 @@
     differences in protocol parsing among various recipients to hide additional
     requests (which might otherwise be blocked or disabled by policy) within an
     apparently harmless request.  Like response splitting, request smuggling
-@@ -2155,7 +2235,7 @@
-             <t>
-    The mechanisms provided with the "https" scheme, such as authenticated
-    encryption, provide protection against modification of messages. Care
--   is needed however to ensure that connection closure cannot be used to
-+   is needed, however, to ensure that connection closure cannot be used to
-    truncate messages (see <xref target="tls.connection.closure"/>). User agents
-    might refuse to accept incomplete messages or treat them specially. For
-    example, a browser being used to view medical history or drug interaction
 @@ -2185,29 +2265,33 @@
     over many forms of encrypted connection, with the selection of
     such transports being identified by the choice of URI scheme or within
@@ -1918,7 +1837,7 @@
     this might be complicated by the presence of a Content-Encoding
     and by the fact that HTTP allows the use of some charsets
     that do not use octets 13 and 10 to represent CR and LF, respectively.
-@@ -2860,25 +2718,25 @@
+@@ -2860,18 +2718,18 @@
           </section>
           <section anchor="conversion.of.date.formats" title="Conversion of Date Formats">
              <t>
@@ -1941,14 +1860,6 @@
     on the media type, proxies and gateways from HTTP to MIME-compliant
     protocols ought to either change the value of the Content-Type
     header field or decode the representation before forwarding the message.
-    (Some experimental applications of Content-Type for Internet mail have used
-    a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
-    a function equivalent to Content-Encoding. However, this parameter is
--   not part of the MIME standards).
-+   not part of the MIME standards.)
- </t>
-          </section>
-          <section anchor="conversion.of.content-transfer-encoding"
 @@ -2900,15 +2758,15 @@
     likelihood of safe transport over the destination protocol.
  </t>
@@ -1991,15 +1902,6 @@
     to which that request was directed. The Host header field was
     introduced during the development of HTTP/1.1 and, though it was
     quickly implemented by most HTTP/1.0 browsers, additional requirements
-@@ -2976,7 +2834,7 @@
-    field in any requests.
- </t>
-                <t>
--   Clients are also encouraged to consider the use of Connection: keep-alive
-+   Clients are also encouraged to consider the use of "Connection: keep-alive"
-    in requests carefully; while they can enable persistent connections with
-    HTTP/1.0 servers, clients using them will need to monitor the
-    connection for "hung" requests (which indicate that the client ought to stop
 @@ -2998,31 +2856,31 @@
              <t>
     Most of the sections introducing HTTP's design goals, history, architecture,