Changeset 647

Timestamp:

Jul 28, 2009, 8:02:09 AM (10 years ago)

Author:

fielding@…

Message:

first pass at cleaning up message parsing definition: header fields.

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (59 diffs)
• p1-messaging.xml (modified) (14 diffs)
• p2-semantics.html (modified) (2 diffs)
• p3-payload.html (modified) (6 diffs)
• p3-payload.xml (modified) (6 diffs)
• p5-range.html (modified) (1 diff)
• p6-cache.html (modified) (4 diffs)
• p6-cache.xml (modified) (3 diffs)

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

@@ -548 +548 @@
          </li>
          <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#http.message">HTTP Message</a><ul class="toc">
-               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#message.types">Message Types</a></li>
-               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#message.headers">Message Headers</a></li>
+               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#message.robustness">Message Parsing Robustness</a></li>
+               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a></li>
                <li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a></li>
                <li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#message.length">Message Length</a></li>
@@ -602 +602 @@
             </ul>
          </li>
-         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
+         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul class="toc">
                <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
                <li class="tocline1">8.2&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
@@ -769 +769 @@
                  ; "bad" whitespace
   <a href="#rule.whitespace" class="smpl">obs-fold</a>       = <a href="#core.rules" class="smpl">CRLF</a>
-                 ; see <a href="#message.headers" title="Message Headers">Section&nbsp;3.2</a>
+                 ; see <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
 </pre><div id="rule.token.separators">
          <p id="rfc.section.1.2.2.p.8">    Many HTTP/1.1 header field values consist of words separated by whitespace or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
@@ -911 +911 @@
          Even when a response is cacheable, there may be additional constraints placed by the client or by the origin server on when
          that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are
-         defined in <a href="p6-cache.html#caching" title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
+         defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
       </p>
       <p id="rfc.section.2.3.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
          inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems
-         that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so on.
+         that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so
+         on.
       </p>
       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="transport-independence" href="#transport-independence">Transport Independence</a></h2>
@@ -1063 +1064 @@
       </p>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="http.message" href="#http.message">HTTP Message</a></h1>
-      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="message.types" href="#message.types">Message Types</a></h2>
-      <p id="rfc.section.3.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>
-      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#message.types" class="smpl">HTTP-message</a>   = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a>     ; HTTP/1.1 messages
-</pre><p id="rfc.section.3.1.p.3">Request (<a href="#request" title="Request">Section&nbsp;4</a>) and Response (<a href="#response" title="Response">Section&nbsp;5</a>) messages use the generic message format of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header
-         fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header
-         fields, and possibly a message-body.
-      </p>
-      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a>
-                    *( <a href="#message.headers" class="smpl">message-header</a> <a href="#core.rules" class="smpl">CRLF</a> )
+      <div id="rfc.iref.h.3"></div>
+      <div id="rfc.iref.h.4"></div>
+      <div id="rfc.iref.h.5"></div>
+      <p id="rfc.section.3.p.1">All HTTP/1.1 messages consist of a start-line followed by a sequence of characters in a format similar to the Internet Message
+         Format <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating
+         the end of the header section, and an optional message-body.
+      </p>
+      <p id="rfc.section.3.p.2">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two
+         types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses),
+         and in the algorithm for determining the length of the message-body (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
+         start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown
+         or invalid request method) and clients are implemented to only expect a response.
+      </p>
+      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#http.message" class="smpl">HTTP-message</a>    = <a href="#http.message" class="smpl">start-line</a>
+                    *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
                     <a href="#core.rules" class="smpl">CRLF</a>
                     [ <a href="#message.body" class="smpl">message-body</a> ]
-  <a href="#message.types" class="smpl">start-line</a>      = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a>
-</pre><p id="rfc.section.3.1.p.5">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol
-         stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
-      </p>
-      <p id="rfc.section.3.1.p.6">Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden
-         by the BNF, an HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF.
-      </p>
-      <p id="rfc.section.3.1.p.7">Whitespace (WSP) <em class="bcp14">MUST NOT</em> be sent between the start-line and the first header field. The presence of whitespace might be an attempt to trick a noncompliant
+  <a href="#http.message" class="smpl">start-line</a>      = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a>
+</pre><p id="rfc.section.3.p.4">Whitespace (WSP) <em class="bcp14">MUST NOT</em> be sent between the start-line and the first header field. The presence of whitespace might be an attempt to trick a noncompliant
          implementation of HTTP into ignoring that field or processing the next line as a new request, either of which may result in
          security issues when implementations within the request chain interpret the same message differently. HTTP/1.1 servers <em class="bcp14">MUST</em> reject such a message with a 400 (Bad Request) response.
       </p>
-      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="message.headers" href="#message.headers">Message Headers</a></h2>
-      <p id="rfc.section.3.2.p.1">HTTP header fields follow the same general format as Internet messages in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":"), optional whitespace, and the field value. Field names are
-         case-insensitive.
-      </p>
-      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span>  <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" OWS [ <a href="#message.headers" class="smpl">field-value</a> ] OWS
-  <a href="#message.headers" class="smpl">field-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
-  <a href="#message.headers" class="smpl">field-value</a>    = *( <a href="#message.headers" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> )
-  <a href="#message.headers" class="smpl">field-content</a>  = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
-</pre><p id="rfc.section.3.2.p.3">Historically, HTTP has allowed field-content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding (allowing other character sets through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding). In practice, most HTTP header field-values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> constrain their field-values to US-ASCII characters. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field-content as opaque data.
-      </p>
-      <p id="rfc.section.3.2.p.4">No whitespace is allowed between the header field-name and colon. For security reasons, any request message received containing
-         such whitespace <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request) and any such whitespace in a response message <em class="bcp14">MUST</em> be removed.
-      </p>
-      <p id="rfc.section.3.2.p.5">The field value <em class="bcp14">MAY</em> be preceded by optional whitespace; a single SP is preferred. The field-value does not include any leading or trailing white
-         space: OWS occurring before the first non-whitespace character of the field-value or after the last non-whitespace character
-         of the field-value is ignored and <em class="bcp14">MAY</em> be removed without changing the meaning of the header field.
-      </p>
-      <p id="rfc.section.3.2.p.6">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
-         space or horizontal tab character (line folding). This specification deprecates such line folding except within the message/http
-         media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>). HTTP/1.1 senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the
-         message is intended for packaging within the message/http media type. HTTP/1.1 recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with a single SP prior to interpreting the field value or
-         forwarding the message downstream.
-      </p>
-      <div id="rule.comment">
-         <p id="rfc.section.3.2.p.7">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
-            in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part
-            of the field value.
-         </p>
-      </div>
-      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
-  <a href="#rule.comment" class="smpl">ctext</a>          = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
-                 ; <a href="#rule.whitespace" class="smpl">OWS</a> / &lt;<a href="#core.rules" class="smpl">VCHAR</a> except "(", ")", and "\"&gt; / <a href="#rule.quoted-string" class="smpl">obs-text</a>
-</pre><p id="rfc.section.3.2.p.9">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
-         to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header
-         fields.
-      </p>
-      <p id="rfc.section.3.2.p.10">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e.,
-         #(values)]. It <em class="bcp14">MUST</em> be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics
-         of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header
-         fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and
-         thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded.
+      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
+      <p id="rfc.section.3.1.p.1">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol
+         stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
+      </p>
+      <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations generate an extra CRLF after a POST request as a lame workaround for some early server
+         applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then
+         the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length.
+      </p>
+      <p id="rfc.section.3.1.p.3">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a
+         hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If
+         a message-body has been indicated, then it is read as a stream until an amount of OCTETs equal to the message-length is read
+         or the connection is closed. Care must be taken to parse an HTTP message as a sequence of OCTETs in an encoding that is a
+         superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16 may introduce
+         security flaws due to the differing ways that such parsers interpret invalid characters.
+      </p>
+      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h2>
+      <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field
+         value.
+      </p>
+      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" OWS [ <a href="#header.fields" class="smpl">field-value</a> ] OWS
+  <a href="#header.fields" class="smpl">field-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
+  <a href="#header.fields" class="smpl">field-value</a>    = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> )
+  <a href="#header.fields" class="smpl">field-content</a>  = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
+</pre><p id="rfc.section.3.2.p.3">No whitespace is allowed between the header field name and colon. For security reasons, any request message received containing
+         such whitespace <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
+      </p>
+      <p id="rfc.section.3.2.p.4">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing
+         white space: OWS occurring before the first non-whitespace character of the field value or after the last non-whitespace character
+         of the field value is ignored and <em class="bcp14">SHOULD</em> be removed without changing the meaning of the header field.
+      </p>
+      <p id="rfc.section.3.2.p.5">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
+         to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations
+         can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include
+         conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.
+      </p>
+      <p id="rfc.section.3.2.p.6">Multiple header fields with the same field name <em class="bcp14">MAY</em> be sent in a message if and only if the entire field value for that header field is defined as a comma-separated list [i.e.,
+         #(values)]. Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without
+         changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated
+         by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation
+         of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
       </p>
       <div class="note"> 
@@ -1132 +1132 @@
          </p> 
       </div>
-      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
+      <p id="rfc.section.3.2.p.8">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
+         space or horizontal tab character (line folding). This specification deprecates such line folding except within the message/http
+         media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>). HTTP/1.1 senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the
+         message is intended for packaging within the message/http media type. HTTP/1.1 recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with a single SP prior to interpreting the field value or
+         forwarding the message downstream.
+      </p>
+      <p id="rfc.section.3.2.p.9">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII characters. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data.
+      </p>
+      <div id="rule.comment">
+         <p id="rfc.section.3.2.p.10">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
+            in fields containing "comment" as part of their field value definition.
+         </p>
+      </div>
+      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
+  <a href="#rule.comment" class="smpl">ctext</a>          = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
+                 ; <a href="#rule.whitespace" class="smpl">OWS</a> / &lt;<a href="#core.rules" class="smpl">VCHAR</a> except "(", ")", and "\"&gt; / <a href="#rule.quoted-string" class="smpl">obs-text</a>
+</pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
       <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The
          message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
          header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.7</a>).
       </p>
