Changeset 2334

Timestamp:

01/08/13 10:42:01 (9 years ago)

Author:

fielding@…

Message:

Many changes to properly target MUST requirements by role; addresses #484

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (32 diffs)
• p1-messaging.xml (modified) (32 diffs)
• p2-semantics.html (modified) (3 diffs)
• p2-semantics.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -1007 +1007 @@
          are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.
       </p>
-      <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
-         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
-         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's <a href="#header.connection" class="smpl">Connection</a> header field (see <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
+      <p id="rfc.section.2.6.p.7">New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely
+         ignored by recipients that do not recognize them. Header field extensibility is discussed in <a href="#field.extensibility" title="Field Extensibility">Section&nbsp;3.2.1</a>.
       </p>
       <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version
@@ -1080 +1079 @@
          identifier for a potential resource within that origin server's name space.
       </p>
-      <p id="rfc.section.2.7.1.p.4">If the host identifier is provided as an IP address, then the origin server is any listener on the indicated TCP port at that
+      <p id="rfc.section.2.7.1.p.4">A sender <em class="bcp14">MUST NOT</em> generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference <em class="bcp14">MUST</em> reject it as invalid.
+      </p>
+      <p id="rfc.section.2.7.1.p.5">If the host identifier is provided as an IP address, then the origin server is any listener on the indicated TCP port at that
          IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might use
-         a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved
-         port for WWW services).
-      </p>
-      <p id="rfc.section.2.7.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
+         a name resolution service, such as DNS, to find the address of a listener for that host. If the port subcomponent is empty
+         or not given, then TCP port 80 is assumed (the default reserved port for WWW services).
+      </p>
+      <p id="rfc.section.2.7.1.p.6">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
          The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening
          to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish
@@ -1091 +1092 @@
          authority to determine which names are valid and how they might be used.
       </p>
-      <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
+      <p id="rfc.section.2.7.1.p.7">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
          and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
       </p>
-      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
+      <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
          delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
          would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that
@@ -1100 +1101 @@
          — it is only the authoritative interface that is specific to TCP.
       </p>
-      <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
+      <p id="rfc.section.2.7.1.p.9">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
          configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
-         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST</em> exclude the userinfo subcomponent (and its "@" delimiter) when an "http" URI is transmitted within a message as a request
-         target or header field value. Recipients of an "http" URI reference <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake
+         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a
+         request target or header field value. Recipients of an "http" URI reference <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake
          of phishing attacks.
       </p>
@@ -1113 +1114 @@
       </p>
       <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
-         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured, end-to-end, through the use of strong encryption prior to sending the first HTTP request.
+         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the user agent <em class="bcp14">MUST</em> ensure that its connection to the origin server is secured through the use of strong encryption, end-to-end, prior to sending
+         the first HTTP request.
       </p>
       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
@@ -1206 +1208 @@
       </p>
       <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
