Changeset 1741

Timestamp:

08/07/12 19:13:21 (10 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink header field definitions (P1)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (33 diffs)
• p1-messaging.xml (modified) (42 diffs)
• p2-semantics.html (modified) (12 diffs)
• p2-semantics.xml (modified) (13 diffs)
• p5-range.html (modified) (2 diffs)
• p5-range.xml (modified) (2 diffs)
• p6-cache.html (modified) (2 diffs)
• p6-cache.xml (modified) (3 diffs)

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

@@ -907 +907 @@
          applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
          servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
-         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;6.2</a>) header fields for both connections.
+         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;6.2</a>) header fields for both connections.
       </p>
       <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
@@ -985 +985 @@
       <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default
          behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
-         are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by
-         all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.
+         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 Connection header field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
+         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.2" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
       </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
@@ -1215 +1214 @@
          them.
       </p>
-      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
+      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy 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.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
       </p>
       <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
@@ -1368 +1367 @@
       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
 </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p>
-      <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a Content-Length or Transfer-Encoding header field. Request message
-         framing is independent of method semantics, even if the method does not define any use for a message body.
+      <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if the method does not define any use for a
+         message body.
       </p>
       <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
-         status code (<a href="#status-code">Paragraph&nbsp;3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,
-         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
+         status code (<a href="#status-code">Paragraph&nbsp;3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
       </p>
       <div id="rfc.iref.t.4"></div>
@@ -1414 +1412 @@
       <div id="rfc.iref.h.7"></div>
       <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h3>
-      <p id="rfc.section.3.3.2.p.1">When a message does not have a Transfer-Encoding header field and the payload body length can be determined prior to being
-         transferred, a Content-Length header field <em class="bcp14">SHOULD</em> be sent to indicate the length of the payload body that is either present as the message body, for requests and non-HEAD responses
+      <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field and the payload body length can be determined prior to being transferred, a Content-Length header field <em class="bcp14">SHOULD</em> be sent to indicate the length of the payload body that is either present as the message body, for requests and non-HEAD responses
          other than <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, or would have been present had the request been an unconditional GET. The length is expressed as a decimal number of octets.
       </p>
@@ -1447 +1444 @@
          <li>
             <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes
-               the header fields. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in such a message.
+               the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message.
             </p>
          </li>
          <li>
-            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding
+            <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding
                indicates the data is complete.
             </p>
-            <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding,
-               the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header
-               field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot
-               be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
+            <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the "chunked" transfer-coding is not the final encoding, the message body length
+               is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in
+               a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot be determined reliably;
+               the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
             </p>
-            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
-               overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of
-               security-related checks on message routing or content) and thus ought to be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message body length after the transfer-coding
+            <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request
+               or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an
+               error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message body length after the transfer-coding
                is decoded.
             </p>
          </li>
          <li>
-            <p>If a message is received without Transfer-Encoding and with either multiple Content-Length 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> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent,
+            <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> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. 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.
             </p>
          </li>
          <li>
-            <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message body length
-               in octets. If the actual number of octets sent in the message is less than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in
+            <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the message body length in octets. If the actual number of octets sent in the message is less
+               than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in
                the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection
                and the connection has been closed by the server.
@@ -1491 +1488 @@
          with HTTP/1.0.
       </p>
-      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
-      </p>
-      <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message body length is known in advance, rather than the "chunked" encoding,
-         since some existing services respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via
+      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
+      </p>
+      <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the "chunked" encoding, since some existing services
+         respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via
          a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire
          request before processing.
       </p>
-      <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
-         knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.
+      <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of
+         specific user configuration or by remembering the version of a prior received response.
       </p>
       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2>
@@ -1509 +1506 @@
       </p>
       <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding
-         has not been received. A message that uses a valid Content-Length is incomplete if the size of the message body received (in
-         octets) is less than the value given by Content-Length. A response that has neither chunked transfer encoding nor Content-Length
-         is terminated by closure of the connection, and thus is considered complete regardless of the number of message body octets
-         received, provided that the header block was received intact.
+         has not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response
+         that has neither chunked transfer encoding nor Content-Length is terminated by closure of the connection, and thus is considered
+         complete regardless of the number of message body octets received, provided that the header block was received intact.
       </p>
       <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that
@@ -1551 +1547 @@
   <a href="#rule.parameter" class="smpl">attribute</a>          = <a href="#rule.token.separators" class="smpl">token</a>
   <a href="#rule.parameter" class="smpl">value</a>              = <a href="#rule.token.separators" class="smpl">word</a>
-</pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. The HTTP Transfer Coding registry is defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
+</pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. The HTTP Transfer Coding registry is defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>. HTTP/1.1 uses transfer-coding values in the <a href="#header.te" class="smpl">TE</a> header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and in the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
       </p>
       <div id="rfc.iref.c.7"></div>
@@ -1582 +1578 @@
          by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
       </p>
-      <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
-         can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;4.4</a>).
+      <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The <a href="#header.trailer" class="smpl">Trailer</a> header field can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;4.4</a>).
       </p>
       <p id="rfc.section.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: 
       </p>
       <ol>
-         <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as
-            described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.3</a>; or,
+         <li>the request included a <a href="#header.te" class="smpl">TE</a> header field that indicates "trailers" is acceptable in the transfer-coding of the response, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.3</a>; or,
          </li>
          <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
@@ -1672 +1666 @@
   TE:
   TE: trailers, deflate;q=0.5
-</pre><p id="rfc.section.4.3.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>) whenever TE is present in an HTTP/1.1 message.
+</pre><p id="rfc.section.4.3.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a <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>) whenever TE is present in an HTTP/1.1 message.
       </p>
       <p id="rfc.section.4.3.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
@@ -1701 +1695 @@
       </p>
       <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
-      <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
+      <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
          is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
          a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
@@ -1726 +1720 @@
       </p>
       <ul>
-         <li>Transfer-Encoding</li>
-         <li>Content-Length</li>
-         <li>Trailer</li>
+         <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li>
+         <li><a href="#header.content-length" class="smpl">Content-Length</a></li>
+         <li><a href="#header.trailer" class="smpl">Trailer</a></li>
       </ul>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