-      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>
+      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.42"></span>  <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>
                / &lt;entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>&gt;
 </pre><p id="rfc.section.3.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding
@@ -1144 +1160 @@
       <p id="rfc.section.3.3.p.4">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.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
-         in the request's message-headers. When a request message contains both a message-body of non-zero length and a method that
-         does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented
+         in the request's header fields. When a request message contains both a message-body of non-zero length and a method that does
+         not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented
          the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response.
       </p>
@@ -1204 +1220 @@
          to the entity being transferred. These header fields apply only to the message being transmitted.
       </p>
-      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>
+      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>
                  / <a href="#header.connection" class="smpl">Connection</a>               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>
                  / <a href="#header.date" class="smpl">Date</a>                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a>
@@ -1221 +1237 @@
          resource, the identifier of the resource, and the protocol version in use.
       </p>
-      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;4.1</a>
+      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;4.1</a>
                   *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.5</a>
                    / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>
@@ -1231 +1247 @@
          The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
       </p>
-      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
+      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
 </pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h3>
       <p id="rfc.section.4.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p>
-      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
+      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
       <p id="rfc.section.4.1.2.p.1">The request-target identifies the resource upon which to apply the request.</p>
-      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
+      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
                  / <a href="#uri" class="smpl">absolute-URI</a>
                  / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
@@ -1245 +1261 @@
          apply to a resource. One example would be
       </p>
-      <div id="rfc.figure.u.32"></div><pre class="text">  OPTIONS * HTTP/1.1
+      <div id="rfc.figure.u.31"></div><pre class="text">  OPTIONS * HTTP/1.1
 </pre><p id="rfc.section.4.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
          and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
@@ -1251 +1267 @@
          Request-Line would be:
       </p>
-      <div id="rfc.figure.u.33"></div><pre class="text">  GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
+      <div id="rfc.figure.u.32"></div><pre class="text">  GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
 </pre><p id="rfc.section.4.1.2.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
       </p>
@@ -1260 +1276 @@
          server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
       </p>
-      <div id="rfc.figure.u.34"></div><pre class="text">  GET /pub/WWW/TheProject.html HTTP/1.1
+      <div id="rfc.figure.u.33"></div><pre class="text">  GET /pub/WWW/TheProject.html HTTP/1.1
   Host: www.example.org
 </pre><p id="rfc.section.4.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
@@ -1268 +1284 @@
          asterisk form of request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
       </p>
-      <div id="rfc.figure.u.35"></div>
+      <div id="rfc.figure.u.34"></div>
       <p>For example, the request</p><pre class="text">  OPTIONS http://www.example.org:8001 HTTP/1.1
-</pre><div id="rfc.figure.u.36"></div>
+</pre><div id="rfc.figure.u.35"></div>
       <p>would be forwarded by the proxy as</p><pre class="text">  OPTIONS * HTTP/1.1
   Host: www.example.org:8001
@@ -1313 +1329 @@
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
       <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
-      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;5.1</a>
+      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.49"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;5.1</a>
                   *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.5</a>
                    / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>
@@ -1324 +1340 @@
          CRLF sequence.
       </p>
-      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
+      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
       <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
@@ -1341 +1357 @@
          <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
       </ul>
-      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
+      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
   <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a>  = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2>
       <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p>
-      <div id="rfc.figure.u.40"></div><pre class="text">  Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
+      <div id="rfc.figure.u.39"></div><pre class="text">  Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
   Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
@@ -1356 +1372 @@
          time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar.
       </p>
-      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
+      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
 </pre><div id="preferred.date.format">
          <p id="rfc.section.6.1.p.6">                    Preferred format:</p>
       </div>
-      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
+      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
 
   <a href="#preferred.date.format" class="smpl">day-name</a>     = %x4D.6F.6E ; "Mon", case-sensitive
@@ -1396 +1412 @@
   <a href="#preferred.date.format" class="smpl">minute</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
   <a href="#preferred.date.format" class="smpl">second</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
-</pre><p id="rfc.section.6.1.p.8">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
+</pre><p id="rfc.section.6.1.p.8">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
       </p>
       <div id="obsolete.date.formats">
          <p id="rfc.section.6.1.p.9">                Obsolete formats:</p>
       </div>
-      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.69"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 
-</pre><div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.70"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
+      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 
+</pre><div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.68"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
   <a href="#obsolete.date.formats" class="smpl">date2</a>        = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a>
                  ; day-month-year (e.g., 02-Jun-82)
@@ -1413 +1429 @@
          / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
          / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
-</pre><div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
+</pre><div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.69"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
   <a href="#obsolete.date.formats" class="smpl">date3</a>        = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> ))
                  ; month day (e.g., Jun  2)
@@ -1431 +1447 @@
          is a property of the message, not of the original entity.
       </p>
-      <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>
+      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>
   <a href="#transfer.codings" class="smpl">transfer-extension</a>      = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> )
 </pre><div id="rule.parameter">
          <p id="rfc.section.6.2.p.3">      Parameters are in the form of attribute/value pairs.</p>
       </div>
-      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
+      <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
   <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">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
@@ -1445 +1461 @@
          (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>).
       </p>
-      <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has
-         a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty
-         in determining the exact body length (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>), or the desire to encrypt data over a shared transport.
+      <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
+         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic
+         of message-bodies is the difficulty in determining the exact body length (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>), or the desire to encrypt data over a shared transport.
       </p>
       <p id="rfc.section.6.2.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry
@@ -1461 +1477 @@
          necessary for the recipient to verify that it has received the full message.
       </p>
-      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span>  <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>
+      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span>  <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>
                    <a href="#chunked.transfer.encoding" class="smpl">last-chunk</a>
                    <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a>
@@ -1499 +1515 @@
       </p>
       <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