-         it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
+         it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server ought to be prepared to receive URIs of unbounded length, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>, and <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target is longer than the server wishes to parse (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
@@ -1241 +1243 @@
       </p>
       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3>
-      <p id="rfc.section.3.2.1.p.1">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
-         new semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this
-         specification and in many other specifications outside the core standard. New header fields can be introduced without changing
-         the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
-      </p>
-      <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.
+      <p id="rfc.section.3.2.1.p.1">Header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new
+         semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification
+         and in many other specifications outside the core standard.
+      </p>
+      <p id="rfc.section.3.2.1.p.2">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
+         of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses.
+      </p>
+      <p id="rfc.section.3.2.1.p.3">A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. These requirements allow HTTP's functionality to be enhanced without requiring prior update
+         of deployed intermediaries.
+      </p>
+      <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
       </p>
       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.order" href="#field.order">Field Order</a></h3>
@@ -1256 +1263 @@
          field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
       </p>
-      <p id="rfc.section.3.2.2.p.3">Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing
-         the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by
-         a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation
-         of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
+      <p id="rfc.section.3.2.2.p.3">A recipient <em class="bcp14">MAY</em> combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics
+         of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order
+         in which header fields with the same field name are received is therefore significant to the interpretation of the combined
+         field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
       </p>
       <div class="note" id="rfc.section.3.2.2.p.4">
@@ -1319 +1326 @@
       </p>
       <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="field.limits" href="#field.limits">Field Limits</a></h3>
-      <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole.
-         Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field
+      <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole,
+         as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field
          semantics.
       </p>
-      <p id="rfc.section.3.2.5.p.2">A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process.
-      </p>
-      <p id="rfc.section.3.2.5.p.3">A client <em class="bcp14">MUST</em> be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such
-         that the dropped value(s) can be safely ignored without changing the response semantics.
+      <p id="rfc.section.3.2.5.p.2">A server ought to be prepared to receive request header fields of unbounded length and <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process.
+      </p>
+      <p id="rfc.section.3.2.5.p.3">A client ought to be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such
+         that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
       </p>
       <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;<a id="field.components" href="#field.components">Field value components</a></h3>
       <div id="rule.token.separators">
-         <p id="rfc.section.3.2.6.p.1">    Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters. These
-            special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
-         </p>
+         <p id="rfc.section.3.2.6.p.1">    Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters.</p>
       </div>
       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span>  <a href="#rule.token.separators" class="smpl">word</a>           = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
@@ -1400 +1405 @@
          applied for transport efficiency or security from those that are characteristics of the selected resource.
       </p>
-      <p id="rfc.section.3.3.1.p.4">All HTTP/1.1 recipients <em class="bcp14">MUST</em> implement the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. If chunked is applied
-         to a payload body, the sender <em class="bcp14">MUST NOT</em> apply chunked more than once (i.e., chunking an already chunked message is not allowed). If any transfer coding is applied
-         to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding is applied
-         to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection.
+      <p id="rfc.section.3.3.1.p.4">All HTTP/1.1 recipients <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer
+         coding other than chunked is applied to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than
+         chunked is applied to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection.
       </p>
       <div id="rfc.figure.u.27"></div>
@@ -1496 +1500 @@
          <li>
             <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message
-               framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
+               framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response.
             </p>
          </li>
@@ -1620 +1624 @@
       <p id="rfc.section.4.1.1.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that
          might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing
-         status. The trailer <em class="bcp14">MUST NOT</em> contain fields that need to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>.
+         status. A sender <em class="bcp14">MUST NOT</em> generate a trailer containing a field that needs to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>.
       </p>
       <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in
-         the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> send a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to
+         the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to
          prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed
          and the recipient wishes to confirm an integrity check on the fly.
       </p>
       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.75"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
-</pre><p id="rfc.section.4.1.1.p.4">If no <a href="#header.trailer" class="smpl">Trailer</a> header field is present, the sender of a chunked message body <em class="bcp14">SHOULD</em> send an empty trailer.
-      </p>
-      <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> send an empty trailer with the chunked transfer coding unless at least one of the following is true: 
+</pre><p id="rfc.section.4.1.1.p.4">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true: 
       </p>
       <ol>
@@ -1636 +1638 @@
          </li>
          <li>the trailer fields consist entirely of optional metadata and the recipient could use the message (in a manner acceptable to
-            the server where the field originated) without receiving that metadata. In other words, the server that generated the header
-            field is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.
+            the generating server) without receiving that metadata. In other words, the generating server is willing to accept the possibility
+            that the trailer fields might be silently discarded along the path to the client.
          </li>
       </ol>
-      <p id="rfc.section.4.1.1.p.6">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)
+      <p id="rfc.section.4.1.1.p.5">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)
          proxy and forwarded to an HTTP/1.0 recipient.
       </p>
@@ -1661 +1663 @@
   Remove "chunked" from Transfer-Encoding
   Remove Trailer from existing header fields
-</pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to receive and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
+</pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
       </p>
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
@@ -1711 +1713 @@
          no transfer coding is always acceptable.
       </p>
-      <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
+      <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
       </p>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
@@ -1766 +1768 @@
       <p id="rfc.section.5.3.p.4">The most common form of request-target is the <dfn>origin-form</dfn>. When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below),
          a client <em class="bcp14">MUST</em> 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, then the client <em class="bcp14">MUST</em> send "/" as the path within the origin-form of request-target. A <a href="#header.host" class="smpl">Host</a> header field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;5.4</a>, containing the target URI's authority component (excluding any userinfo).
+         is empty, then the client <em class="bcp14">MUST</em> send "/" as the path within the origin-form of request-target. A <a href="#header.host" class="smpl">Host</a> header field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;5.4</a>.
       </p>
       <p id="rfc.section.5.3.p.5">For example, a client wishing to retrieve a representation of the resource identified as</p>
@@ -1792 +1794 @@
          </p>
       </div>
-      <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
+      <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
       </p>
       <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
@@ -1815 +1817 @@
       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
       <p id="rfc.section.5.4.p.1">The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server
-         to distinguish among resources while servicing requests for multiple host names on a single IP address. Since the Host field-value
-         is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line.
+         to distinguish among resources while servicing requests for multiple host names on a single IP address.
       </p>
       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.86"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