@@ -1780 +1774 @@
          <p id="rfc.section.5.3.p.3"><span id="rfc.iref.o.3"></span> The most common form of request-target is the origin-form. 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 Host 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>, containing the target URI's authority component (excluding any userinfo).
          </p>
       </div>
@@ -1851 +1845 @@
       <div id="rfc.iref.e.1"></div>
       <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2>
-      <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, Host,
-         and connection context, in order to identify the intended target resource and properly service the request. The URI derived
-         from this reconstruction process is referred to as the "effective request URI".
+      <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request.
+         The URI derived from this reconstruction process is referred to as the "effective request URI".
       </p>
       <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p>
@@ -1863 +1856 @@
       </p>
       <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target.
-         Otherwise, if a Host header field is supplied with a non-empty field-value, then the authority component is the same as the
-         Host field-value. Otherwise, the authority component is the concatenation of the default host name configured for the server,
-         a colon (":"), and the connection's incoming TCP port number in decimal form.
+         Otherwise, if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, then the authority component is the same as the Host field-value. Otherwise,
+         the authority component is the concatenation of the default host name configured for the server, a colon (":"), and the connection's
+         incoming TCP port number in decimal form.
       </p>
       <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component
@@ -1883 +1876 @@
 </pre> <div id="rfc.figure.u.58"></div> 
       <p>has an effective request URI of</p>  <pre class="text">https://www.example.org
-</pre> <p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Host field-value and instead replace it with a configured server name when constructing the effective request URI.
-      </p>
-      <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess
+</pre> <p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the <a href="#header.host" class="smpl">Host</a> field-value and instead replace it with a configured server name when constructing the effective request URI.
+      </p>
+      <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess
          the effective request URI's authority component.
       </p>
@@ -1901 +1894 @@
          except as noted above to replace an empty path with "/" or "*".
       </p>
-      <p id="rfc.section.5.6.p.5">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>.
+      <p id="rfc.section.5.6.p.5">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.5" title="Connection">Section&nbsp;6.1</a>.
       </p>
       <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h3>
@@ -1915 +1908 @@
       <p id="rfc.section.5.6.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
       <ul>
-         <li>Connection</li>
-         <li>Keep-Alive</li>
-         <li>Proxy-Authenticate</li>
-         <li>Proxy-Authorization</li>
-         <li>TE</li>
-         <li>Trailer</li>
-         <li>Transfer-Encoding</li>
-         <li>Upgrade</li>
+         <li><a href="#header.connection" class="smpl">Connection</a></li>
+         <li>Keep-Alive (<a href="http://tools.ietf.org/html/rfc2068#section-19.7.1.1">Section 19.7.1.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>)
+         </li>
+         <li><a href="p7-auth.html#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> (<a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>)
+         </li>
+         <li><a href="p7-auth.html#header.proxy-authorization" class="smpl">Proxy-Authorization</a> (<a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>)
+         </li>
+         <li><a href="#header.te" class="smpl">TE</a></li>
+         <li><a href="#header.trailer" class="smpl">Trailer</a></li>
+         <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li>
+         <li><a href="#header.upgrade" class="smpl">Upgrade</a></li>
       </ul>
       <p id="rfc.section.5.6.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
-      <p id="rfc.section.5.6.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>).
+      <p id="rfc.section.5.6.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in 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>).
       </p>
       <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h3>
@@ -2092 +2088 @@
       </p>
       <p id="rfc.section.6.3.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
-         takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
+         takes place using 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>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
       </p>
       <h4 id="rfc.section.6.3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
-      <p id="rfc.section.6.3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection
-         option "close" was sent in the request. If the server chooses to close the connection immediately after sending the response,
-         it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
+      <p id="rfc.section.6.3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection
+         immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
       </p>
       <p id="rfc.section.6.3.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
-         a Connection header field with the connection option "close". In case the client does not want to maintain a connection for
-         more than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
-      </p>
-      <p id="rfc.section.6.3.2.1.p.3">If either the client or the server sends the "close" option in the Connection header field, that request becomes the last
-         one for the connection.
+         a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that
+         request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close".
+      </p>
+      <p id="rfc.section.6.3.2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection.
       </p>
       <p id="rfc.section.6.3.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
       </p>
       <p id="rfc.section.6.3.2.1.p.5">Each persistent connection applies to only one transport link.</p>
-      <p id="rfc.section.6.3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
+      <p id="rfc.section.6.3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
       </p>
       <p id="rfc.section.6.3.2.1.p.7">In order to remain persistent, all messages on the 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>.
@@ -2182 +2176 @@
          </li>
          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
-            with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"
+            with <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"
             expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared
             wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
@@ -2240 +2234 @@
          although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
       </p>
-      <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
+      <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <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>) whenever Upgrade is present in an HTTP/1.1 message.
       </p>
       <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
@@ -2331 +2325 @@
       </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 "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" 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.10" title="Connection">Section&nbsp;6.1</a>).
       </p>
       <div id="rfc.table.u.1">
@@ -2555 +2549 @@
       </div>
       <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h2>
-      <p id="rfc.section.7.6.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade
-         header field. Each registered protocol-name is associated with contact information and an optional set of specifications that
+      <p id="rfc.section.7.6.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the <a href="#header.upgrade" class="smpl">Upgrade</a> header field. Each registered protocol name is associated with contact information and an optional set of specifications that
          details how the connection will be processed after it has been upgraded.
       </p>
@@ -2672 +2665 @@
       </p>
       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
-      <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.5">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.3">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari
+      <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.6">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.3">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari
          Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Mark Nottingham.
          See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions.
@@ -2712 +2705 @@
       <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
       </h2>
-      <table>                        
+      <table>                          
          <tr>
             <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
@@ -2735 +2728 @@
             <td class="reference"><b id="Part6">[Part6]</b></td>
             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), July&nbsp;2012.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="Part7">[Part7]</b></td>
+            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), July&nbsp;2012.
             </td>
          </tr>
@@ -2928 +2926 @@
       </p>
       <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts
-         (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought
-         to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests
-         wherein a buggy client failed to properly encode linear whitespace found in a URI reference and placed in the request-target.
+         (selection of resource by inspection of the <a href="#header.host" class="smpl">Host</a> header field). Any server that implements name-based virtual hosts ought to disable support for HTTP/0.9. Most requests that
+         appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests wherein a buggy client failed to properly encode linear
+         whitespace found in a URI reference and placed in the request-target.
       </p>
       <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
       <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
       <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3>
-      <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>) are among the most important changes defined by HTTP/1.1.
+      <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the <a href="#header.host" class="smpl">Host</a> header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>) are among the most important changes defined by HTTP/1.1.
       </p>
       <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
-         for distinguishing the intended server of a request than the IP address 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,
+         for distinguishing the intended server of a request than the IP address to which that request was directed. The <a href="#header.host" class="smpl">Host</a> 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 were placed on all HTTP/1.1 requests in order to ensure complete adoption. At the time of this writing,
          most HTTP-based services are dependent upon the Host header field for targeting requests.
@@ -2946 +2943 @@
       <p id="rfc.section.A.1.2.p.1">In HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the
          response. However, some implementations implement the explicitly negotiated ("Keep-Alive") version of persistent connections
-         described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
+         described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
       </p>
       <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly
          negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0
-         persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand Connection, it will erroneously
-         forward that header to the next inbound server, which would result in a hung connection.
+         persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header to the next inbound server, which would result in a hung connection.
       </p>
       <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header, targeted specifically at proxies. In practice, this
@@ -2980 +2976 @@
       <p id="rfc.section.A.2.p.6">Empty list elements in list productions have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section&nbsp;3.2.5</a>)
       </p>
-      <p id="rfc.section.A.2.p.7">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
+      <p id="rfc.section.A.2.p.7">Require recipients to handle bogus <a href="#header.content-length" class="smpl">Content-Length</a> header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
       </p>
       <p id="rfc.section.A.2.p.8">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>)
@@ -2997 +2993 @@
       <p id="rfc.section.A.2.p.14">Clarify exactly when "close" connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;6.1</a>)
       </p>
-      <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.5</a>)
+      <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.5</a>)
       </p>
       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
@@ -3772 +3768 @@
                      </ul>
                   </li>
+                  <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">5.6.1</a>, <a href="#rfc.xref.Part7.2">5.6.1</a>, <a href="#Part7"><b>10.1</b></a><ul>
+                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">5.6.1</a></li>
+                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.2">5.6.1</a></li>
+                     </ul>
+                  </li>
                   <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
                </ul>
@@ -3792 +3793 @@
                   </li>
                   <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li>
-                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.4.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>
-                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>
+                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul>
+                        <li><em>Section 19.7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">5.6.1</a></li>
+                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a></li>
                      </ul>
                   </li>

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

@@ -36 +36 @@
   <!ENTITY header-pragma          "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY header-warning         "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY header-proxy-authenticate  "<xref target='Part7' x:rel='#header.proxy-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY header-proxy-authorization "<xref target='Part7' x:rel='#header.proxy-authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY methods                "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -503 +505 @@
    that wishes to interoperate with third-party HTTP servers &MUST;
    conform to HTTP user agent requirements on the gateway's inbound
-   connection and &MUST; implement the Connection
-   (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)
-   header fields for both connections.
+   connection and &MUST; implement the <x:ref>Connection</x:ref>
+   (<xref target="header.connection"/>) and <x:ref>Via</x:ref>
+   (<xref target="header.via"/>) header fields for both connections.
 </t>
 <t><iref primary="true" item="tunnel"/>
@@ -662 +664 @@
    behavior of a recipient in the absence of such a field can change.
    Unless specified otherwise, header fields defined in HTTP/1.1 are
-   defined for all versions of HTTP/1.x.  In particular, the Host and
-   Connection header fields ought to be implemented by all HTTP/1.x
-   implementations whether or not they advertise conformance with HTTP/1.1.
+   defined for all versions of HTTP/1.x.  In particular, the <x:ref>Host</x:ref>
+   and <x:ref>Connection</x:ref> header fields ought to be implemented by all
+   HTTP/1.x implementations whether or not they advertise conformance with
+   HTTP/1.1.
 </t>
 <t>
@@ -674 +677 @@
    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 Connection header field
+   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
@@ -1162 +1165 @@
    to the procedures in &cons-new-header-fields;.
    Unrecognized header fields &MUST; be forwarded by a proxy unless the
-   field-name is listed in the Connection header field
+   field-name is listed in the <x:ref>Connection</x:ref> header field
    (<xref target="header.connection"/>) or the proxy is specifically
    configured to block or otherwise transform such fields.
@@ -1474 +1477 @@
 <t>
    The presence of a message body in a request is signaled by a
-   a Content-Length or Transfer-Encoding header field.
-   Request message framing is independent of method semantics,
+   a <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header
+   field. Request message framing is independent of method semantics,
    even if the method does not define any use for a message body.
 </t>
@@ -1483 +1486 @@
    status code (<xref target="status-code"/>).
    Responses to the HEAD request method never include a message body
-   because the associated response header fields (e.g., Transfer-Encoding,
-   Content-Length, etc.) only indicate what their values would have been
-   if the request method had been GET.
-   <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of
-   having a message body.
+   because the associated response header fields (e.g.,
+   <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.) only
+   indicate what their values would have been if the request method had been
+   GET. <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel
+   mode instead of having a message body.
    All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and
    <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
@@ -1587 +1590 @@
   <x:anchor-alias value="Content-Length"/>
 <t>
-   When a message does not have a Transfer-Encoding header field and the
-   payload body length can be determined prior to being transferred, a
+   When a message does not have a <x:ref>Transfer-Encoding</x:ref> header field
+   and the payload body length can be determined prior to being transferred, a
    Content-Length header field &SHOULD; be sent to indicate the length of the
    payload body that is either present as the message body, for requests
@@ -1657 +1660 @@
      Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request implies that the
      connection will become a tunnel immediately after the empty line that
-     concludes the header fields.  A client &MUST; ignore any Content-Length
-     or Transfer-Encoding header fields received in such a message.
+     concludes the header fields.  A client &MUST; ignore any
+     <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header
+     fields received in such a message.
     </t></x:lt>
     <x:lt><t>
-     If a Transfer-Encoding header field is present
+     If a <x:ref>Transfer-Encoding</x:ref> header field is present
      and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
      is the final encoding, the message body length is determined by reading