-      <div id="rfc.figure.u.49"></div><pre class="text">  length := 0
+      <div id="rfc.figure.u.48"></div><pre class="text">  length := 0
   read chunk-size, chunk-ext (if any) and CRLF
   while (chunk-size &gt; 0) {
@@ -1521 +1537 @@
          By convention, the products are listed in order of their significance for identifying the application.
       </p>
-      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
+      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
   <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
 </pre><p id="rfc.section.6.3.p.3">Examples:</p>
-      <div id="rfc.figure.u.51"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+      <div id="rfc.figure.u.50"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
   Server: Apache/0.8.4
 </pre><p id="rfc.section.6.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
@@ -1533 +1549 @@
          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.
       </p>
-      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.90"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
+      <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.88"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
                  / ( "1" [ "." 0*3("0") ] )
 </pre><div class="note"> 
@@ -1717 +1733 @@
          </li>
       </ul>
-      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
+      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
       <p id="rfc.section.8.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p>
       <p id="rfc.section.8.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
@@ -1723 +1739 @@
       </p>
       <div id="rfc.iref.c.5"></div>
-      <div id="rfc.iref.h.3"></div>
+      <div id="rfc.iref.h.6"></div>
       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
       <p id="rfc.section.8.1.p.1">The general-header field "Connection" allows the sender to specify options that are desired for that particular connection
@@ -1729 +1745 @@
       </p>
       <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p>
-      <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.connection" class="smpl">Connection</a>       = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>
+      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span>  <a href="#header.connection" class="smpl">Connection</a>       = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>
   <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
   <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
@@ -1742 +1758 @@
          of the response. For example,
       </p>
-      <div id="rfc.figure.u.54"></div><pre class="text">  Connection: close
+      <div id="rfc.figure.u.53"></div><pre class="text">  Connection: close
 </pre><p id="rfc.section.8.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>) after the current request/response is complete.
       </p>
@@ -1753 +1769 @@
       </p>
       <div id="rfc.iref.c.6"></div>
-      <div id="rfc.iref.h.4"></div>
+      <div id="rfc.iref.h.7"></div>
       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
       <p id="rfc.section.8.2.p.1">The entity-header field "Content-Length" indicates the size of the entity-body, in number of OCTETs, sent to the recipient
          or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
       </p>
-      <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span>  <a href="#header.content-length" class="smpl">Content-Length</a>   = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>
+      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.content-length" class="smpl">Content-Length</a>   = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>
   <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
 </pre><p id="rfc.section.8.2.p.3">An example is</p>
-      <div id="rfc.figure.u.56"></div><pre class="text">  Content-Length: 3495
+      <div id="rfc.figure.u.55"></div><pre class="text">  Content-Length: 3495
 </pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section&nbsp;3.4</a>.
       </p>
@@ -1771 +1787 @@
       </p>
       <div id="rfc.iref.d.2"></div>
-      <div id="rfc.iref.h.5"></div>
+      <div id="rfc.iref.h.8"></div>
       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
       <p id="rfc.section.8.3.p.1">The general-header field "Date" represents the date and time at which the message was originated, having the same semantics
-         as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
-      </p>
-      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span>  <a href="#header.date" class="smpl">Date</a>   = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>
+         as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
+      </p>
+      <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span>  <a href="#header.date" class="smpl">Date</a>   = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>
   <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>
 </pre><p id="rfc.section.8.3.p.3">An example is</p>
-      <div id="rfc.figure.u.58"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
+      <div id="rfc.figure.u.57"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 
       </p>
@@ -1807 +1823 @@
          of responses without storing separate Expires values for each resource).
       </p>
-      <div id="rfc.iref.h.6"></div>
-      <div id="rfc.iref.h.7"></div>
+      <div id="rfc.iref.h.9"></div>
+      <div id="rfc.iref.h.10"></div>
       <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
       <p id="rfc.section.8.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from
@@ -1815 +1831 @@
          a single IP address.
       </p>
-      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span>  <a href="#header.host" class="smpl">Host</a>   = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>
+      <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span>  <a href="#header.host" class="smpl">Host</a>   = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>
   <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>
 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
          URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
       </p>
-      <div id="rfc.figure.u.60"></div><pre class="text">  GET /pub/WWW/ HTTP/1.1
+      <div id="rfc.figure.u.59"></div><pre class="text">  GET /pub/WWW/ HTTP/1.1
   Host: www.example.org
 </pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name
@@ -1829 +1845 @@
       </p>
       <div id="rfc.iref.t.2"></div>
-      <div id="rfc.iref.h.8"></div>
+      <div id="rfc.iref.h.11"></div>
       <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
       <p id="rfc.section.8.5.p.1">The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether
@@ -1835 +1851 @@
          and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
       </p>
-      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span>  <a href="#header.te" class="smpl">TE</a>        = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>
+      <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span>  <a href="#header.te" class="smpl">TE</a>        = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>
   <a href="#header.te" class="smpl">TE-v</a>      = #<a href="#header.te" class="smpl">t-codings</a>
   <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] )
@@ -1844 +1860 @@
       </p>
       <p id="rfc.section.8.5.p.4">Examples of its use are:</p>
-      <div id="rfc.figure.u.62"></div><pre class="text">  TE: deflate
+      <div id="rfc.figure.u.61"></div><pre class="text">  TE: deflate
   TE:
   TE: trailers, deflate;q=0.5
@@ -1876 +1892 @@
       </p>
       <div id="rfc.iref.t.3"></div>
-      <div id="rfc.iref.h.9"></div>
+      <div id="rfc.iref.h.12"></div>
       <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
       <p id="rfc.section.8.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with
          chunked transfer-coding.
       </p>
-      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span>  <a href="#header.trailer" class="smpl">Trailer</a>   = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>
-  <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a>
+      <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span>  <a href="#header.trailer" class="smpl">Trailer</a>   = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>
+  <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
          to know which header fields to expect in the trailer.
@@ -1896 +1912 @@
       </ul>
       <div id="rfc.iref.t.4"></div>
-      <div id="rfc.iref.h.10"></div>
+      <div id="rfc.iref.h.13"></div>
       <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
       <p id="rfc.section.8.7.p.1">The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message
@@ -1902 +1918 @@
          transfer-coding is a property of the message, not of the entity.
       </p>
-      <div id="rfc.figure.u.64"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>
+      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>
                         <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a>
   <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>. An example is:
       </p>
-      <div id="rfc.figure.u.65"></div><pre class="text">  Transfer-Encoding: chunked
+      <div id="rfc.figure.u.64"></div><pre class="text">  Transfer-Encoding: chunked
 </pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.
       </p>
       <p id="rfc.section.8.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p>
       <div id="rfc.iref.u.5"></div>
-      <div id="rfc.iref.h.11"></div>
+      <div id="rfc.iref.h.14"></div>
       <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
       <p id="rfc.section.8.8.p.1">The general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like
          to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
       </p>
-      <div id="rfc.figure.u.66"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>   = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>
+      <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>   = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>
   <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a>
 </pre><p id="rfc.section.8.8.p.3">For example,</p>
-      <div id="rfc.figure.u.67"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+      <div id="rfc.figure.u.66"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
          protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
@@ -1943 +1959 @@
       </p>
       <div id="rfc.iref.v.1"></div>
-      <div id="rfc.iref.h.12"></div>
+      <div id="rfc.iref.h.15"></div>
       <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
       <p id="rfc.section.8.9.p.1">The general-header field "Via" <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
-         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.6"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
+         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
          of all senders along the request/response chain.
       </p>
-      <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span>  <a href="#header.via" class="smpl">Via</a>               = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>
+      <div id="rfc.figure.u.67"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span>  <a href="#header.via" class="smpl">Via</a>               = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>
   <a href="#header.via" class="smpl">Via-v</a>             = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
                           [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
@@ -1974 +1990 @@
          server at www.example.com. The request received by www.example.com would then have the following Via header field:
       </p>
-      <div id="rfc.figure.u.69"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
+      <div id="rfc.figure.u.68"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
 </pre><p id="rfc.section.8.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
       </p>
@@ -1980 +1996 @@
          For example,
       </p>
-      <div id="rfc.figure.u.70"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+      <div id="rfc.figure.u.69"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p>
-      <div id="rfc.figure.u.71"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+      <div id="rfc.figure.u.70"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
 </pre><p id="rfc.section.8.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
          by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
@@ -2070 +2086 @@
       <p id="rfc.section.9.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>
-      <p id="rfc.section.9.2.p.1">The entry for the "http" URI Scheme in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; should be updated to point to <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
+      <p id="rfc.section.9.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; should be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.6.1</a> and <a href="#https.uri" title="https URI scheme">2.6.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
       </p>
       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
@@ -2464 +2480 @@
       <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required.
       </p>
-      <p id="rfc.section.A.p.3">The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing
-         such headers, recognize a single LF as a line terminator and ignore the leading CR.
+      <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers,
+         recognize a single LF as a line terminator and ignore the leading CR.
       </p>
       <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling
@@ -2587 +2603 @@
       <p id="rfc.section.B.4.p.5">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>)
       </p>