-</pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then the Host
-         field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
-      </p>
-      <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
+</pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client <em class="bcp14">MUST</em> send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@"
+         delimiter (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target URI, then a client <em class="bcp14">MUST</em> send a Host header field with an empty field-value.
+      </p>
+      <p id="rfc.section.5.4.p.4">Since the Host field-value is critical information for handling a request, a user agent <em class="bcp14">SHOULD</em> generate Host as the first header field following the request-line.
+      </p>
+      <p id="rfc.section.5.4.p.5">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
       <div id="rfc.figure.u.46"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
 Host: www.example.org
-</pre><p id="rfc.section.5.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information
-         to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
-      </p>
-      <p id="rfc.section.5.4.p.7">When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. If
-         the proxy forwards the request, it <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value.
-      </p>
-      <p id="rfc.section.5.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
+</pre><p id="rfc.section.5.4.p.7">A client <em class="bcp14">MUST</em> send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the
+         Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
+      </p>
+      <p id="rfc.section.5.4.p.8">When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy
+         that forwards such a request <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value.
+      </p>
+      <p id="rfc.section.5.4.p.9">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
          poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
          relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache,
          without first verifying that the intercepted connection is targeting a valid IP address for that host.
       </p>
-      <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than
+      <p id="rfc.section.5.4.p.10">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than
          one Host header field or a Host header field with an invalid field-value.
       </p>
@@ -1891 +1894 @@
          enhance (or interfere) with either direction of the stream.
       </p>
-      <p id="rfc.section.5.7.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>, to exclude fields that are only intended for the incoming connection.
-      </p>
-      <p id="rfc.section.5.7.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
+      <p id="rfc.section.5.7.p.2">An intermediary not acting as a tunnel <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>, and exclude fields from being forwarded that are only intended for the incoming connection.
+      </p>
+      <p id="rfc.section.5.7.p.3">An intermediary <em class="bcp14">MUST NOT</em> forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize
+         its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.
       </p>
       <div id="rfc.iref.v.1"></div>
@@ -1920 +1924 @@
       </p>
       <p id="rfc.section.5.7.1.p.6">The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded
-         the message. However, if the real host is considered to be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
-      </p>
-      <p id="rfc.section.5.7.1.p.7">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
+         the message. However, if the real host is considered to be sensitive information, a sender <em class="bcp14">MAY</em> replace it with a pseudonym. If a port is not provided, a recipient <em class="bcp14">MAY</em> interpret that as meaning it was received on the default TCP port, if any, for the received-protocol.
+      </p>
+      <p id="rfc.section.5.7.1.p.7">A sender <em class="bcp14">MAY</em> generate comments in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and a recipient <em class="bcp14">MAY</em> remove them prior to forwarding the message.
       </p>
       <p id="rfc.section.5.7.1.p.8">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
@@ -1929 +1933 @@
       </p>
       <div id="rfc.figure.u.52"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net
-</pre><p id="rfc.section.5.7.1.p.10">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
-         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
-      </p>
-      <p id="rfc.section.5.7.1.p.11">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
+</pre><p id="rfc.section.5.7.1.p.10">An intermediary used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
+         such an intermediary <em class="bcp14">SHOULD</em> replace each received-by host of any host behind the firewall by an appropriate pseudonym for that host.
+      </p>
+      <p id="rfc.section.5.7.1.p.11">An intermediary <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
          values. For example,
       </p>
@@ -2014 +2018 @@
       </p>
       <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
-</pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">MUST</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section&nbsp;6.6</a>).
+</pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the sender is going to close the connection after the current
+         request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section&nbsp;6.6</a>).
       </p>
       <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every request message.
@@ -2043 +2048 @@
       <p id="rfc.section.6.3.p.4">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option.
       </p>
-      <p id="rfc.section.6.3.p.5">In order to remain persistent, all messages on a connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>. A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
+      <p id="rfc.section.6.3.p.5">In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined
+         by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>. A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
          on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request.
       </p>
@@ -2064 +2070 @@
          or fixing any changes that were partially applied, and then automatically retrying the requests that failed.
       </p>
-      <p id="rfc.section.6.3.1.p.4">An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if it fails.
+      <p id="rfc.section.6.3.1.p.4">A client <em class="bcp14">SHOULD NOT</em> automatically retry a failed automatic retry.
       </p>
       <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h3>
       <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
       </p>
-      <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">MUST</em> be prepared to retry those requests if the connection closes before it receives all of the corresponding responses. A client
-         that assumes a persistent connection and pipelines immediately after connection establishment <em class="bcp14">MUST NOT</em> pipeline on a retry connection until it knows the connection is persistent.
-      </p>
-      <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method until the final response status code for that method has been received, unless
+      <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined
+         requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client <em class="bcp14">MUST NOT</em> pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused
+         an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset
+         problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section&nbsp;6.6</a>).
+      </p>
+      <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
          the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
       </p>
@@ -2115 +2123 @@
       <div id="rfc.iref.c.14"></div>
       <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h2>
-      <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.
+      <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.
       </p>
       <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request.
@@ -2150 +2158 @@
   <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
 </pre><p id="rfc.section.6.7.p.3">A server that sends a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response <em class="bcp14">MUST</em> send an Upgrade header field to indicate the new protocol(s) to which the connection is being switched; if multiple protocol
-         layers are being switched, the new protocols <em class="bcp14">MUST</em> be listed in layer-ascending order. A server <em class="bcp14">MUST NOT</em> switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field. A server <em class="bcp14">MAY</em> choose to ignore the order of preference indicated by the client and select the new protocol(s) based on other factors, such
+         layers are being switched, the sender <em class="bcp14">MUST</em> list the protocols in layer-ascending order. A server <em class="bcp14">MUST NOT</em> switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field. A server <em class="bcp14">MAY</em> choose to ignore the order of preference indicated by the client and select the new protocol(s) based on other factors, such
          as the nature of the request or the current load on the server.
       </p>
@@ -2166 +2174 @@
 </pre><p id="rfc.section.6.7.p.7">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
          and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol(s)