@@ -1668 +1672 @@
     </t>
     <t>
-     If a Transfer-Encoding header field is present in a response and the
-     "chunked" transfer-coding is not the final encoding, the message body
-     length is determined by reading the connection until it is closed by
-     the server.
+     If a <x:ref>Transfer-Encoding</x:ref> header field is present in a
+     response and the "chunked" transfer-coding is not the final encoding, the
+     message body length is determined by reading the connection until it is
+     closed by the server.
      If a Transfer-Encoding header field is present in a request and the
      "chunked" transfer-coding is not the final encoding, the message body
@@ -1678 +1682 @@
     </t>
     <t>
-     If a message is received with both a Transfer-Encoding header field
-     and a Content-Length header field, the Transfer-Encoding overrides
-     the Content-Length.
+     If a message is received with both a <x:ref>Transfer-Encoding</x:ref>
+     and a <x:ref>Content-Length</x:ref> header field, the
+     Transfer-Encoding overrides the Content-Length.
      Such a message might indicate an attempt to perform request or response
      smuggling (bypass of security-related checks on message routing or content)
@@ -1688 +1692 @@
     </t></x:lt>
     <x:lt><t>
-     If a message is received without Transfer-Encoding and with either
-     multiple Content-Length 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.
+     If a message is received without <x:ref>Transfer-Encoding</x:ref> and with
+     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.
      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.
@@ -1702 +1706 @@
     </t></x:lt>
     <x:lt><t>
-     If a valid Content-Length header field 
-     is present without Transfer-Encoding, its decimal value defines the
+     If a valid <x:ref>Content-Length</x:ref> header field is present without
+     <x:ref>Transfer-Encoding</x:ref>, its decimal value defines the
      message body length in octets.  If the actual number of octets sent in
      the message is less than the indicated Content-Length, the recipient
@@ -1736 +1740 @@
 <t>
    A server &MAY; reject a request that contains a message body but
-   not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>.
+   not a <x:ref>Content-Length</x:ref> by responding with
+   <x:ref>411 (Length Required)</x:ref>.
 </t>
 <t>
    Unless a transfer-coding other than "chunked" has been applied,
    a client that sends a request containing a message body &SHOULD;
-   use a valid Content-Length header field if the message body length
-   is known in advance, rather than the "chunked" encoding, since some
+   use a valid <x:ref>Content-Length</x:ref> header field if the message body
+   length is known in advance, rather than the "chunked" encoding, since some
    existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    status code even though they understand the chunked encoding.  This
@@ -1751 +1756 @@
 <t>
    A client that sends a request containing a message body &MUST; include a
-   valid Content-Length header field if it does not know the server will
-   handle HTTP/1.1 (or later) requests; such knowledge can be in the form
-   of specific user configuration or by remembering the version of a prior
-   received response.
+   valid <x:ref>Content-Length</x:ref> header field if it does not know the
+   server will handle HTTP/1.1 (or later) requests; such knowledge can be in
+   the form of specific user configuration or by remembering the version of a
+   prior received response.
 </t>
 </section>
@@ -1777 +1782 @@
    A message body that uses the chunked transfer encoding is
    incomplete if the zero-sized chunk that terminates the encoding has not
-   been received.  A message that uses a valid Content-Length is incomplete
-   if the size of the message body received (in octets) is less than the
-   value given by Content-Length.  A response that has neither chunked
+   been received.  A message that uses a valid <x:ref>Content-Length</x:ref> is
+   incomplete if the size of the message body received (in octets) is less than
+   the value given by Content-Length.  A response that has neither chunked
    transfer encoding nor Content-Length is terminated by closure of the
    connection, and thus is considered complete regardless of the number of
@@ -1866 +1871 @@
    The HTTP Transfer Coding registry is defined in
    <xref target="transfer.coding.registry"/>.
-   HTTP/1.1 uses transfer-coding values in the TE header field
-   (<xref target="header.te"/>) and in the Transfer-Encoding header field
-   (<xref target="header.transfer-encoding"/>).
+   HTTP/1.1 uses transfer-coding values in the <x:ref>TE</x:ref> header field
+   (<xref target="header.te"/>) and in the <x:ref>Transfer-Encoding</x:ref>
+   header field (<xref target="header.transfer-encoding"/>).
 </t>
 
@@ -1921 +1926 @@
 <t>
    The trailer allows the sender to include additional HTTP header
-   fields at the end of the message. The Trailer header field can be
-   used to indicate which header fields are included in a trailer (see
+   fields at the end of the message. The <x:ref>Trailer</x:ref> header field
+   can be used to indicate which header fields are included in a trailer (see
    <xref target="header.trailer"/>).
 </t>
@@ -1930 +1935 @@
    true:
   <list style="numbers">
-    <t>the request included a TE header field that indicates "trailers" is
-     acceptable in the transfer-coding of the  response, as described in
-     <xref target="header.te"/>; or,</t>
+    <t>the request included a <x:ref>TE</x:ref> header field that indicates
+    "trailers" is acceptable in the transfer-coding of the response, as
+    described in <xref target="header.te"/>; or,</t>
      
     <t>the trailer fields consist entirely of optional metadata, and the
@@ -2076 +2081 @@
 <t>
    The TE header field only applies to the immediate connection.
-   Therefore, the keyword &MUST; be supplied within a Connection header
-   field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.
+   Therefore, the keyword &MUST; be supplied within a <x:ref>Connection</x:ref>
+   header field (<xref target="header.connection"/>) whenever TE is present in
+   an HTTP/1.1 message.
 </t>
 <t>
@@ -2120 +2126 @@
   <x:anchor-alias value="qvalue"/>
 <t>
-   Both transfer codings (TE request header field, <xref target="header.te"/>)
-   and content negotiation (&content.negotiation;) use short "floating point"
-   numbers to indicate the relative importance ("weight") of various
-   negotiable parameters.  A weight is normalized to a real number in
-   the range 0 through 1, where 0 is the minimum and 1 the maximum
-   value. If a parameter has a quality value of 0, then content with
+   Both transfer codings (<x:ref>TE</x:ref> request header field,
+   <xref target="header.te"/>) and content negotiation (&content.negotiation;)
+   use short "floating point" numbers to indicate the relative importance
+   ("weight") of various negotiable parameters.  A weight is normalized to a
+   real number in the range 0 through 1, where 0 is the minimum and 1 the
+   maximum value. If a parameter has a quality value of 0, then content with
    this parameter is "not acceptable" for the client. HTTP/1.1
    applications &MUST-NOT; generate more than three digits after the
@@ -2171 +2177 @@
    include the following header fields:
   <list style="symbols">
-    <t>Transfer-Encoding</t>
-    <t>Content-Length</t>
-    <t>Trailer</t>
+    <t><x:ref>Transfer-Encoding</x:ref></t>
+    <t><x:ref>Content-Length</x:ref></t>
+    <t><x:ref>Trailer</x:ref></t>
   </list>
 </t>
@@ -2273 +2279 @@
    If the target URI's path component is empty, then the client &MUST; send
    "/" as the path within the origin-form of request-target.
-   A Host header field is also sent, as defined in
+   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).
@@ -2428 +2434 @@
    A server that receives an HTTP request message &MUST; reconstruct
    the user agent's original target URI, based on the pieces of information