-      <p id="rfc.section.B.4.p.6">Require that invalid whitespace around field-names be rejected. (<a href="#message.headers" title="Message Headers">Section&nbsp;3.2</a>)
+      <p id="rfc.section.B.4.p.6">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
       </p>
       <p id="rfc.section.B.4.p.7">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>)
@@ -2622 +2638 @@
       </dl>
       <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
-      <div id="rfc.figure.u.72"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
+      <div id="rfc.figure.u.71"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
 
 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
@@ -2640 +2656 @@
 <a href="#http.version" class="smpl">HTTP-Version</a> = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
 <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date
-<a href="#message.types" class="smpl">HTTP-message</a> = Request / Response
+<a href="#http.message" class="smpl">HTTP-message</a> = start-line *( header-field CRLF ) CRLF [
+ message-body ]
 <a href="#header.host" class="smpl">Host</a> = "Host:" OWS Host-v
 <a href="#header.host" class="smpl">Host-v</a> = uri-host [ ":" port ]
@@ -2721 +2738 @@
 <a href="#abnf.dependencies" class="smpl">entity-header</a> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
 
-<a href="#message.headers" class="smpl">field-content</a> = *( WSP / VCHAR / obs-text )
-<a href="#message.headers" class="smpl">field-name</a> = token
-<a href="#message.headers" class="smpl">field-value</a> = *( field-content / OWS )
+<a href="#header.fields" class="smpl">field-content</a> = *( WSP / VCHAR / obs-text )
+<a href="#header.fields" class="smpl">field-name</a> = token
+<a href="#header.fields" class="smpl">field-value</a> = *( field-content / OWS )
 <a href="#uri" class="smpl">fragment</a> = &lt;fragment, defined in [RFC3986], Section 3.5&gt;
 
 <a href="#general.header.fields" class="smpl">general-header</a> = Cache-Control / Connection / Date / Pragma / Trailer
  / Transfer-Encoding / Upgrade / Via / Warning
-<a href="#message.types" class="smpl">generic-message</a> = start-line *( message-header CRLF ) CRLF [
- message-body ]
 
 <a href="#preferred.date.format" class="smpl">hour</a> = 2DIGIT
@@ -2739 +2754 @@
 <a href="#message.body" class="smpl">message-body</a> = entity-body /
  &lt;entity-body encoded as per Transfer-Encoding&gt;
-<a href="#message.headers" class="smpl">message-header</a> = field-name ":" OWS [ field-value ] OWS
+<a href="#header.fields" class="smpl">header-field</a> = field-name ":" OWS [ field-value ] OWS
 <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT
 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan
@@ -2788 +2803 @@
 
 <a href="#preferred.date.format" class="smpl">second</a> = 2DIGIT
-<a href="#message.types" class="smpl">start-line</a> = Request-Line / Status-Line
+<a href="#http.message" class="smpl">start-line</a> = Request-Line / Status-Line
 
 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( transfer-extension [ te-params ] )
@@ -2807 +2822 @@
 
 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
-</pre> <div id="rfc.figure.u.73"></div>
+</pre> <div id="rfc.figure.u.72"></div>
       <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used
 ; Content-Length defined but not used
@@ -3051 +3066 @@
                         <li class="indline1"><tt>absolute-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>2.6</b></a></li>
                         <li class="indline1">ALPHA&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>asctime-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.71"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.75"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>asctime-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.69"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.73"><b>6.2</b></a></li>
                         <li class="indline1"><tt>authority</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>2.6</b></a></li>
                         <li class="indline1"><tt>BWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li>
-                        <li class="indline1"><tt>chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.80"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>chunk-data</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.86"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>chunk-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.83"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.84"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.85"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>chunk-size</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.81"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>Chunked-Body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.79"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>comment</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>3.2</b></a></li>
-                        <li class="indline1"><tt>Connection</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.91"><b>8.1</b></a></li>
-                        <li class="indline1"><tt>connection-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.93"><b>8.1</b></a></li>
-                        <li class="indline1"><tt>Connection-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.92"><b>8.1</b></a></li>
-                        <li class="indline1"><tt>Content-Length</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.94"><b>8.2</b></a></li>
-                        <li class="indline1"><tt>Content-Length-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.95"><b>8.2</b></a></li>
+                        <li class="indline1"><tt>chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.78"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>chunk-data</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.84"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>chunk-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.81"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.82"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.83"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>chunk-size</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.79"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>Chunked-Body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.77"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>comment</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>3.2</b></a></li>
+                        <li class="indline1"><tt>Connection</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.89"><b>8.1</b></a></li>
+                        <li class="indline1"><tt>connection-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.91"><b>8.1</b></a></li>
+                        <li class="indline1"><tt>Connection-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.90"><b>8.1</b></a></li>
+                        <li class="indline1"><tt>Content-Length</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.92"><b>8.2</b></a></li>
+                        <li class="indline1"><tt>Content-Length-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.93"><b>8.2</b></a></li>
                         <li class="indline1">CR&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li>
                         <li class="indline1">CRLF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>ctext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>3.2</b></a></li>
+                        <li class="indline1"><tt>ctext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>3.2</b></a></li>
                         <li class="indline1">CTL&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>Date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.96"><b>8.3</b></a></li>
-                        <li class="indline1"><tt>Date-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.97"><b>8.3</b></a></li>
-                        <li class="indline1"><tt>date1</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.58"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>date2</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.77"><b>6.2</b></a></li>
-                        <li class="indline1"><tt>date3</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.78"><b>6.2</b></a></li>
-                        <li class="indline1"><tt>day</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.65"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>day-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.63"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>day-name-l</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.64"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>Date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.94"><b>8.3</b></a></li>
+                        <li class="indline1"><tt>Date-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.95"><b>8.3</b></a></li>
+                        <li class="indline1"><tt>date1</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.56"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>date2</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.75"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>date3</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.76"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>day</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.63"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>day-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.61"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>day-name-l</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.62"><b>6.1</b></a></li>
                         <li class="indline1">DIGIT&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li>
                         <li class="indline1">DQUOTE&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>extension-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.54"><b>5.1.1</b></a></li>
-                        <li class="indline1"><tt>extension-method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.49"><b>4.1.1</b></a></li>
-                        <li class="indline1"><tt>field-content</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>3.2</b></a></li>
-                        <li class="indline1"><tt>field-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>3.2</b></a></li>
-                        <li class="indline1"><tt>field-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>3.2</b></a></li>
-                        <li class="indline1"><tt>general-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>3.5</b></a></li>
-                        <li class="indline1"><tt>generic-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>3.1</b></a></li>
-                        <li class="indline1"><tt>GMT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>extension-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.52"><b>5.1.1</b></a></li>
+                        <li class="indline1"><tt>extension-method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.47"><b>4.1.1</b></a></li>
+                        <li class="indline1"><tt>field-content</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>3.2</b></a></li>
+                        <li class="indline1"><tt>field-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>3.2</b></a></li>
+                        <li class="indline1"><tt>field-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>3.2</b></a></li>
+                        <li class="indline1"><tt>general-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>3.5</b></a></li>
+                        <li class="indline1"><tt>GMT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.66"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>header-field</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>3.2</b></a></li>
                         <li class="indline1">HEXDIG&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>Host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.98"><b>8.4</b></a></li>
-                        <li class="indline1"><tt>Host-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.99"><b>8.4</b></a></li>
-                        <li class="indline1"><tt>hour</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.60"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>HTTP-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.56"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>HTTP-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>3.1</b></a></li>
+                        <li class="indline1"><tt>Host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.96"><b>8.4</b></a></li>
+                        <li class="indline1"><tt>Host-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.97"><b>8.4</b></a></li>
+                        <li class="indline1"><tt>hour</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.58"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>HTTP-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.54"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>HTTP-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>3</b></a></li>
                         <li class="indline1"><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>2.5</b></a></li>
                         <li class="indline1"><tt>http-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>2.6.1</b></a></li>
                         <li class="indline1"><tt>HTTP-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>2.5</b></a></li>
                         <li class="indline1"><tt>https-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>2.6.2</b></a></li>