-         chosen, although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field.
+         chosen. However, immediately after sending the 101 response, the server is expected to continue responding to the original
+         request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding request to
+         satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated).
       </p>
       <p id="rfc.section.6.7.p.8">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, it first
@@ -2181 +2191 @@
 [... data stream switches to HTTP/2.0 with an appropriate response
 (as defined by new protocol) to the "GET /hello.txt" request ...]
-</pre><p id="rfc.section.6.7.p.10">When Upgrade is sent, the sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
+</pre><p id="rfc.section.6.7.p.10">When Upgrade is sent, the sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
          that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request.
       </p>
@@ -2215 +2225 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a> 
+                  <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a> 
                   </td>
                </tr>
@@ -2271 +2281 @@
       </div>
       <p id="rfc.section.7.1.p.3">Furthermore, the header field-name "Close" shall be registered as "reserved", since using that name as an HTTP header field
-         might conflict with the "close" connection option of the "<a href="#header.connection" class="smpl">Connection</a>" header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>).
+         might conflict with the "close" connection option of the "<a href="#header.connection" class="smpl">Connection</a>" header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>).
       </p>
       <div id="rfc.table.u.1">
@@ -2981 +2991 @@
       <p id="rfc.section.A.2.p.26">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7.1</a>)
       </p>
-      <p id="rfc.section.A.2.p.27">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
+      <p id="rfc.section.A.2.p.27">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>)
       </p>
       <p id="rfc.section.A.2.p.28">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop
-         in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
+         in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
       </p>
       <p id="rfc.section.A.2.p.29">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
@@ -3279 +3289 @@
                   <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li>
                   <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
-                  <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.6</a>, <a href="#rfc.xref.header.connection.2">3.2.1</a>, <a href="#rfc.xref.header.connection.3">4.3</a>, <a href="#rfc.xref.header.connection.4">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.5">6.6</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">A.2</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
+                  <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">7.1</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a>, <a href="#rfc.xref.header.connection.9">A.2</a></li>
                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
                   <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
-                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.6</a>, <a href="#rfc.xref.header.connection.2">3.2.1</a>, <a href="#rfc.xref.header.connection.3">4.3</a>, <a href="#rfc.xref.header.connection.4">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.5">6.6</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">A.2</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
+                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">7.1</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a>, <a href="#rfc.xref.header.connection.9">A.2</a></li>
                   <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>
                </ul>

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -730 +730 @@
 </t>
 <t>
-   New header fields can be defined such that, when they are
-   understood by a recipient, they might override or enhance the
-   interpretation of previously defined header fields.  When an
-   implementation receives an unrecognized header field, the recipient
-   &MUST; ignore that header field for local processing regardless of
-   the message's HTTP version.  An unrecognized header field received
-   by a proxy &MUST; be forwarded downstream unless the header field's
-   field-name is listed in the message's <x:ref>Connection</x:ref> header field
-   (see <xref target="header.connection"/>).
-   These requirements allow HTTP's functionality to be enhanced without
-   requiring prior update of deployed intermediaries.
+   New header fields can be introduced without changing the protocol version
+   if their defined semantics allow them to be safely ignored by recipients
+   that do not recognize them. Header field extensibility is discussed in
+   <xref target="field.extensibility"/>.
 </t>
 <t>
@@ -889 +882 @@
 </t>
 <t>
+   A sender &MUST-NOT; generate an "http" URI with an empty host identifier.
+   A recipient that processes such a URI reference &MUST; reject it as invalid. 
+</t>
+<t>
    If the host identifier is provided as an IP address,
    then the origin server is any listener on the indicated TCP port at
@@ -895 +892 @@
    resolution service, such as DNS, to find the address of a listener
    for that host.
-   The host &MUST-NOT; be empty; if an "http" URI is received with an
-   empty host, then it &MUST; be rejected as invalid. 
    If the port subcomponent is empty or not given, then TCP port 80 is
    assumed (the default reserved port for WWW services).
@@ -940 +935 @@
    invocation options, configuration files, or bookmark lists, even
    though such usage might expose a user identifier or password.
-   Senders &MUST; exclude the userinfo subcomponent (and its "@"
-   delimiter) when an "http" URI is transmitted within a message as a
+   Senders &MUST-NOT; generate the userinfo subcomponent (and its "@"
+   delimiter) when an "http" URI reference is generated within a message as a
    request target or header field value.
    Recipients of an "http" URI reference &SHOULD; parse for userinfo and
@@ -964 +959 @@
    requirements for the "https" scheme, except that a default TCP port
    of 443 is assumed if the port subcomponent is empty or not given,
-   and the TCP connection &MUST; be secured, end-to-end, through the
-   use of strong encryption prior to sending the first HTTP request.
+   and the user agent &MUST; ensure that its connection to the origin
+   server is secured through the use of strong encryption, end-to-end,
+   prior to sending the first HTTP request.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"><!--terminal production--></iref>
@@ -1157 +1153 @@
    A server that receives a method longer than any that it implements
    &SHOULD; respond with a <x:ref>501 (Not Implemented)</x:ref> status code.