-   learned from the request-target, Host, and connection context, in order
-   to identify the intended target resource and properly service the request.
-   The URI derived from this reconstruction process is referred to as the
-   "effective request URI".
+   learned from the request-target, <x:ref>Host</x:ref> header field, and
+   connection context, in order to identify the intended target resource and
+   properly service the request. The URI derived from this reconstruction
+   process is referred to as the "effective request URI".
 </t>
 <t>
@@ -2449 +2455 @@
    If the request-target is in authority-form, then the effective
    request URI's authority component is the same as the request-target.
-   Otherwise, if a Host header field is supplied with a non-empty field-value,
-   then the authority component is the same as the Host field-value.
-   Otherwise, the authority component is the concatenation of the default
-   host name configured for the server, a colon (":"), and the connection's
-   incoming TCP port number in decimal form.
+   Otherwise, if a <x:ref>Host</x:ref> header field is supplied with a
+   non-empty field-value, then the authority component is the same as the
+   Host field-value. Otherwise, the authority component is the concatenation of
+   the default host name configured for the server, a colon (":"), and the
+   connection's incoming TCP port number in decimal form.
 </t>
 <t>
@@ -2503 +2509 @@
 <t>
    An origin server that does not allow resources to differ by requested
-   host &MAY; ignore the Host field-value and instead replace it with a
-   configured server name when constructing the effective request URI.
-</t>
-<t>
-   Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
-   attempt to use heuristics (e.g., examination of the URI path for
+   host &MAY; ignore the <x:ref>Host</x:ref> field-value and instead replace it
+   with a configured server name when constructing the effective request URI.
+</t>
+<t>
+   Recipients of an HTTP/1.0 request that lacks a <x:ref>Host</x:ref> header
+   field &MAY; attempt to use heuristics (e.g., examination of the URI path for
    something unique to a particular host) in order to guess the
    effective request URI's authority component.
@@ -2542 +2548 @@
 <t>
    Intermediaries that forward a message &MUST; implement the
-   Connection header field as specified in <xref target="header.connection"/>.
+   <x:ref>Connection</x:ref> header field as specified in
+   <xref target="header.connection"/>.
 </t>
 
@@ -2569 +2576 @@
    The following HTTP/1.1 header fields are hop-by-hop header fields:
   <list style="symbols">
-      <t>Connection</t>
-      <t>Keep-Alive</t>
-      <t>Proxy-Authenticate</t>
-      <t>Proxy-Authorization</t>
-      <t>TE</t>
-      <t>Trailer</t>
-      <t>Transfer-Encoding</t>
-      <t>Upgrade</t>
+      <t><x:ref>Connection</x:ref></t>
+      <t>Keep-Alive (<xref target="RFC2068" x:fmt="of" x:sec="19.7.1.1"/>)</t>
+      <t><x:ref>Proxy-Authenticate</x:ref> (&header-proxy-authenticate;)</t>
+      <t><x:ref>Proxy-Authorization</x:ref> (&header-proxy-authorization;)</t>
+      <t><x:ref>TE</x:ref></t>
+      <t><x:ref>Trailer</x:ref></t>
+      <t><x:ref>Transfer-Encoding</x:ref></t>
+      <t><x:ref>Upgrade</x:ref></t>
   </list>
 </t>
@@ -2583 +2590 @@
 </t>
 <t>
-   Other hop-by-hop header fields &MUST; be listed in a Connection header field
-   (<xref target="header.connection"/>).
+   Other hop-by-hop header fields &MUST; be listed in a
+   <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>).
 </t>
 </section>
@@ -2930 +2937 @@
    Persistent connections provide a mechanism by which a client and a
    server can signal the close of a TCP connection. This signaling takes
-   place using the Connection header field (<xref target="header.connection"/>). Once a close
-   has been signaled, the client &MUST-NOT; send any more requests on that
+   place using the <x:ref>Connection</x:ref> header field
+   (<xref target="header.connection"/>). Once a close has been signaled, the
+   client &MUST-NOT; send any more requests on that
    connection.
 </t>
@@ -2938 +2946 @@
 <t>
    An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
-   maintain a persistent connection unless a Connection header field including
-   the connection option "close" was sent in the request. If the server
-   chooses to close the connection immediately after sending the
+   maintain a persistent connection unless a <x:ref>Connection</x:ref> header
+   field including the connection option "close" was sent in the request. If
+   the server chooses to close the connection immediately after sending the
    response, it &SHOULD; send a Connection header field including the
    connection option "close".
@@ -2947 +2955 @@
    An HTTP/1.1 client &MAY; expect a connection to remain open, but would
    decide to keep it open based on whether the response from a server
-   contains a Connection header field with the connection option "close". In case
-   the client does not want to maintain a connection for more than that
-   request, it &SHOULD; send a Connection header field including the
+   contains a <x:ref>Connection</x:ref> header field with the connection option
+   "close". In case the client does not want to maintain a connection for more
+   than that request, it &SHOULD; send a Connection header field including the
    connection option "close".
 </t>
 <t>
    If either the client or the server sends the "close" option in the
-   Connection header field, that request becomes the last one for the
-   connection.
+   <x:ref>Connection</x:ref> header field, that request becomes the last one
+   for the connection.
 </t>
 <t>