-                        <li class="indline1"><tt>last-chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.82"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>last-chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.80"><b>6.2.1</b></a></li>
                         <li class="indline1">LF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>message-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>3.3</b></a></li>
-                        <li class="indline1"><tt>message-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>3.2</b></a></li>
-                        <li class="indline1"><tt>Method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.48"><b>4.1.1</b></a></li>
-                        <li class="indline1"><tt>minute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.61"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>month</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.66"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>obs-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.69"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>message-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>3.3</b></a></li>
+                        <li class="indline1"><tt>Method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.46"><b>4.1.1</b></a></li>
+                        <li class="indline1"><tt>minute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.59"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>month</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.64"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>obs-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.67"><b>6.1</b></a></li>
                         <li class="indline1"><tt>obs-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li>
                         <li class="indline1">OCTET&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li>
@@ -3113 +3127 @@
                         <li class="indline1"><tt>path-absolute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>2.6</b></a></li>
                         <li class="indline1"><tt>port</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>2.6</b></a></li>
-                        <li class="indline1"><tt>product</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.88"><b>6.3</b></a></li>
-                        <li class="indline1"><tt>product-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.89"><b>6.3</b></a></li>
-                        <li class="indline1"><tt>protocol-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.114"><b>8.9</b></a></li>
-                        <li class="indline1"><tt>protocol-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.115"><b>8.9</b></a></li>
-                        <li class="indline1"><tt>pseudonym</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.117"><b>8.9</b></a></li>
+                        <li class="indline1"><tt>product</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.86"><b>6.3</b></a></li>
+                        <li class="indline1"><tt>product-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.87"><b>6.3</b></a></li>
+                        <li class="indline1"><tt>protocol-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.112"><b>8.9</b></a></li>
+                        <li class="indline1"><tt>protocol-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.113"><b>8.9</b></a></li>
+                        <li class="indline1"><tt>pseudonym</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.115"><b>8.9</b></a></li>
                         <li class="indline1"><tt>qdtext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li>
                         <li class="indline1"><tt>query</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>2.6</b></a></li>
@@ -3123 +3137 @@
                         <li class="indline1"><tt>quoted-string</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li>
                         <li class="indline1"><tt>quoted-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li>
-                        <li class="indline1"><tt>qvalue</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.90"><b>6.4</b></a></li>
-                        <li class="indline1"><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.55"><b>5.1.1</b></a></li>
-                        <li class="indline1"><tt>received-by</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.116"><b>8.9</b></a></li>
-                        <li class="indline1"><tt>received-protocol</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.113"><b>8.9</b></a></li>
-                        <li class="indline1"><tt>Request</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.46"><b>4</b></a></li>
-                        <li class="indline1"><tt>Request-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.47"><b>4.1</b></a></li>
-                        <li class="indline1"><tt>request-target</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.50"><b>4.1.2</b></a></li>
-                        <li class="indline1"><tt>Response</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.51"><b>5</b></a></li>
-                        <li class="indline1"><tt>rfc1123-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.57"><b>6.1</b></a></li>
-                        <li class="indline1"><tt>rfc850-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.70"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>qvalue</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.88"><b>6.4</b></a></li>
+                        <li class="indline1"><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.53"><b>5.1.1</b></a></li>
+                        <li class="indline1"><tt>received-by</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.114"><b>8.9</b></a></li>
+                        <li class="indline1"><tt>received-protocol</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.111"><b>8.9</b></a></li>
+                        <li class="indline1"><tt>Request</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>4</b></a></li>
+                        <li class="indline1"><tt>Request-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>4.1</b></a></li>
+                        <li class="indline1"><tt>request-target</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.48"><b>4.1.2</b></a></li>
+                        <li class="indline1"><tt>Response</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.49"><b>5</b></a></li>
+                        <li class="indline1"><tt>rfc1123-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.55"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>rfc850-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li>
                         <li class="indline1"><tt>RWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li>
-                        <li class="indline1"><tt>second</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.62"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>second</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.60"><b>6.1</b></a></li>
                         <li class="indline1">SP&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>start-line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>3.1</b></a></li>
-                        <li class="indline1"><tt>Status-Code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.53"><b>5.1.1</b></a></li>
-                        <li class="indline1"><tt>Status-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.52"><b>5.1</b></a></li>
-                        <li class="indline1"><tt>t-codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.102"><b>8.5</b></a></li>
+                        <li class="indline1"><tt>Status-Code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.51"><b>5.1.1</b></a></li>
+                        <li class="indline1"><tt>Status-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.50"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>t-codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.100"><b>8.5</b></a></li>
                         <li class="indline1"><tt>tchar</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li>
-                        <li class="indline1"><tt>TE</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.100"><b>8.5</b></a></li>
-                        <li class="indline1"><tt>te-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.104"><b>8.5</b></a></li>
-                        <li class="indline1"><tt>te-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.103"><b>8.5</b></a></li>
-                        <li class="indline1"><tt>TE-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.101"><b>8.5</b></a></li>
-                        <li class="indline1"><tt>time-of-day</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.59"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>TE</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.98"><b>8.5</b></a></li>
+                        <li class="indline1"><tt>te-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.102"><b>8.5</b></a></li>
+                        <li class="indline1"><tt>te-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.101"><b>8.5</b></a></li>
+                        <li class="indline1"><tt>TE-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.99"><b>8.5</b></a></li>
+                        <li class="indline1"><tt>time-of-day</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.57"><b>6.1</b></a></li>
                         <li class="indline1"><tt>token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li>
-                        <li class="indline1"><tt>Trailer</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.105"><b>8.6</b></a></li>
-                        <li class="indline1"><tt>trailer-part</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.87"><b>6.2.1</b></a></li>
-                        <li class="indline1"><tt>Trailer-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.106"><b>8.6</b></a></li>
-                        <li class="indline1"><tt>transfer-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.72"><b>6.2</b></a></li>
-                        <li class="indline1"><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.107"><b>8.7</b></a></li>
-                        <li class="indline1"><tt>Transfer-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.108"><b>8.7</b></a></li>
-                        <li class="indline1"><tt>transfer-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.73"><b>6.2</b></a></li>
-                        <li class="indline1"><tt>transfer-parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.74"><b>6.2</b></a></li>
-                        <li class="indline1"><tt>Upgrade</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.109"><b>8.8</b></a></li>
-                        <li class="indline1"><tt>Upgrade-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.110"><b>8.8</b></a></li>
+                        <li class="indline1"><tt>Trailer</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.103"><b>8.6</b></a></li>
+                        <li class="indline1"><tt>trailer-part</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.85"><b>6.2.1</b></a></li>
+                        <li class="indline1"><tt>Trailer-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.104"><b>8.6</b></a></li>
+                        <li class="indline1"><tt>transfer-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.70"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.105"><b>8.7</b></a></li>
+                        <li class="indline1"><tt>Transfer-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.106"><b>8.7</b></a></li>
+                        <li class="indline1"><tt>transfer-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.71"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>transfer-parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.72"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>Upgrade</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.107"><b>8.8</b></a></li>
+                        <li class="indline1"><tt>Upgrade-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.108"><b>8.8</b></a></li>
                         <li class="indline1"><tt>uri-host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>2.6</b></a></li>
                         <li class="indline1"><tt>URI-reference</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>2.6</b></a></li>
-                        <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.76"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.74"><b>6.2</b></a></li>
                         <li class="indline1">VCHAR&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>Via</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.111"><b>8.9</b></a></li>
-                        <li class="indline1"><tt>Via-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.112"><b>8.9</b></a></li>
+                        <li class="indline1"><tt>Via</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.109"><b>8.9</b></a></li>
+                        <li class="indline1"><tt>Via-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.110"><b>8.9</b></a></li>
                         <li class="indline1">WSP&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>1.2</b></a></li>
-                        <li class="indline1"><tt>year</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.67"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>year</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.65"><b>6.1</b></a></li>
                      </ul>
                   </li>
@@ -3170 +3183 @@
             </li>
             <li class="indline0"><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul class="ind">
+                  <li class="indline1">header field&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.5">3</a></li>
+                  <li class="indline1">header section&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.3">3</a></li>
+                  <li class="indline1">headers&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.4">3</a></li>
                   <li class="indline1">Headers&nbsp;&nbsp;
                      <ul class="ind">