-   A server &MUST; be prepared to receive URIs of unbounded length and
-   respond with the <x:ref>414 (URI Too Long)</x:ref> status code if the received
-   request-target would be longer than the server wishes to handle
-   (see &status-414;).
+   A server ought to be prepared to receive URIs of unbounded length, as
+   described in <xref target="conformance"/>, and &MUST; respond with a
+   <x:ref>414 (URI Too Long)</x:ref> status code if the received
+   request-target is longer than the server wishes to parse (see &status-414;).
 </t>
 <t>
@@ -1238 +1234 @@
 <section title="Field Extensibility" anchor="field.extensibility">
 <t>
-   HTTP header fields are fully extensible: there is no limit on the
+   Header fields are fully extensible: there is no limit on the
    introduction of new field names, each presumably defining new semantics,
    nor on the number of header fields used in a given message.  Existing
    fields are defined in each part of this specification and in many other
    specifications outside the core standard.
-   New header fields can be introduced without changing the protocol version
-   if their defined semantics allow them to be safely ignored by recipients
-   that do not recognize them.
-</t>
-<t>
-   New HTTP header fields ought to be registered with IANA in the
-   Message Header Field Registry, as described in &iana-header-registry;.
+</t>
+<t>
+   New header fields can be defined such that, when they are understood by a
+   recipient, they might override or enhance the interpretation of previously
+   defined header fields, define preconditions on request evaluation, or
+   refine the meaning of responses.
+</t>
+<t>
    A proxy &MUST; forward unrecognized header fields unless the
    field-name is listed in the <x:ref>Connection</x:ref> header field
@@ -1255 +1252 @@
    configured to block, or otherwise transform, such fields.
    Other recipients &SHOULD; ignore unrecognized header fields.
+   These requirements allow HTTP's functionality to be enhanced without
+   requiring prior update of deployed intermediaries.
+</t>
+<t>
+   All defined header fields ought to be registered with IANA in the
+   Message Header Field Registry, as described in &iana-header-registry;.
 </t>
 </section>
@@ -1277 +1280 @@
 </t>
 <t>
-   Multiple header fields with the same field name can be combined into
-   one "field-name: field-value" pair, without changing the semantics of the
-   message, by appending each subsequent field value to the combined
+   A recipient &MAY; combine multiple header fields with the same field name
+   into one "field-name: field-value" pair, without changing the semantics of
+   the message, by appending each subsequent field value to the combined
    field value in order, separated by a comma. The order in which
    header fields with the same field name are received is therefore
@@ -1411 +1414 @@
 <t>
    HTTP does not place a pre-defined limit on the length of each header field
-   or on the length of the header block as a whole.  Various ad-hoc
-   limitations on individual header field length are found in practice,
-   often depending on the specific field semantics.
-</t>
-<t>
-   A server &MUST; be prepared to receive request header fields of unbounded
-   length and respond with an appropriate <x:ref>4xx (Client Error)</x:ref>
-   status code if the received header field(s) are larger than the server
-   wishes to process.
-</t>
-<t>
-   A client &MUST; be prepared to receive response header fields of unbounded
-   length. A client &MAY; discard or truncate received header fields that are
-   larger than the client wishes to process if the field semantics are such
-   that the dropped value(s) can be safely ignored without changing the
-   response semantics.
+   or on the length of the header block as a whole, as described in
+   <xref target="conformance"/>. Various ad-hoc limitations on individual
+   header field length are found in practice, often depending on the specific
+   field semantics.
+</t>
+<t>
+   A server ought to be prepared to receive request header fields of unbounded
+   length and &MUST; respond with an appropriate
+   <x:ref>4xx (Client Error)</x:ref> status code if the received header
+   field(s) are larger than the server wishes to process.
+</t>
+<t>
+   A client ought to be prepared to receive response header fields of
+   unbounded length.
+   A client &MAY; discard or truncate received header fields that are larger
+   than the client wishes to process if the field semantics are such that the
+   dropped value(s) can be safely ignored without changing the
+   message framing or response semantics.
 </t>
 </section>
@@ -1437 +1442 @@
   <x:anchor-alias value="word"/>
    Many HTTP header field values consist of words (token or quoted-string)
-   separated by whitespace or special characters. These special characters
-   &MUST; be in a quoted string to be used within a parameter value (as defined
-   in <xref target="transfer.codings"/>).
+   separated by whitespace or special characters.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="word"/><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><iref primary="true" item="Grammar" subitem="special"><!--unused production--></iref>
@@ -1574 +1577 @@
 </t>
 <t>
-   All HTTP/1.1 recipients &MUST; implement the chunked transfer coding
+   All HTTP/1.1 recipients &MUST; be able to parse the chunked transfer coding
    (<xref target="chunked.encoding"/>) because it plays a crucial role in
    framing messages when the payload body size is not known in advance.