@@ -3273 +3281 @@
 <t>
    The Upgrade header field only applies to the immediate connection.
-   Therefore, the upgrade keyword &MUST; be supplied within a Connection
-   header field (<xref target="header.connection"/>) whenever Upgrade is present in an
-   HTTP/1.1 message.
+   Therefore, the upgrade keyword &MUST; be supplied within a
+   <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>)
+   whenever Upgrade is present in an HTTP/1.1 message.
 </t>
 <t>
@@ -3376 +3384 @@
    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 "Connection"
+   conflict with the "close" connection option of the "<x:ref>Connection</x:ref>"
    header field (<xref target="header.connection"/>).
 </t>
@@ -3639 +3647 @@
 <t>
    The HTTP Upgrade Token Registry defines the name space for protocol-name
-   tokens used to identify protocols in the Upgrade header field.
-   Each registered protocol-name is associated with contact information and
-   an optional set of specifications that details how the connection
+   tokens used to identify protocols in the <x:ref>Upgrade</x:ref> header
+   field. Each registered protocol name is associated with contact information
+   and an optional set of specifications that details how the connection
    will be processed after it has been upgraded.
 </t>
@@ -4222 +4230 @@
 </reference>
 
+<reference anchor="Part7">
+  <front>
+    <title>HTTP/1.1, part 7: Authentication</title>
+    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
+      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
+      <address><email>fielding@gbiv.com</email></address>
+    </author>
+    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
+      <organization abbrev="W3C">World Wide Web Consortium</organization>
+      <address><email>ylafon@w3.org</email></address>
+    </author>
+    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
+      <organization abbrev="greenbytes">greenbytes GmbH</organization>
+      <address><email>julian.reschke@greenbytes.de</email></address>
+    </author>
+    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
+  </front>
+  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;"/>
+  <x:source href="p7-auth.xml" basename="p7-auth">
+    <x:defines>Proxy-Authenticate</x:defines>
+    <x:defines>Proxy-Authorization</x:defines>
+  </x:source>
+</reference>
+
 <reference anchor="RFC5234">
   <front>
@@ -4833 +4865 @@
    Since HTTP/0.9 did not support header fields in a request,
    there is no mechanism for it to support name-based virtual