-                        <li class="indline1">Connection&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.iref.h.3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">8.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">8.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li>
-                        <li class="indline1">Content-Length&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h.4"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">9.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>
-                        <li class="indline1">Date&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>8.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">9.1</a></li>
-                        <li class="indline1">Host&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.7"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>
-                        <li class="indline1">TE&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.h.8"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">9.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li>
-                        <li class="indline1">Trailer&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li>
-                        <li class="indline1">Transfer-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.5</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.h.10"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li>
-                        <li class="indline1">Upgrade&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.5</a>, <a class="iref" href="#rfc.iref.h.11"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">9.1</a></li>
-                        <li class="indline1">Via&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.via.1">3.5</a>, <a class="iref" href="#rfc.iref.h.12"><b>8.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">9.1</a></li>
+                        <li class="indline1">Connection&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.iref.h.6"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">8.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">8.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li>
+                        <li class="indline1">Content-Length&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h.7"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">9.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>
+                        <li class="indline1">Date&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h.8"><b>8.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">9.1</a></li>
+                        <li class="indline1">Host&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.10"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>
+                        <li class="indline1">TE&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.h.11"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">9.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li>
+                        <li class="indline1">Trailer&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h.12"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li>
+                        <li class="indline1">Transfer-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.5</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.h.13"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li>
+                        <li class="indline1">Upgrade&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.5</a>, <a class="iref" href="#rfc.iref.h.14"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">9.1</a></li>
+                        <li class="indline1">Via&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.via.1">3.5</a>, <a class="iref" href="#rfc.iref.h.15"><b>8.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">9.1</a></li>
                      </ul>
                   </li>
-                  <li class="indline1">Host header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.6"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>
+                  <li class="indline1">Host header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.9"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>
                   <li class="indline1">http URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.1"><b>2.6.1</b></a></li>
                   <li class="indline1">https URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.2">2.6.2</a></li>
@@ -3243 +3259 @@
                   <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#Part5"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">B.3</a></li>
                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.5</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">B.3</a><ul class="ind">
-                        <li class="indline1"><em>Section 1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">2.3</a></li>
+                        <li class="indline1"><em>Section 2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">2.3</a></li>
                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">3.5</a></li>
                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a></li>
@@ -3262 +3278 @@
                   <li class="indline1"><em>RFC1900</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1900.1">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li>
                   <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>
-                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">6.2</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.2</b></a></li>
+                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">6.2</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.2</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2045.2">6.2</a></li>
+                     </ul>
+                  </li>
                   <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">3.2</a>, <a class="iref" href="#RFC2047"><b>12.2</b></a></li>
                   <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">2.5</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">11</a>, <a class="iref" href="#RFC2068"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.5">B</a>, <a class="iref" href="#rfc.xref.RFC2068.6">B.2</a><ul class="ind">
@@ -3296 +3315 @@
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">3.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">3.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">6.1</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.6">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.3">3.2</a></li>
-                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.4">6.1</a></li>
-                        <li class="indline1"><em>Section 3.6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.5">8.3</a></li>
-                        <li class="indline1"><em>Section 3.6.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.6">8.9</a></li>
+                  <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">3</a>, <a class="iref" href="#rfc.xref.RFC5322.3">6.1</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.3">6.1</a></li>
+                        <li class="indline1"><em>Section 3.6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.4">8.3</a></li>
+                        <li class="indline1"><em>Section 3.6.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.5">8.9</a></li>
                      </ul>
                   </li>

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

@@ -427 +427 @@
                  ; "bad" whitespace
   <x:ref>obs-fold</x:ref>       = <x:ref>CRLF</x:ref>
-                 ; see <xref target="message.headers"/>
+                 ; see <xref target="header.fields"/>
 </artwork></figure>
 <t anchor="rule.token.separators">
@@ -1019 +1019 @@
 
 <section title="HTTP Message" anchor="http.message">
-
-<section title="Message Types" anchor="message.types">
-  <x:anchor-alias value="generic-message"/>
-  <x:anchor-alias value="HTTP-message"/>
-  <x:anchor-alias value="start-line"/>
-<t>
-   HTTP messages consist of requests from client to server and responses
-   from server to client.
+<x:anchor-alias value="generic-message"/>
+<x:anchor-alias value="message.types"/>
+<x:anchor-alias value="HTTP-message"/>
+<x:anchor-alias value="start-line"/>
+<iref item="header section"/>
+<iref item="headers"/>
+<iref item="header field"/>
+<t>
+   All HTTP/1.1 messages consist of a start-line followed by a sequence of
+   characters in a format similar to the Internet Message Format
+   <xref target="RFC5322"/>: zero or more header fields (collectively
+   referred to as the "headers" or the "header section"), an empty line
+   indicating the end of the header section, and an optional message-body.
+</t>
+<t>
+   An HTTP message can either be a request from client to server or a
+   response from server to client.  Syntactically, the two types of message
+   differ only in the start-line, which is either a Request-Line (for requests)
+   or a Status-Line (for responses), and in the algorithm for determining
+   the length of the message-body (<xref target="message.length"/>).
+   In theory, a client could receive requests and a server could receive
+   responses, distinguishing them by their different start-line formats,
+   but in practice servers are implemented to only expect a request
+   (a response is interpreted as an unknown or invalid request method)
+   and clients are implemented to only expect a response.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
-  <x:ref>HTTP-message</x:ref>   = <x:ref>Request</x:ref> / <x:ref>Response</x:ref>     ; HTTP/1.1 messages
-</artwork></figure>
-<t>
-   Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic
-   message format of <xref target="RFC5322"/> for transferring entities (the payload
-   of the message). Both types of message consist of a start-line, zero
-   or more header fields (also known as "headers"), an empty line (i.e.,
-   a line with nothing preceding the CRLF) indicating the end of the
-   header fields, and possibly a message-body.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="generic-message"/><iref primary="true" item="Grammar" subitem="start-line"/>
-  <x:ref>generic-message</x:ref> = <x:ref>start-line</x:ref>
-                    *( <x:ref>message-header</x:ref> <x:ref>CRLF</x:ref> )
+  <x:ref>HTTP-message</x:ref>    = <x:ref>start-line</x:ref>
+                    *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
                     <x:ref>CRLF</x:ref>
                     [ <x:ref>message-body</x:ref> ]
   <x:ref>start-line</x:ref>      = <x:ref>Request-Line</x:ref> / <x:ref>Status-Line</x:ref>
 </artwork></figure>
-<t>
-   In the interest of robustness, servers &SHOULD; ignore any empty
-   line(s) received where a Request-Line is expected. In other words, if
-   the server is reading the protocol stream at the beginning of a
-   message and receives a CRLF first, it should ignore the CRLF.
-</t>
-<t>
-   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
-   after a POST request. To restate what is explicitly forbidden by the
-   BNF, an HTTP/1.1 client &MUST-NOT; preface or follow a request with an
-   extra CRLF.
-</t>
 <t>
    Whitespace (WSP) &MUST-NOT; be sent between the start-line and the first
@@ -1067 +1061 @@
    with a 400 (Bad Request) response.
 </t>
-</section>
-
-<section title="Message Headers" anchor="message.headers">
+
+<section title="Message Parsing Robustness" anchor="message.robustness">
+<t>
+   In the interest of robustness, servers &SHOULD; ignore at least one
+   empty line received where a Request-Line is expected. In other words, if
+   the server is reading the protocol stream at the beginning of a
+   message and receives a CRLF first, it should ignore the CRLF.
+</t>
+<t>
+   Some old HTTP/1.0 client implementations generate an extra CRLF
+   after a POST request as a lame workaround for some early server
+   applications that failed to read message-body content that was
+   not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
+   preface or follow a request with an extra CRLF.  If terminating
+   the request message-body with a line-ending is desired, then the
+   client &MUST; include the terminating CRLF octets as part of the
+   message-body length. 
+</t>
+<t>
+   The normal procedure for parsing an HTTP message is to read the
+   start-line into a structure, read each header field into a hash
+   table by field name until the empty line, and then use the parsed
+   data to determine if a message-body is expected.  If a message-body
+   has been indicated, then it is read as a stream until an amount
+   of OCTETs equal to the message-length is read or the connection
+   is closed.  Care must be taken to parse an HTTP message as a sequence
+   of OCTETs in an encoding that is a superset of US-ASCII.  Attempting
+   to parse HTTP as a stream of Unicode characters in a character encoding
+   like UTF-16 may introduce security flaws due to the differing ways
+   that such parsers interpret invalid characters.
+</t>
+</section>
+
+<section title="Header Fields" anchor="header.fields">
+  <x:anchor-alias value="header-field"/>
   <x:anchor-alias value="field-content"/>
   <x:anchor-alias value="field-name"/>
   <x:anchor-alias value="field-value"/>