-   If chunked is applied to a payload body, the sender &MUST-NOT; apply
-   chunked more than once (i.e., chunking an already chunked message is not
-   allowed).
-   If any transfer coding is applied to a request payload body, the
-   sender &MUST; apply chunked as the final transfer coding to ensure that
-   the message is properly framed.
-   If any transfer coding is applied to a response payload body, the
-   sender &MUST; either apply chunked as the final transfer coding or
-   terminate the message by closing the connection.
+   A sender &MUST-NOT; apply chunked more than once to a message body
+   (i.e., chunking an already chunked message is not allowed).
+   If any transfer coding other than chunked is applied to a request payload
+   body, the sender &MUST; apply chunked as the final transfer coding to
+   ensure that the message is properly framed.
+   If any transfer coding other than chunked is applied to a response payload
+   body, the sender &MUST; either apply chunked as the final transfer coding
+   or terminate the message by closing the connection.
 </t>
 <figure><preamble>
@@ -1777 +1779 @@
      either multiple <x:ref>Content-Length</x:ref> header fields having
      differing field-values or a single Content-Length header field having an
-     invalid value, then the message framing is invalid and &MUST; be treated
-     as an error to prevent request or response smuggling.
+     invalid value, then the message framing is invalid and
+     the recipient &MUST; treat it as an unrecoverable error to prevent
+     request or response smuggling.
      If this is a request message, the server &MUST; respond with
      a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
-     If this is a response message received by a proxy, the proxy
-     &MUST; close the connection to the server, discard the received response,
-     and send a <x:ref>502 (Bad Gateway)</x:ref> response to the client.
-     If this is a response message received by a user agent, it &MUST; be
-     treated as an error by discarding the message and closing the connection.
+     If this is a response message received by a proxy,
+     the proxy &MUST; close the connection to the server, discard the received
+     response, and send a <x:ref>502 (Bad Gateway)</x:ref> response to the
+     client.
+     If this is a response message received by a user agent,
+     the user agent &MUST; close the connection to the server and discard the
+     received response.
     </t></x:lt>
     <x:lt><t>
@@ -2023 +2028 @@
    generated while the message body is sent, such as a message integrity
    check, digital signature, or post-processing status.
-   The trailer &MUST-NOT; contain fields that need to be known before a
-   recipient processes the body, such as <x:ref>Transfer-Encoding</x:ref>,
-   <x:ref>Content-Length</x:ref>, and <x:ref>Trailer</x:ref>.
+   A sender &MUST-NOT; generate a trailer containing a field that needs to be
+   known before a recipient processes the body, such as
+   <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, and
+   <x:ref>Trailer</x:ref>.
 </t>
 <t>
    When a message includes a message body encoded with the chunked
    transfer coding and the sender desires to send metadata in the form of
-   trailer fields at the end of the message, the sender &SHOULD; send a
+   trailer fields at the end of the message, the sender &SHOULD; generate a
    <x:ref>Trailer</x:ref> header field before the message body to indicate
    which fields will be present in the trailers. This allows the recipient
@@ -2041 +2047 @@
 </artwork></figure>
 <t>
-   If no <x:ref>Trailer</x:ref> header field is present, the sender of a
-   chunked message body &SHOULD; send an empty trailer.
-</t>
-<t>
-   A server &MUST; send an empty trailer with the chunked transfer coding
+   A server &MUST; generate an empty trailer with the chunked transfer coding
    unless at least one of the following is true:
   <list style="numbers">
@@ -2053 +2055 @@
      
     <t>the trailer fields consist entirely of optional metadata and the
-    recipient could use the message (in a manner acceptable to the server where
-    the field originated) without receiving that metadata. In other words,
-    the server that generated the header field is willing to accept the
-    possibility that the trailer fields might be silently discarded along
-    the path to the client.</t>
+    recipient could use the message (in a manner acceptable to the generating
+    server) without receiving that metadata. In other words, the generating
+    server is willing to accept the possibility that the trailer fields might
+    be silently discarded along the path to the client.</t>
   </list>
 </t>
@@ -2091 +2092 @@
 </artwork></figure>
 <t>
-   All recipients &MUST; be able to receive and decode the
+   All recipients &MUST; be able to parse and decode the
    chunked transfer coding and &MUST; ignore chunk-ext extensions
    they do not understand.
@@ -2310 +2311 @@
    "/" as the path within the origin-form of request-target.
    A <x:ref>Host</x:ref> header field is also sent, as defined in
-   <xref target="header.host"/>, containing the target URI's
-   authority component (excluding any userinfo).
+   <xref target="header.host"/>.
 </t>
 <t>
@@ -2360 +2360 @@
 </t>
 <t>
-   The <x:dfn>authority-form</x:dfn> of request-target is only used for CONNECT requests
-   (&CONNECT;).  When making a CONNECT request to establish a tunnel through
-   one or more proxies, a client &MUST; send only the target URI's
-   authority component (excluding any userinfo) as the request-target.
-   For example,
+   The <x:dfn>authority-form</x:dfn> of request-target is only used for
+   CONNECT requests (&CONNECT;). When making a CONNECT request to establish a
+   tunnel through one or more proxies, a client &MUST; send only the target
+   URI's authority component (excluding any userinfo and its "@" delimiter) as
+   the request-target. For example,
 </t>
 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
@@ -2412 +2412 @@
    information from the target URI, enabling the origin
    server to distinguish among resources while servicing requests