-   hosts (selection of resource by inspection of the Host header
+   hosts (selection of resource by inspection of the <x:ref>Host</x:ref> header
    field).  Any server that implements name-based virtual hosts
    ought to disable support for HTTP/0.9.  Most requests that
@@ -4850 +4882 @@
 <section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
 <t>
-   The requirements that clients and servers support the Host header
-   field (<xref target="header.host"/>), report an error if it is
+   The requirements that clients and servers support the <x:ref>Host</x:ref>
+   header field (<xref target="header.host"/>), report an error if it is
    missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    are among the most important changes defined by HTTP/1.1.
@@ -4859 +4891 @@
    addresses and servers; there was no other established mechanism for
    distinguishing the intended server of a request than the IP address
-   to which that request was directed. The Host header field was
+   to which that request was directed. The <x:ref>Host</x:ref> 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
@@ -4881 +4913 @@
    with a "Connection: keep-alive" request header field. However, some
    experimental implementations of HTTP/1.0 persistent connections are faulty;
-   for example, if a HTTP/1.0 proxy server doesn't understand Connection, it
-   will erroneously forward that header to the next inbound server, which
-   would result in a hung connection.
+   for example, if a HTTP/1.0 proxy server doesn't understand
+   <x:ref>Connection</x:ref>, it will erroneously forward that header to the
+   next inbound server, which would result in a hung connection.
 </t>
 <t>
@@ -4942 +4974 @@
 </t>
 <t>
-  Require recipients to handle bogus Content-Length header fields as errors.
+  Require recipients to handle bogus <x:ref>Content-Length</x:ref> header
+  fields as errors.
   (<xref target="message.body"/>)
 </t>
@@ -4980 +5013 @@
 </t>
 <t>
-  Define the semantics of the "Upgrade" header field in responses other than
-  101 (this was incorporated from <xref target="RFC2817"/>).
+  Define the semantics of the <x:ref>Upgrade</x:ref> header field in responses
+  other than 101 (this was incorporated from <xref target="RFC2817"/>).
   (<xref target="header.upgrade"/>)
 </t>

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

@@ -967 +967 @@
       </p>
       <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
-         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
+         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0".
       </p>
       <p id="rfc.section.2.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
@@ -1114 +1114 @@
       </p>
       <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
-         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
+         or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
          messages in an infinite loop.
       </p>
@@ -1133 +1133 @@
 </pre><p id="rfc.section.2.3.8.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has
          switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately
-         after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
-      </p>
-      <p id="rfc.section.2.3.8.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
+         after the blank line that concludes the successful response's header block.
+      </p>
+      <p id="rfc.section.2.3.8.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
+      </p>
+      <p id="rfc.section.2.3.8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
          governed by HTTP.
       </p>
-      <p id="rfc.section.2.3.8.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p>
+      <p id="rfc.section.2.3.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>
       <div id="rfc.figure.u.5"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=
 
-</pre><p id="rfc.section.2.3.8.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
+</pre><p id="rfc.section.2.3.8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
          to reject the request.
       </p>
-      <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
+      <p id="rfc.section.2.3.8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
          if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding.
       </p>
-      <p id="rfc.section.2.3.8.p.10">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
+      <p id="rfc.section.2.3.8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
          the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority.
       </p>
-      <p id="rfc.section.2.3.8.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
+      <p id="rfc.section.2.3.8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
          the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
          peer undelivered, that data will be discarded.
       </p>
-      <p id="rfc.section.2.3.8.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
+      <p id="rfc.section.2.3.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
       </p>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
@@ -1207 +1209 @@
          </li>
          <li>
-            <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
+            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
             </p>
          </li>
@@ -1673 +1675 @@
       <div id="rfc.iref.s.5"></div>
       <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
-      <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
+      <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
          by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
       </p>
@@ -1987 +1989 @@
       <div id="rfc.iref.s.31"></div>
       <h3 id="rfc.section.4.6.10"><a href="#rfc.section.4.6.10">4.6.10</a>&nbsp;<a id="status.411" href="#status.411">411 Length Required</a></h3>
-      <p id="rfc.section.4.6.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
+      <p id="rfc.section.4.6.10.p.1">The server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
          message.
       </p>
@@ -2022 +2024 @@
       <div id="rfc.iref.s.36"></div>
       <h3 id="rfc.section.4.6.15"><a href="#rfc.section.4.6.15">4.6.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
-      <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
+      <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
       </p>
       <div id="rfc.figure.u.7"></div> 
@@ -2349 +2351 @@
       </div>
       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
-      <p id="rfc.section.6.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure
-         safe and proper transfer of the message.
+      <p id="rfc.section.6.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
       </p>
       <div id="rfc.iref.r.1"></div>
@@ -2369 +2370 @@
          in an HTTP message, it is referred to as the payload of the message.
       </p>
-      <p id="rfc.section.7.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied
-         to ensure safe and proper transfer of the message.
+      <p id="rfc.section.7.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
       </p>
       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
@@ -3052 +3052 @@
 </pre><p id="rfc.section.9.17.p.4">Example:</p>
       <div id="rfc.figure.u.60"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
-</pre><p id="rfc.section.9.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
+</pre><p id="rfc.section.9.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
       </p>
       <div class="note" id="rfc.section.9.17.p.7"> 
@@ -3606 +3606 @@
       </p>
       <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
-         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
+         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any <a href="p1-messaging.html#header.via" class="smpl">Via</a> fields generated behind the firewall.
       </p>
       <p id="rfc.section.11.1.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can
@@ -3925 +3925 @@
       </p>
       <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
-      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.59"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
+      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.59"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
       </p>
       <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>

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

@@ -551 +551 @@
    future extensions to HTTP. Content negotiation &MAY; be used to select
    the appropriate response format. If no response body is included, the
-   response &MUST; include a Content-Length field with a field-value of
-   "0".
+   response &MUST; include a <x:ref>Content-Length</x:ref> field with a
+   field-value of "0".
 </t>
 <t>
@@ -881 +881 @@
    TRACE allows the client to see what is being received at the other
    end of the request chain and use that data for testing or diagnostic
-   information. The value of the Via header field (&header-via;) is of
-   particular interest, since it acts as a trace of the request chain.
+   information. The value of the <x:ref>Via</x:ref> header field (&header-via;)
+   is of particular interest, since it acts as a trace of the request chain.
    Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
    limit the length of the request chain, which is useful for testing a chain of
@@ -921 +921 @@
    The tunneled data from the server begins immediately after the blank line
    that concludes the successful response's header block.
-   A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
-   header fields in a successful response.
+</t>
+<t>
+   A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or
+   <x:ref>Content-Length</x:ref> header fields in a successful response.
    A client &MUST; ignore any Content-Length or Transfer-Encoding header
    fields received in a successful response.
@@ -1056 +1058 @@
     responses or requests, in all messages, only on responses to a particular
     request method.</t></x:lt>
-    <x:lt><t>Whether it is appropriate to list the field-name in the Connection header
-    (i.e., if the header is to be hop-by-hop, see &header-connection;).</t></x:lt>
+    <x:lt><t>Whether it is appropriate to list the field-name in the
+    <x:ref>Connection</x:ref> header field (i.e., if the header field is to
+    be hop-by-hop, see &header-connection;).</t></x:lt>
     <x:lt><t>Under what conditions intermediaries are allowed to modify the header
     field's value, insert or delete it.</t></x:lt>
@@ -1347 +1350 @@
   <x:anchor-alias value="101 (Switching Protocols)"/>
 <t>
-   The server understands and is willing to comply with the client's
-   request, via the Upgrade message header field (&header-upgrade;), for a
-   change in the application protocol being used on this connection. The
-   server will switch protocols to those defined by the response's
-   Upgrade header field immediately after the empty line which
-   terminates the 101 response.
+   The server understands and is willing to comply with the client's request,
+   via the <x:ref>Upgrade</x:ref> message header field (&header-upgrade;), for
+   a change in the application protocol being used on this connection. The
+   server will switch protocols to those defined by the response's Upgrade
+   header field immediately after the empty line which terminates the 101
+   response.
 </t>
 <t>
@@ -1984 +1987 @@
   <x:anchor-alias value="411 (Length Required)"/>
 <t>
-   The server refuses to accept the request without a defined Content-Length.
-   The client &MAY; repeat the request if it adds a valid
-   Content-Length header field containing the length of the message body
-   in the request message.
+   The server refuses to accept the request without a defined
+   <x:ref>Content-Length</x:ref>. The client &MAY; repeat the request if it
+   adds a valid Content-Length header field containing the length of the
+   message body in the request message.
 </t>
 </section>
@@ -2053 +2056 @@
 <t>
    The request can not be completed without a prior protocol upgrade. This
-   response &MUST; include an Upgrade header field (&header-upgrade;)
-   specifying the required protocols.
+   response &MUST; include an <x:ref>Upgrade</x:ref> header field
+   (&header-upgrade;) specifying the required protocols.
 </t>
 <figure>
@@ -2661 +2664 @@
    A payload body is only present in a message when a message body is
    present, as described in &message-body;. The payload body is obtained
-   from the message body by decoding any Transfer-Encoding that might
-   have been applied to ensure safe and proper transfer of the message.
+   from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that
+   might have been applied to ensure safe and proper transfer of the message.
 </t>
 </section>
@@ -2701 +2704 @@
    A representation body is only present in a message when a message body is
    present, as described in &message-body;. The representation body is obtained
-   from the message body by decoding any Transfer-Encoding that might
-   have been applied to ensure safe and proper transfer of the message.
+   from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that
+   might have been applied to ensure safe and proper transfer of the message.
 </t>
 
@@ -3938 +3941 @@
 </artwork></figure>
 <t>
-   If the response is being forwarded through a proxy, the proxy
-   application &MUST-NOT; modify the Server header field. Instead, it
-   &MUST; include a Via field (as described in &header-via;).
+   If the response is being forwarded through a proxy, the proxy application
+   &MUST-NOT; modify the <x:ref>Server</x:ref> header field. Instead, it
+   &MUST; include a <x:ref>Via</x:ref> field (as described in &header-via;).
 </t>
 <x:note>
@@ -4478 +4481 @@
    take special precautions regarding the transfer of header information
    that identifies the hosts behind the firewall. In particular, they
-   &SHOULD; remove, or replace with sanitized versions, any Via fields
-   generated behind the firewall.
+   &SHOULD; remove, or replace with sanitized versions, any <x:ref>Via</x:ref>
+   fields generated behind the firewall.
 </t>
 <t>
@@ -4645 +4648 @@
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
   <x:source href="p1-messaging.xml" basename="p1-messaging">
+    <x:defines>Connection</x:defines>
     <x:defines>Content-Length</x:defines>
     <x:defines>Transfer-Encoding</x:defines>
+    <x:defines>Upgrade</x:defines>
     <x:defines>Via</x:defines>
   </x:source>
@@ -5443 +5448 @@
 <section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding">
 <t>
-   HTTP/1.1 introduces the Transfer-Encoding header field (&header-transfer-encoding;).
-   Proxies/gateways &MUST; remove any transfer-coding prior to
-   forwarding a message via a MIME-compliant protocol.
+   HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field
+   (&header-transfer-encoding;). Proxies/gateways &MUST; remove any
+   transfer-coding prior to forwarding a message via a MIME-compliant protocol.
 </t>
 </section>

draft-ietf-httpbis/latest/p5-range.html

@@ -771 +771 @@
       </h2>
       <p id="rfc.section.4.1.p.1">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to
-         a request for a set of ranges that overlap without any holes), this content is transmitted with a <a href="#header.content-range" class="smpl">Content-Range</a> header field, and a Content-Length header field showing the number of bytes actually transferred. For example,
+         a request for a set of ranges that overlap without any holes), this content is transmitted with a <a href="#header.content-range" class="smpl">Content-Range</a> header field, and a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field showing the number of bytes actually transferred. For example,
       </p>
       <div id="rfc.figure.u.5"></div><pre class="text">HTTP/1.1 206 Partial Content