-  <x:anchor-alias value="message-header"/>
-<t>
-   HTTP header fields follow the same general format as Internet messages in
-   <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists
-   of a name followed by a colon (":"), optional whitespace, and the field
-   value. Field names are case-insensitive.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/>
-  <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" OWS [ <x:ref>field-value</x:ref> ] OWS
+  <x:anchor-alias value="OWS"/>
+<t>
+   Each HTTP header field consists of a case-insensitive field name
+   followed by a colon (":"), optional whitespace, and the field value.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="header-field"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/>
+  <x:ref>header-field</x:ref>   = <x:ref>field-name</x:ref> ":" OWS [ <x:ref>field-value</x:ref> ] OWS
   <x:ref>field-name</x:ref>     = <x:ref>token</x:ref>
   <x:ref>field-value</x:ref>    = *( <x:ref>field-content</x:ref> / <x:ref>OWS</x:ref> )
@@ -1087 +1111 @@
 </artwork></figure>
 <t>
-   Historically, HTTP has allowed field-content with text in the ISO-8859-1
-   <xref target="ISO-8859-1"/> character encoding (allowing other character sets
-   through use of <xref target="RFC2047"/> encoding). In practice, most HTTP
-   header field-values use only a subset of the US-ASCII charset
-   <xref target="USASCII"/>. Newly defined header fields &SHOULD; constrain
-   their field-values to US-ASCII characters. Recipients &SHOULD; treat other
-   (obs-text) octets in field-content as opaque data.
-</t>
-<t>
-   No whitespace is allowed between the header field-name and colon. For
+   No whitespace is allowed between the header field name and colon. For
    security reasons, any request message received containing such whitespace
-   &MUST; be rejected with a response code of 400 (Bad Request) and any such
-   whitespace in a response message &MUST; be removed.
-</t>
-<t>
-   The field value &MAY; be preceded by optional whitespace; a single SP is
-   preferred. The field-value does not include any leading or trailing white
+   &MUST; be rejected with a response code of 400 (Bad Request). A proxy
+   &MUST; remove any such whitespace from a response message before
+   forwarding the message downstream.
+</t>
+<t>
+   A field value &MAY; be preceded by optional whitespace (OWS); a single SP is
+   preferred. The field value does not include any leading or trailing white
    space: OWS occurring before the first non-whitespace character of the
-   field-value or after the last non-whitespace character of the field-value
-   is ignored and &MAY; be removed without changing the meaning of the header
+   field value or after the last non-whitespace character of the field value
+   is ignored and &SHOULD; be removed without changing the meaning of the header
    field.
 </t>
+<t>
+   The order in which header fields with differing field names are
+   received is not significant. However, it is "good practice" to send
+   header fields that contain control data first, such as Host on
+   requests and Date on responses, so that implementations can decide
+   when not to handle a message as early as possible.  A server &MUST;
+   wait until the entire header section is received before interpreting
+   a request message, since later header fields might include conditionals,
+   authentication credentials, or deliberately misleading duplicate
+   header fields that would impact request processing.
+</t>
+<t>
+   Multiple header fields with the same field name &MAY; be
+   sent in a message if and only if the entire field value for that
+   header field is defined as a comma-separated list [i.e., #(values)].
+   Multiple header fields with the same field name can be combined into
+   one "field-name: field-value" pair, without changing the semantics of the
+   message, by appending each subsequent field value to the combined
+   field value in order, separated by a comma. The order in which
+   header fields with the same field name are received is therefore
+   significant to the interpretation of the combined field value;
+   a proxy &MUST-NOT; change the order of these field values when
+   forwarding a message.
+</t>
+<x:note>
+  <t>
+   <x:h>Note:</x:h> the "Set-Cookie" header as implemented in
+   practice (as opposed to how it is specified in <xref target="RFC2109"/>)
+   can occur multiple times, but does not use the list syntax, and thus cannot
+   be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/>
+   for details.) Also note that the Set-Cookie2 header specified in
+   <xref target="RFC2965"/> does not share this problem. 
+  </t>
+</x:note>
 <t>
    Historically, HTTP header field values could be extended over multiple
@@ -1122 +1172 @@
    or forwarding the message downstream.
 </t>
+<t>
+   Historically, HTTP has allowed field content with text in the ISO-8859-1
+   <xref target="ISO-8859-1"/> character encoding and supported other
+   character sets only through use of <xref target="RFC2047"/> encoding.
+   In practice, most HTTP header field values use only a subset of the
+   US-ASCII character encoding <xref target="USASCII"/>. Newly defined
+   header fields &SHOULD; limit their field values to US-ASCII characters.
+   Recipients &SHOULD; treat other (obs-text) octets in field content as
+   opaque data.
+</t>
 <t anchor="rule.comment">
   <x:anchor-alias value="comment"/>
@@ -1128 +1188 @@
    the comment text with parentheses. Comments are only allowed in
    fields containing "comment" as part of their field value definition.
-   In all other fields, parentheses are considered part of the field
-   value.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>
@@ -1136 +1194 @@
                  ; <x:ref>OWS</x:ref> / &lt;<x:ref>VCHAR</x:ref> except "(", ")", and "\"&gt; / <x:ref>obs-text</x:ref>
 </artwork></figure>
-<t>
-   The order in which header fields with differing field names are
-   received is not significant. However, it is "good practice" to send
-   general-header fields first, followed by request-header or response-header
-   fields, and ending with the entity-header fields.
-</t>
-<t>
-   Multiple message-header fields with the same field-name &MAY; be
-   present in a message if and only if the entire field-value for that
-   header field is defined as a comma-separated list [i.e., #(values)].
-   It &MUST; be possible to combine the multiple header fields into one
-   "field-name: field-value" pair, without changing the semantics of the
-   message, by appending each subsequent field-value to the first, each
-   separated by a comma. The order in which header fields with the same
-   field-name are received is therefore significant to the
-   interpretation of the combined field value, and thus a proxy &MUST-NOT;
-   change the order of these field values when a message is forwarded.
-</t>
-<x:note>
-  <t>
-   <x:h>Note:</x:h> the "Set-Cookie" header as implemented in
-   practice (as opposed to how it is specified in <xref target="RFC2109"/>)
-   can occur multiple times, but does not use the list syntax, and thus cannot
-   be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/>
-   for details.) Also note that the Set-Cookie2 header specified in
-   <xref target="RFC2965"/> does not share this problem. 
-  </t>
-</x:note>
   
 </section>
@@ -1194 +1224 @@
    The presence of a message-body in a request is signaled by the
    inclusion of a Content-Length or Transfer-Encoding header field in
-   the request's message-headers. 
+   the request's header fields. 
    When a request message contains both a message-body of non-zero
    length and a method that does not define any semantics for that
@@ -2371 +2401 @@
 
 
-<section title="Header Field Definitions" anchor="header.fields">
+<section title="Header Field Definitions" anchor="header.field.definitions">
 <t>
    This section defines the syntax and semantics of HTTP/1.1 header fields
@@ -4059 +4089 @@
 </t>
 <t>
-   The line terminator for message-header fields is the sequence CRLF.
+   The line terminator for header fields is the sequence CRLF.
    However, we recommend that applications, when parsing such headers,
    recognize a single LF as a line terminator and ignore the leading CR.
@@ -4297 +4327 @@
 <t>
   Require that invalid whitespace around field-names be rejected.
-  (<xref target="message.headers"/>)
+  (<xref target="header.fields"/>)
 </t>
 <t>
@@ -4387 +4417 @@
 <x:ref>HTTP-Version</x:ref> = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
 <x:ref>HTTP-date</x:ref> = rfc1123-date / obs-date