-   for multiple host names on a single IP address.  Since the Host
-   field-value is critical information for handling a request, it
-   &SHOULD; be sent as the first header field following the request-line.
+   for multiple host names on a single IP address.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>
@@ -2420 +2418 @@
 </artwork></figure>
 <t>
-   A client &MUST; send a Host header field in all HTTP/1.1 request
-   messages.  If the target URI includes an authority component, then
-   the Host field-value &MUST; be identical to that authority component
-   after excluding any userinfo (<xref target="http.uri"/>).
+   A client &MUST; send a Host header field in all HTTP/1.1 request messages.
+   If the target URI includes an authority component, then a client &MUST;
+   send a field-value for Host that is identical to that authority
+   component, excluding any userinfo subcomponent and its "@" delimiter
+   (<xref target="http.uri"/>).
    If the authority component is missing or undefined for the target URI,
-   then the Host header field &MUST; be sent with an empty field-value.
+   then a client &MUST; send a Host header field with an empty field-value.
+</t>
+<t>
+   Since the Host field-value is critical information for handling a request,
+   a user agent &SHOULD; generate Host as the first header field following the
+   request-line. 
 </t>
 <t>
@@ -2436 +2440 @@
 </artwork></figure>
 <t>
-   The Host header field &MUST; be sent in an HTTP/1.1 request even
+   A client &MUST; send a Host header field in an HTTP/1.1 request even
    if the request-target is in the absolute-form, since this
    allows the Host information to be forwarded through ancient HTTP/1.0
@@ -2445 +2449 @@
    request-target, the proxy &MUST; ignore the received
    Host header field (if any) and instead replace it with the host
-   information of the request-target.  If the proxy forwards the request,
-   it &MUST; generate a new Host field-value based on the received
+   information of the request-target.  A proxy that forwards such a request
+   &MUST; generate a new Host field-value based on the received
    request-target rather than forward the received Host field-value.
 </t>
@@ -2588 +2592 @@
 </t>
 <t>
-   Intermediaries that forward a message &MUST; implement the
+   An intermediary not acting as a tunnel &MUST; implement the
    <x:ref>Connection</x:ref> header field, as specified in
-   <xref target="header.connection"/>, to exclude fields that are only
-   intended for the incoming connection.
-</t>
-<t>
-   In order to avoid request loops, a proxy that forwards requests to other
-   proxies &MUST; be able to recognize and exclude all of its own server
-   names, including any aliases, local variations, or literal IP addresses.
+   <xref target="header.connection"/>, and exclude fields from being forwarded
+   that are only intended for the incoming connection.
+</t>
+<t>
+   An intermediary &MUST-NOT; forward a message to itself unless it is
+   protected from an infinite request loop. In general, an intermediary ought
+   to recognize its own server names, including any aliases, local variations,
+   or literal IP addresses, and respond to such requests directly.
 </t>
 
@@ -2649 +2654 @@
    The received-by field is normally the host and optional port number of a
    recipient server or client that subsequently forwarded the message.
-   However, if the real host is considered to be sensitive information, it
-   &MAY; be replaced by a pseudonym. If the port is not given, it &MAY; be
-   assumed to be the default port of the received-protocol.
-</t>
-<t>
-   Comments &MAY; be used in the Via header field to identify the software
-   of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
+   However, if the real host is considered to be sensitive information, a
+   sender &MAY; replace it with a pseudonym. If a port is not provided,
+   a recipient &MAY; interpret that as meaning it was received on the default
+   TCP port, if any, for the received-protocol.
+</t>
+<t>
+   A sender &MAY; generate comments in the Via header field to identify the
+   software of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
    <x:ref>Server</x:ref> header fields. However, all comments in the Via field
-   are optional and &MAY; be removed by any recipient prior to forwarding the
+   are optional and a recipient &MAY; remove them prior to forwarding the
    message.
 </t>
@@ -2672 +2678 @@
 </artwork></figure>
 <t>
-   A proxy or gateway used as a portal through a network firewall
+   An intermediary used as a portal through a network firewall
    &SHOULD-NOT; forward the names and ports of hosts within the firewall
-   region unless it is explicitly enabled to do so. If not enabled, the
-   received-by host of any host behind the firewall &SHOULD; be replaced
-   by an appropriate pseudonym for that host.
-</t>
-<t>
-   A proxy or gateway &MAY; combine an ordered subsequence of Via header
+   region unless it is explicitly enabled to do so. If not enabled, such an
+   intermediary &SHOULD; replace each received-by host of any host behind the
+   firewall by an appropriate pseudonym for that host.
+</t>
+<t>
+   An intermediary &MAY; combine an ordered subsequence of Via header
    field entries into a single such entry if the entries have identical
    received-protocol values. For example,
@@ -2859 +2865 @@
 </artwork></figure>
 <t>
-   in either the request or the response header fields indicates that
-   the connection &MUST; be closed after the current request/response
+   in either the request or the response header fields indicates that the
+   sender is going to close the connection after the current request/response
    is complete (<xref target="persistent.tear-down"/>).
 </t>
@@ -2918 +2924 @@
 </t>
 <t>