@@ -807 +807 @@
       </p>
       <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected
-         responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a Content-Length header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field describing the included range(s) and be recorded as incomplete. If the union consists of a discontinuous range
+         responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field describing the included range(s) and be recorded as incomplete. If the union consists of a discontinuous range
          of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple <a href="#status.206" class="smpl">206</a> responses with one continuous range each.
       </p>

draft-ietf-httpbis/latest/p5-range.xml

@@ -403 +403 @@
    for a set of ranges that overlap without any holes), this content is
    transmitted with a <x:ref>Content-Range</x:ref> header field, and a
-   Content-Length header field showing the number of bytes actually transferred.
-   For example,
+   <x:ref>Content-Length</x:ref> header field showing the number of bytes
+   actually transferred. For example,
 </t>
 <figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
@@ -481 +481 @@
    content ranges in the new response and each of the selected responses.
    If the union consists of the entire range of the representation, then the
-   combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref> response
-   with a Content-Length header field that reflects the complete length.
-   Otherwise, the combined response(s) &MUST; include a <x:ref>Content-Range</x:ref>
-   header field describing the included range(s) and be recorded as
-   incomplete.  If the union consists of a discontinuous range of the
-   representation, then the client &MAY; store it as either a multipart range
-   response or as multiple <x:ref>206</x:ref> responses with one continuous range each.
+   combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref>
+   response with a <x:ref>Content-Length</x:ref> header field that reflects the
+   complete length. Otherwise, the combined response(s) &MUST; include a
+   <x:ref>Content-Range</x:ref> header field describing the included range(s)
+   and be recorded as incomplete.  If the union consists of a discontinuous
+   range of the representation, then the client &MAY; store it as either a
+   multipart range response or as multiple <x:ref>206</x:ref> responses with
+   one continuous range each.
 </t>
 </section>

draft-ietf-httpbis/latest/p6-cache.html

@@ -1028 +1028 @@
       <p>These <em class="bcp14">SHOULD</em> be combined as
       </p>  <pre class="text">  corrected_initial_age = max(apparent_age, corrected_age_value);
-</pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the Via header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
+</pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
       </p>
       <p id="rfc.section.2.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
@@ -1120 +1120 @@
          a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
       </p>
-      <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) for a HEAD request, and the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
-      </p>
-      <p id="rfc.section.2.5.p.3">If the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules: 
+      <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
+      </p>
+      <p id="rfc.section.2.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules: 
       </p>
       <ul>

draft-ietf-httpbis/latest/p6-cache.xml

@@ -808 +808 @@
 <t>
    unless the cache is confident in the value of the <x:ref>Age</x:ref> header
-   field (e.g., because there are no HTTP/1.0 hops in the Via header field), in
-   which case the corrected_age_value &MAY; be used as the
+   field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref>
+   header field), in which case the corrected_age_value &MAY; be used as the
    corrected_initial_age.</t>
 <t>
@@ -991 +991 @@
    If one or more stored GET responses can be selected (as per <xref
    target="caching.negotiated.responses"/>) for a HEAD request, and the
-   Content-Length, <x:ref>ETag</x:ref> or <x:ref>Last-Modified</x:ref> value of
-   a HEAD response differs from that in a selected GET response, the cache
-   &MUST; consider that selected response to be stale.
-</t>
-<t>
-   If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>
-   values of a HEAD response (when present) are the same as that in a selected
-   GET response (as per <xref target="caching.negotiated.responses"/>), the
-   cache &SHOULD; update the remaining headers in the stored response using the
-   following rules:
+   <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> or
+   <x:ref>Last-Modified</x:ref> value of a HEAD response differs from that in a
+   selected GET response, the cache &MUST; consider that selected response to
+   be stale.
+</t>
+<t>
+   If the <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> and
+   <x:ref>Last-Modified</x:ref> values of a HEAD response (when present) are
+   the same as that in a selected GET response (as per
+   <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update
+   the remaining headers in the stored response using the following rules:
    <list style="symbols">
       <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
@@ -2280 +2281 @@
     </front>
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;" />
-    <x:source basename="p1-messaging" href="p1-messaging.xml" />
+    <x:source basename="p1-messaging" href="p1-messaging.xml">
+      <x:defines>Content-Length</x:defines>
+      <x:defines>Via</x:defines>
+    </x:source>
   </reference>