-<x:ref>HTTP-message</x:ref> = Request / Response
+<x:ref>HTTP-message</x:ref> = start-line *( header-field CRLF ) CRLF [
+ message-body ]
 <x:ref>Host</x:ref> = "Host:" OWS Host-v
 <x:ref>Host-v</x:ref> = uri-host [ ":" port ]
@@ -4475 +4506 @@
 <x:ref>general-header</x:ref> = Cache-Control / Connection / Date / Pragma / Trailer
  / Transfer-Encoding / Upgrade / Via / Warning
-<x:ref>generic-message</x:ref> = start-line *( message-header CRLF ) CRLF [
- message-body ]
 
 <x:ref>hour</x:ref> = 2DIGIT
@@ -4486 +4515 @@
 <x:ref>message-body</x:ref> = entity-body /
  &lt;entity-body encoded as per Transfer-Encoding&gt;
-<x:ref>message-header</x:ref> = field-name ":" OWS [ field-value ] OWS
+<x:ref>header-field</x:ref> = field-name ":" OWS [ field-value ] OWS
 <x:ref>minute</x:ref> = 2DIGIT
 <x:ref>month</x:ref> = %x4A.61.6E ; Jan

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

@@ -471 +471 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">July 27, 2009</td>
+            <td class="header right">July 28, 2009</td>
          </tr>
       </table>
@@ -1544 +1544 @@
          </p> 
       </div>
-      <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p>
+      <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p>
       <ul>
-         <li>With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.</li>
+         <li>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</li>
          <li>With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment
             characteristics.

draft-ietf-httpbis/latest/p3-payload.html

@@ -478 +478 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">July 27, 2009</td>
+            <td class="header right">July 28, 2009</td>
          </tr>
       </table>
@@ -655 +655 @@
 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
       <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p>
-      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>   = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.3</a>&gt;
+      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>   = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
   <a href="#abnf.dependencies" class="smpl">Content-Length</a> = &lt;Content-Length, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a>&gt;
-  <a href="#abnf.dependencies" class="smpl">message-header</a> = &lt;message-header, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 3.2</a>&gt;
-  <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.3</a>&gt;
+  <a href="#abnf.dependencies" class="smpl">header-field</a>   = &lt;header-field, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
+  <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
   <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a>&gt;
 </pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Last-Modified</a>  = &lt;Last-Modified, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a>&gt;
@@ -847 +847 @@
                  / <a href="#entity.header.fields" class="smpl">extension-header</a>
   
-  <a href="#entity.header.fields" class="smpl">extension-header</a> = <a href="#abnf.dependencies" class="smpl">message-header</a>
+  <a href="#entity.header.fields" class="smpl">extension-header</a> = <a href="#abnf.dependencies" class="smpl">header-field</a>
 </pre><p id="rfc.section.3.1.p.3">The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these
          fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies.
@@ -1788 +1788 @@
  / Content-Location / Content-MD5 / Content-Range / Content-Type /
  Expires / Last-Modified / extension-header
-<a href="#entity.header.fields" class="smpl">extension-header</a> = message-header
+<a href="#entity.header.fields" class="smpl">extension-header</a> = header-field
 
 <a href="#content-disposition" class="smpl">filename-parm</a> = "filename=" quoted-string
@@ -1798 +1798 @@
  ";" OWS parameter )
 <a href="#media.types" class="smpl">media-type</a> = type "/" subtype *( OWS ";" OWS parameter )
-<a href="#abnf.dependencies" class="smpl">message-header</a> = &lt;message-header, defined in [Part1], Section 3.2&gt;
+<a href="#abnf.dependencies" class="smpl">header-field</a> = &lt;header-field, defined in [Part1], Section 3.2&gt;
 
 <a href="#rule.parameter" class="smpl">parameter</a> = attribute "=" value
@@ -2061 +2061 @@
                         <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.2</a></li>
                         <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a></li>
-                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a></li>
+                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a></li>
                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.2.2</a></li>
                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">3.2</a></li>

draft-ietf-httpbis/latest/p3-payload.xml

@@ -28 +28 @@
   <!ENTITY message-body             "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY message-length           "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY message-headers          "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY header-fields            "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY multipart-byteranges     "<xref target='Part5' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY full-date                "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -300 +300 @@
   <x:anchor-alias value="Expires"/>
   <x:anchor-alias value="Last-Modified"/>
-  <x:anchor-alias value="message-header"/>
+  <x:anchor-alias value="header-field"/>
   <x:anchor-alias value="partial-URI"/>
   <x:anchor-alias value="qvalue"/>
@@ -309 +309 @@
   <x:ref>absolute-URI</x:ref>   = &lt;absolute-URI, defined in &uri;&gt;
   <x:ref>Content-Length</x:ref> = &lt;Content-Length, defined in &header-content-length;&gt;
-  <x:ref>message-header</x:ref> = &lt;message-header, defined in &message-headers;&gt;
+  <x:ref>header-field</x:ref>   = &lt;header-field, defined in &header-fields;&gt;
   <x:ref>partial-URI</x:ref>    = &lt;partial-URI, defined in &uri;&gt;
   <x:ref>qvalue</x:ref>         = &lt;qvalue, defined in &qvalue;&gt;
@@ -679 +679 @@
                  / <x:ref>extension-header</x:ref>
   
-  <x:ref>extension-header</x:ref> = <x:ref>message-header</x:ref>
+  <x:ref>extension-header</x:ref> = <x:ref>header-field</x:ref>
 </artwork></figure>
 <t>
@@ -2729 +2729 @@
  / Content-Location / Content-MD5 / Content-Range / Content-Type /
  Expires / Last-Modified / extension-header
-<x:ref>extension-header</x:ref> = message-header
+<x:ref>extension-header</x:ref> = header-field
 
 <x:ref>filename-parm</x:ref> = "filename=" quoted-string
@@ -2739 +2739 @@
  ";" OWS parameter )
 <x:ref>media-type</x:ref> = type "/" subtype *( OWS ";" OWS parameter )
-<x:ref>message-header</x:ref> = &lt;message-header, defined in [Part1], Section 3.2&gt;
+<x:ref>header-field</x:ref> = &lt;header-field, defined in [Part1], Section 3.2&gt;
 
 <x:ref>parameter</x:ref> = attribute "=" value

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

@@ -1148 +1148 @@
 <a href="#header.content-range" class="smpl">other-content-range-spec</a> = other-range-unit SP other-range-resp-spec
 <a href="#header.content-range" class="smpl">other-range-resp-spec</a> = *CHAR
+<a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*CHAR
 <a href="#range.units" class="smpl">other-range-unit</a> = token
-<a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = 1*CHAR
+<a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = other-range-unit "=" other-range-set
 
 <a href="#range.units" class="smpl">range-unit</a> = bytes-unit / other-range-unit

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

@@ -473 +473 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">July 27, 2009</td>
+            <td class="header right">July 28, 2009</td>
          </tr>
       </table>
@@ -692 +692 @@
 </pre><h3 id="rfc.section.1.4.2"><a href="#rfc.section.1.4.2">1.4.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
       <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p>
-      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 3.2</a>&gt;
+      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
   <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
-  <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.3</a>&gt;
+  <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
   <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a>&gt; 
-  <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.3</a>&gt;
+  <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Cache Operation</a></h1>
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>
@@ -923 +923 @@
       <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
-         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
+         name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
       </p>
       <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p>
@@ -1868 +1868 @@
                         <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a></li>
                         <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a></li>
-                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li>
+                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li>
                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a></li>
                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a></li>

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

@@ -29 +29 @@
   <!ENTITY header-via                  "<xref target='Part1' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY header-last-modified        "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY message-headers             "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY header-fields             "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY message-length              "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY safe-methods                "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -406 +406 @@
 </t>
 <figure><!--Part1--><artwork type="abnf2616">
-  <x:ref>field-name</x:ref>    = &lt;field-name, defined in &message-headers;&gt;
+  <x:ref>field-name</x:ref>    = &lt;field-name, defined in &header-fields;&gt;
   <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &full-date;&gt;
   <x:ref>port</x:ref>          = &lt;port, defined in &uri;&gt;
@@ -823 +823 @@
   <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
   combining multiple message-header fields with the same field name following the rules
-  about message headers in &message-headers;.
+  about header fields in &header-fields;.
 </t>
 <t>