-   In order to remain persistent, all messages on a connection &MUST;
+   In order to remain persistent, all messages on a connection need to
    have a self-defined message length (i.e., one not defined by closure
    of the connection), as described in <xref target="message.body"/>.
@@ -2968 +2974 @@
 </t>
 <t>
-   An automatic retry &SHOULD-NOT; be repeated if it fails.
+   A client &SHOULD-NOT; automatically retry a failed automatic retry.
 </t>
 </section>
@@ -2983 +2989 @@
 </t>
 <t>
-   A client that pipelines requests &MUST; be prepared to retry those
-   requests if the connection closes before it receives all of the
-   corresponding responses. A client that assumes a persistent connection and
-   pipelines immediately after connection establishment &MUST-NOT; pipeline
-   on a retry connection until it knows the connection is persistent.
+   A client that pipelines requests &SHOULD; retry unanswered requests if the
+   connection closes before it receives all of the corresponding responses.
+   When retrying pipelined requests after a failed connection (a connection
+   not explicitly closed by the server in its last complete response), a
+   client &MUST-NOT; pipeline immediately after connection establishment,
+   since the first remaining request in the prior pipeline might have caused
+   an error response that can be lost again if multiple requests are sent on a
+   prematurely closed connection (see the TCP reset problem described in
+   <xref target="persistent.tear-down"/>).
 </t>
 <t>
    Idempotent methods (&idempotent-methods;) are significant to pipelining
    because they can be automatically retried after a connection failure.
-   A user agent &SHOULD-NOT; pipeline requests after a non-idempotent method
+   A user agent &SHOULD-NOT; pipeline requests after a non-idempotent method,
    until the final response status code for that method has been received,
    unless the user agent has a means to detect and recover from partial
@@ -3163 +3173 @@
    &MUST; send an Upgrade header field to indicate the new protocol(s) to
    which the connection is being switched; if multiple protocol layers are
-   being switched, the new protocols &MUST; be listed in layer-ascending
+   being switched, the sender &MUST; list the protocols in layer-ascending
    order. A server &MUST-NOT; switch to a protocol that was not indicated by
    the client in the corresponding request's Upgrade header field.
@@ -3193 +3203 @@
    use by the server is optional. The capabilities and nature of the
    application-level communication after the protocol change is entirely
-   dependent upon the new protocol(s) chosen, although the first action
-   after changing the protocol &MUST; be a response to the initial HTTP
-   request that contained the Upgrade header field.
+   dependent upon the new protocol(s) chosen. However, immediately after
+   sending the 101 response, the server is expected to continue responding to
+   the original request as if it had received its equivalent within the new
+   protocol (i.e., the server still has an outstanding request to satisfy
+   after the protocol has been changed, and is expected to do so without
+   requiring the request to be repeated).
 </t>
 <t>

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1611 +1611 @@
       </p>
       <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> send 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 <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient <em class="bcp14">SHOULD</em> exclude any request header fields from the response body that are likely to contain sensitive data.
+         be foolish for a user agent to send stored user credentials <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient of the request <em class="bcp14">SHOULD</em> exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
       </p>
       <p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
@@ -2115 +2115 @@
       <div id="rfc.iref.r.2"></div>
       <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h3>
-      <p id="rfc.section.5.5.2.p.1">The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the <a href="p1-messaging.html#target-resource" class="smpl">target URI</a> was obtained (i.e., the "referrer", though the field name is misspelled). A user agent <em class="bcp14">MUST</em> exclude any fragment or userinfo components <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> when generating the Referer field value.
+      <p id="rfc.section.5.5.2.p.1">The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the <a href="p1-messaging.html#target-resource" class="smpl">target URI</a> was obtained (i.e., the "referrer", though the field name is misspelled). A user agent <em class="bcp14">MUST NOT</em> include the fragment and userinfo components of the URI reference <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, if any, when generating the Referer field value.
       </p>
       <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
@@ -2426 +2426 @@
          servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
       </p>
-      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect one.
+      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx status responses received prior to a final response, even if the client does not expect one.
          A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
       </p>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -1747 +1747 @@
    would be foolish for a user agent to send stored user credentials
    <xref target="Part7"/> or cookies <xref target="RFC6265"/> in a TRACE
-   request. The final recipient &SHOULD; exclude any request header fields
-   from the response body that are likely to contain sensitive data.
+   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.
 </t>
 <t>
@@ -2481 +2482 @@
    reference for the resource from which the <x:ref>target URI</x:ref> was
    obtained (i.e., the "referrer", though the field name is misspelled).
-   A user agent &MUST; exclude any fragment or userinfo components
-   <xref target="RFC3986"/> when generating the Referer field value.
+   A user agent &MUST-NOT; include the fragment and userinfo components
+   of the URI reference <xref target="RFC3986"/>, if any, when generating the
+   Referer field value.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/>
@@ -2733 +2735 @@
 </t>
 <t>
-   A client &MUST; be prepared to accept one or more 1xx status responses
+   A client &MUST; be able to parse one or more 1xx status responses received
    prior to a final response, even if the client does not expect one.
    A user agent &MAY; ignore unexpected 1xx status responses.