Changeset 2380 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

13/09/13 09:05:47 (8 years ago)

Author:

fielding@…

Message:

Remove the Expect extension mechanism to focus on the definition of 100-continue; allow proxies to generate 100 on behalf of inbound HTTP/1.0 servers; addresses #458 and #468

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (79 diffs)

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

@@ -446 +446 @@
   }
   @bottom-center {
-       content: "Expires March 16, 2014";
+       content: "Expires March 17, 2014";
   }
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-09-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-09-13">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
@@ -519 +519 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">September 12, 2013</td>
+               <td class="right">September 13, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: March 16, 2014</td>
+               <td class="left">Expires: March 17, 2014</td>
                <td class="right"></td>
             </tr>
@@ -550 +550 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 16, 2014.</p>
+      <p>This Internet-Draft will expire on March 17, 2014.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -633 +633 @@
          <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#request.header.fields">Request Header Fields</a><ul>
                <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.controls">Controls</a><ul>
-                     <li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a><ul>
-                           <li><a href="#rfc.section.5.1.1.1">5.1.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#expect-100-continue">100-continue Expectation</a></li>
-                        </ul>
-                     </li>
+                     <li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li>
                      <li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li>
                   </ul>
@@ -1675 +1672 @@
       </div>
       <div id="rfc.iref.e.1"></div>
+      <div id="rfc.iref.40"></div>
       <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h3>
-      <p id="rfc.section.5.1.1.p.1">The "Expect" header field in a request indicates that a certain set of behaviors (expectations) need to be supported by all
-         inbound servers in order to properly handle this request. A server that does not understand, or cannot comply with, one or
-         more of the received expectations <em class="bcp14">MUST</em> respond with an appropriate <a href="#status.4xx" class="smpl">4xx</a> status code, indicating either <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or some other error status that was determined prior to evaluating Expect.
-      </p>
-      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a>
-  
-  <a href="#header.expect" class="smpl">expectation</a>  = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#imported.abnf" class="smpl">BWS</a> "=" <a href="#imported.abnf" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ]
-                             *( <a href="#imported.abnf" class="smpl">OWS</a> ";" [ <a href="#imported.abnf" class="smpl">OWS</a> <a href="#header.expect" class="smpl">expect-param</a> ] )
-  <a href="#header.expect" class="smpl">expect-param</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#imported.abnf" class="smpl">BWS</a> "=" <a href="#imported.abnf" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ]
-  
-  <a href="#header.expect" class="smpl">expect-name</a>  = <a href="#imported.abnf" class="smpl">token</a>
-  <a href="#header.expect" class="smpl">expect-value</a> = <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a>
-</pre><p id="rfc.section.5.1.1.p.3">Comparison is case-insensitive for names (expect-name) and case-sensitive for values (expect-value).</p>
-      <p id="rfc.section.5.1.1.p.4">An intermediary forwarding a request <em class="bcp14">MUST</em> forward a received Expect header field unless one of the expectations requires otherwise.
-      </p>
-      <p id="rfc.section.5.1.1.p.5">The Expect header field was added after the original publication of HTTP/1.1 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and was not implemented by many of the initial implementations. We are hoping that those implementations have long since been
-         replaced. However, it remains unlikely that any implementation sending HTTP/1.0 messages will have implemented this field.
-         A server that receives an Expect header field in an HTTP/1.0 request <em class="bcp14">MUST</em> respond with <a href="#status.417" class="smpl">417 (Expectation Failed)</a>, since this would indicate that the message has been forwarded through an HTTP/1.0 intermediary that does not support Expect
-         and won't be able to support any expectation.
-      </p>
-      <div id="rfc.iref.45"></div>
-      <div id="rfc.iref.e.2"></div>
-      <h4 id="rfc.section.5.1.1.1"><a href="#rfc.section.5.1.1.1">5.1.1.1</a>&nbsp;<a id="expect-100-continue" href="#expect-100-continue">100-continue Expectation</a></h4>
-      <p id="rfc.section.5.1.1.1.p.1">The <dfn>100-continue</dfn> expectation informs recipients that the client is about to send a (presumably large) payload in this request and wishes to
-         receive a <a href="#status.100" class="smpl">100 (Continue)</a> interim response if the request-line and header fields are not sufficient to cause an immediate success, redirect, or error
-         response. This allows the client to wait for an indication that it is worthwhile to send the payload body before actually
-         doing so, which can improve efficiency when the payload body is huge or when the client anticipates that an error is likely
+      <p id="rfc.section.5.1.1.p.1">The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the
+         server in order to properly handle this request. The only such expectation defined by this specification is <a href="#header.expect" class="smpl">100-continue</a>.
+      </p>
+      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.17"></span>  <a href="#header.expect" class="smpl">Expect</a>  = "100-continue"
+</pre><p id="rfc.section.5.1.1.p.3">The Expect field-value is case-insensitive.</p>
+      <p id="rfc.section.5.1.1.p.4">A server that receives an Expect field-value other than <a href="#header.expect" class="smpl">100-continue</a> <em class="bcp14">MAY</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code to indicate that the unexpected expectation cannot be met.
+      </p>
+      <p id="rfc.section.5.1.1.p.5">A <dfn>100-continue</dfn> expectation informs recipients that the client is about to send a (presumably large) message body in this request and wishes
+         to receive a <a href="#status.100" class="smpl">100 (Continue)</a> interim response if the request-line and header fields are not sufficient to cause an immediate success, redirect, or error
+         response. This allows the client to wait for an indication that it is worthwhile to send the message body before actually
+         doing so, which can improve efficiency when the message body is huge or when the client anticipates that an error is likely
          (e.g., when sending a state-changing method, for the first time, without previously verified authentication credentials).
       </p>
-      <p id="rfc.section.5.1.1.1.p.2">Requirements for clients: </p>
+      <p id="rfc.section.5.1.1.p.6">For example, a request that begins with</p>
+      <div id="rfc.figure.u.21"></div><pre class="text2">PUT /somewhere/fun HTTP/1.1
+Host: origin.example.com
+Content-Type: video/h264
+Content-Length: 1234567890987
+Expect: 100-continue
+
+</pre><p id="rfc.section.5.1.1.p.8">allows the origin server to immediately respond with an error message, such as <a href="p7-auth.html#status.401" class="smpl">401 (Unauthorized)</a> or <a href="#status.405" class="smpl">405 (Method Not Allowed)</a>, before the client starts filling the pipes with an unnecessary data transfer.
+      </p>
+      <p id="rfc.section.5.1.1.p.9">Requirements for clients: </p>
       <ul>
-         <li>A client <em class="bcp14">MUST NOT</em> generate a 100-continue expectation in a request that does not include a payload body.
-         </li>
-         <li>A client that will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the request payload body <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field containing a 100-continue expectation.
-         </li>
-         <li>A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client <em class="bcp14">MAY</em> proceed to send the payload body even if it has not yet received a response. Furthermore, since <a href="#status.100" class="smpl">100 (Continue)</a> responses cannot be sent to an HTTP/1.0 intermediary, and since some servers have failed to implement Expect, such a client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the payload body.
-         </li>
-         <li>A client that sends a 100-continue expectation <em class="bcp14">MUST NOT</em> send an expect-value or expect-param within that expectation.
+         <li>A client <em class="bcp14">MUST NOT</em> generate a 100-continue expectation in a request that does not include a message body.
+         </li>
+         <li>A client that will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the request message body <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field containing a 100-continue expectation.
+         </li>
+         <li>A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client <em class="bcp14">MAY</em> proceed to send the message body even if it has not yet received a response. Furthermore, since <a href="#status.100" class="smpl">100 (Continue)</a> responses cannot be sent through an HTTP/1.0 intermediary, such a client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the message body.
          </li>
          <li>A client that receives a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code in response to a request containing a 100-continue expectation <em class="bcp14">SHOULD</em> repeat that request without a 100-continue expectation, since the 417 response merely indicates that the response chain does
@@ -1719 +1708 @@
          </li>
       </ul>
-      <p id="rfc.section.5.1.1.1.p.3">Requirements for origin servers: </p>
+      <p id="rfc.section.5.1.1.p.10">Requirements for servers: </p>
       <ul>
-         <li>Upon receiving a request that includes a 100-continue expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response.
-         </li>
-         <li>An origin server <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 client.
-         </li>
-         <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the payload body for the corresponding request.
-         </li>
-         <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the payload body is received and processed, unless the connection is closed prematurely.
-         </li>
-         <li>An origin server that responds with a final status code before reading the entire payload body <em class="bcp14">SHOULD</em> indicate in that response whether it intends to close the connection or continue reading and discarding the request payload
-            body (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
+         <li>A server that receives a 100-continue expectation in an HTTP/1.0 request <em class="bcp14">MUST</em> ignore that expectation.
+         </li>
+         <li>A server <em class="bcp14">MAY</em> omit sending a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the message body for the corresponding request, or if the framing indicates
+            that there is no message body.
+         </li>
+         <li>A server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the message body is received and processed, unless the connection is closed prematurely.
+         </li>
+         <li>A server that responds with a final status code before reading the entire message body <em class="bcp14">SHOULD</em> indicate in that response whether it intends to close the connection or continue reading and discarding the request message
+            (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
          </li>
       </ul>
-      <p id="rfc.section.5.1.1.1.p.4">Requirements for proxies: </p>
-      <ul>
-         <li>A proxy that forwards a request received with a 100-continue expectation <em class="bcp14">MUST</em> send a 100-continue expectation in the forwarded request.
-         </li>
-         <li>A proxy <em class="bcp14">MUST NOT</em> forward a request received with a 100-continue expectation if it knows the advertised HTTP version of the next-hop server
-            is HTTP/1.0; instead, such a proxy <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code.
-         </li>
-         <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
-         </li>
-      </ul>
+      <p id="rfc.section.5.1.1.p.11">An origin server <em class="bcp14">MUST</em>, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation
+         and indicates a request message body will follow, either send an immediate response with a final status code, if that status
+         can be determined by examining just the request-line and header fields, or send an immediate <a href="#status.100" class="smpl">100 (Continue)</a> response to encourage the client to send the request's message body. The origin server <em class="bcp14">MUST NOT</em> wait for the message body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response.
+      </p>
+      <p id="rfc.section.5.1.1.p.12">A proxy <em class="bcp14">MUST</em>, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation
+         and indicates a request message body will follow, either send an immediate response with a final status code, if that status
+         can be determined by examining just the request-line and header fields, or begin forwarding the request toward the origin
+         server by sending a corresponding request-line and header section to the next inbound server. If the proxy believes (from
+         configuration or past interaction) that the next inbound server only supports HTTP/1.0, the proxy <em class="bcp14">MAY</em> generate an immediate <a href="#status.100" class="smpl">100 (Continue)</a> response to encourage the client to begin sending the message body.
+      </p>
+      <div class="note" id="rfc.section.5.1.1.p.13">
+         <p><b>Note:</b> The Expect header field was added after the original publication of HTTP/1.1 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> as both the means to request an interim 100 response and the general mechanism for indicating must-understand extensions.
+            However, the extension mechanism has not been used by clients and the must-understand requirements have not been implemented
+            by many servers, rendering the extension mechanism useless. This specification has removed the extension mechanism in order
+            to simplify the definition and processing of 100-continue.
+         </p> 
+      </div>
       <div id="rfc.iref.m.1"></div>
       <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3>
@@ -1748 +1743 @@
          to trace a request that appears to be failing or looping mid-chain.
       </p>
-      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
+      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.18"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
 </pre><p id="rfc.section.5.1.2.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
       <p id="rfc.section.5.1.2.p.4">Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the intermediary <em class="bcp14">MUST NOT</em> forward the request; instead, the intermediary <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, the intermediary <em class="bcp14">MUST</em> generate an updated Max-Forwards field in the forwarded message with a field-value that is the lesser of: a) the received
@@ -1837 +1832 @@
          a value of 0 means "not acceptable". If no "q" parameter is present, the default weight is 1.
       </p>
-      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span>  <a href="#quality.values" class="smpl">weight</a> = <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a>
+      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>  <a href="#quality.values" class="smpl">weight</a> = <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a>
   <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#imported.abnf" class="smpl">DIGIT</a> ] )
          / ( "1" [ "." 0*3("0") ] )
@@ -1849 +1844 @@
          for an in-line image.
       </p>
-      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
+      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span>  <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
   
   <a href="#header.accept" class="smpl">media-range</a>    = ( "*/*"
@@ -1871 +1866 @@
       </div>
       <p id="rfc.section.5.3.2.p.6">The example</p>
-      <div id="rfc.figure.u.24"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
+      <div id="rfc.figure.u.25"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
 </pre><p id="rfc.section.5.3.2.p.8"><em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
          quality".
@@ -1880 +1875 @@
       </p>
       <p id="rfc.section.5.3.2.p.10">A more elaborate example is</p>
-      <div id="rfc.figure.u.25"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
+      <div id="rfc.figure.u.26"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
           text/x-dvi; q=0.8, text/x-c
 </pre><p id="rfc.section.5.3.2.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the equally preferred media types, but if they do not exist,
@@ -1888 +1883 @@
          to a given type, the most specific reference has precedence. For example,
       </p>
-      <div id="rfc.figure.u.26"></div><pre class="text">  Accept: text/*, text/plain, text/plain;format=flowed, */*
+      <div id="rfc.figure.u.27"></div><pre class="text">  Accept: text/*, text/plain, text/plain;format=flowed, */*
 </pre><p id="rfc.section.5.3.2.p.15">have the following precedence: </p>
       <ol>
@@ -1899 +1894 @@
          that matches the type. For example,
       </p>
-      <div id="rfc.figure.u.27"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+      <div id="rfc.figure.u.28"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
           text/html;level=2;q=0.4, */*;q=0.5
 </pre><p id="rfc.section.5.3.2.p.18">would cause the following values to be associated:</p>
@@ -1947 +1942 @@
          capability to an origin server that is capable of representing information in those charsets.
       </p>
-      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#charset" class="smpl">charset</a> / "*" ) [ <a href="#quality.values" class="smpl">weight</a> ] )
+      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#charset" class="smpl">charset</a> / "*" ) [ <a href="#quality.values" class="smpl">weight</a> ] )
 </pre><p id="rfc.section.5.3.3.p.3">Charset names are defined in <a href="#charset" title="Charset">Section&nbsp;3.1.1.2</a>. A user agent <em class="bcp14">MAY</em> associate a quality value with each charset to indicate the user's relative preference for that charset, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>. An example is
       </p>
-      <div id="rfc.figure.u.29"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+      <div id="rfc.figure.u.30"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
 </pre><p id="rfc.section.5.3.3.p.5">The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the
          Accept-Charset field. If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field
@@ -1967 +1962 @@
          no encoding is preferred.
       </p>
-      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#quality.values" class="smpl">weight</a> ] )
+      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#quality.values" class="smpl">weight</a> ] )
   <a href="#header.accept-encoding" class="smpl">codings</a>          = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*"
 </pre><p id="rfc.section.5.3.4.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value representing the preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>. The asterisk "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
@@ -1973 +1968 @@
       </p>
       <p id="rfc.section.5.3.4.p.4">For example,</p>
-      <div id="rfc.figure.u.31"></div><pre class="text">  Accept-Encoding: compress, gzip
+      <div id="rfc.figure.u.32"></div><pre class="text">  Accept-Encoding: compress, gzip
   Accept-Encoding:
   Accept-Encoding: *
@@ -2007 +2002 @@
          in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;3.1.3.1</a>.
       </p>
-      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a> = 1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#quality.values" class="smpl">weight</a> ] )
+      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a> = 1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#quality.values" class="smpl">weight</a> ] )
   <a href="#header.accept-language" class="smpl">language-range</a>  = 
             &lt;language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>&gt;
@@ -2013 +2008 @@
          specified by that range, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>. For example,
       </p>
-      <div id="rfc.figure.u.33"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
+      <div id="rfc.figure.u.34"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
 </pre><p id="rfc.section.5.3.5.p.5">would mean: "I prefer Danish, but will accept British English and other types of English".</p>
       <p id="rfc.section.5.3.5.p.6">A request without any Accept-Language header field implies that the user agent will accept any language in response. If the
@@ -2098 +2093 @@
          ought to be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
       </p>
-      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
+      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
   
   <a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>&gt;
 </pre><p id="rfc.section.5.5.1.p.3">An example is:</p>
-      <div id="rfc.figure.u.35"></div><pre class="text">  From: webmaster@example.org
+      <div id="rfc.figure.u.36"></div><pre class="text">  From: webmaster@example.org
 </pre><p id="rfc.section.5.5.1.p.5">The From header field is rarely sent by non-robotic user agents. A user agent <em class="bcp14">SHOULD NOT</em> send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests
          or their site's security policy.
@@ -2116 +2111 @@
       <p id="rfc.section.5.5.2.p.1">The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the <a href="p1-messaging.html#target-resource" class="smpl">target URI</a> was obtained (i.e., the "referrer", though the field name is misspelled). A user agent <em class="bcp14">MUST NOT</em> include the fragment and userinfo components of the URI reference <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, if any, when generating the Referer field value.
       </p>
-      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
+      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
 </pre><p id="rfc.section.5.5.2.p.3">Referer allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc. It
          also allows obsolete or mistyped links to be found for maintenance. Some servers use Referer as a means of denying links from
@@ -2123 +2118 @@
       </p>
       <p id="rfc.section.5.5.2.p.4">Example:</p>
-      <div id="rfc.figure.u.37"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
+      <div id="rfc.figure.u.38"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
 </pre><p id="rfc.section.5.5.2.p.6">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard, or an entry
          within the user's bookmarks/favorites), the user agent <em class="bcp14">MUST</em> either exclude Referer or send it with a value of "about:blank".
@@ -2144 +2139 @@
          agent limitations, and for analytics regarding browser or operating system use. A user agent <em class="bcp14">SHOULD</em> send a User-Agent field in each request unless specifically configured not to do so.
       </p>
-      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.36"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) )
+      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) )
 </pre><p id="rfc.section.5.5.3.p.3">The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the user agent software and its significant subproducts. By convention, the product identifiers
          are listed in decreasing order of their significance for identifying the user agent software. Each product identifier consists
          of a name and optional version.
       </p>
-      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span>  <a href="#header.user-agent" class="smpl">product</a>         = <a href="#imported.abnf" class="smpl">token</a> ["/" <a href="#header.user-agent" class="smpl">product-version</a>]
+      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span>  <a href="#header.user-agent" class="smpl">product</a>         = <a href="#imported.abnf" class="smpl">token</a> ["/" <a href="#header.user-agent" class="smpl">product-version</a>]
   <a href="#header.user-agent" class="smpl">product-version</a> = <a href="#imported.abnf" class="smpl">token</a>
 </pre><p id="rfc.section.5.5.3.p.5">Senders <em class="bcp14">SHOULD</em> limit generated product identifiers to what is necessary to identify the product; senders <em class="bcp14">MUST NOT</em> generate advertising or other non-essential information within the product identifier. Senders <em class="bcp14">SHOULD NOT</em> generate information in <a href="#header.user-agent" class="smpl">product-version</a> that is not a version identifier (i.e., successive versions of the same product name ought to only differ in the product-version
@@ -2155 +2150 @@
       </p>
       <p id="rfc.section.5.5.3.p.6">Example:</p>
-      <div id="rfc.figure.u.40"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+      <div id="rfc.figure.u.41"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
 </pre><p id="rfc.section.5.5.3.p.8">A user agent <em class="bcp14">SHOULD NOT</em> generate a User-Agent field containing needlessly fine-grained detail and <em class="bcp14">SHOULD</em> limit the addition of subproducts by third parties. Overly long and detailed User-Agent field values increase request latency
          and the risk of a user being identified against their wishes ("fingerprinting").
@@ -2418 +2413 @@
       </p>
       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>
-      <div id="rfc.iref.72"></div>
+      <div id="rfc.iref.67"></div>
       <div id="rfc.iref.s.3"></div>
       <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing
@@ -2431 +2426 @@
          "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).
       </p>
-      <div id="rfc.iref.73"></div>
+      <div id="rfc.iref.68"></div>
       <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="status.100" href="#status.100">100 Continue</a></h3>
       <p id="rfc.section.6.2.1.p.1">The <dfn>100 (Continue)</dfn> status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The
          server intends to send a final response after the request has been fully received and acted upon.
       </p>
-      <p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#expect-100-continue" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#expect-100-continue" title="100-continue Expectation">Section&nbsp;5.1.1.1</a>. The client ought to continue sending the request and discard the 100 response.
-      </p>
-      <p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="#expect-100-continue" class="smpl">100-continue</a> expectation, the client can simply discard this interim response.
-      </p>
-      <div id="rfc.iref.73"></div>
+      <p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#header.expect" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;5.1.1</a>. The client ought to continue sending the request and discard the 100 response.
+      </p>
+      <p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="#header.expect" class="smpl">100-continue</a> expectation, the client can simply discard this interim response.
+      </p>
+      <div id="rfc.iref.68"></div>
       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
       <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the
@@ -2450 +2445 @@
       </p>
       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>
-      <div id="rfc.iref.73"></div>
+      <div id="rfc.iref.68"></div>
       <div id="rfc.iref.s.4"></div>
       <p id="rfc.section.6.3.p.1">The <dfn>2xx (Successful)</dfn> class of status code indicates that the client's request was successfully received, understood, and accepted.
       </p>
-      <div id="rfc.iref.74"></div>
+      <div id="rfc.iref.69"></div>
       <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
       <p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For
@@ -2479 +2474 @@
       <p id="rfc.section.6.3.1.p.3">A 200 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.74"></div>
+      <div id="rfc.iref.69"></div>
       <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h3>
       <p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The
@@ -2486 +2481 @@
       <p id="rfc.section.6.3.2.p.2">The 201 response payload typically describes and links to the resource(s) created. See <a href="#response.validator" title="Validator Header Fields">Section&nbsp;7.2</a> for a discussion of the meaning and purpose of validator header fields, such as <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a>, in a 201 response.
       </p>
-      <div id="rfc.iref.74"></div>
+      <div id="rfc.iref.69"></div>
       <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a id="status.202" href="#status.202">202 Accepted</a></h3>
       <p id="rfc.section.6.3.3.p.1">The <dfn>202 (Accepted)</dfn> status code indicates that the request has been accepted for processing, but the processing has not been completed. The request
@@ -2498 +2493 @@
          be fulfilled.
       </p>
-      <div id="rfc.iref.74"></div>
+      <div id="rfc.iref.69"></div>
       <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
       <p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might
@@ -2508 +2503 @@
       <p id="rfc.section.6.3.4.p.3">A 203 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.74"></div>
+      <div id="rfc.iref.69"></div>
       <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
       <p id="rfc.section.6.3.5.p.1">The <dfn>204 (No Content)</dfn> status code indicates that the server has successfully fulfilled the request and that there is no additional content to send
@@ -2528 +2523 @@
       <p id="rfc.section.6.3.5.p.6">A 204 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.74"></div>
+      <div id="rfc.iref.69"></div>
       <h3 id="rfc.section.6.3.6"><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;<a id="status.205" href="#status.205">205 Reset Content</a></h3>
       <p id="rfc.section.6.3.6.p.1">The <dfn>205 (Reset Content)</dfn> status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view",
@@ -2541 +2536 @@
       </p>
       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
-      <div id="rfc.iref.74"></div>
+      <div id="rfc.iref.69"></div>
       <div id="rfc.iref.s.5"></div>
       <p id="rfc.section.6.4.p.1">The <dfn>3xx (Redirection)</dfn> class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. If
@@ -2578 +2573 @@
          </p> 
       </div>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
       <p id="rfc.section.6.4.1.p.1">The <dfn>300 (Multiple Choices)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has more than one representation, each with its own more specific identifier, and information about the alternatives is being
@@ -2600 +2595 @@
          </p> 
       </div>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
       <p id="rfc.section.6.4.2.p.1">The <dfn>301 (Moved Permanently)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients
@@ -2615 +2610 @@
       <p id="rfc.section.6.4.2.p.4">A 301 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3>
       <p id="rfc.section.6.4.3.p.1">The <dfn>302 (Found)</dfn> status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered
@@ -2627 +2622 @@
          </p> 
       </div>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;<a id="status.303" href="#status.303">303 See Other</a></h3>
       <p id="rfc.section.6.4.4.p.1">The <dfn>303 (See Other)</dfn> status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the <a href="#header.location" class="smpl">Location</a> header field, that is intended to provide an indirect response to the original request. In order to satisfy the original request,
@@ -2646 +2641 @@
          a hyperlink to the same URI reference provided in the <a href="#header.location" class="smpl">Location</a> header field.
       </p>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <h3 id="rfc.section.6.4.5"><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;<a id="status.305" href="#status.305">305 Use Proxy</a></h3>
       <p id="rfc.section.6.4.5.p.1">The <dfn>305 (Use Proxy)</dfn> status code was defined in a previous version of this specification and is now deprecated (<a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;B</a>).
       </p>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <h3 id="rfc.section.6.4.6"><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;<a id="status.306" href="#status.306">306 (Unused)</a></h3>
       <p id="rfc.section.6.4.6.p.1">The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.</p>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <h3 id="rfc.section.6.4.7"><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
       <p id="rfc.section.6.4.7.p.1">The <dfn>307 (Temporary Redirect)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> resides temporarily under a different URI and the user agent <em class="bcp14">MUST NOT</em> change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time,
@@ -2668 +2663 @@
       </div>
       <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>
-      <div id="rfc.iref.75"></div>
+      <div id="rfc.iref.70"></div>
       <div id="rfc.iref.s.6"></div>
       <p id="rfc.section.6.5.p.1">The <dfn>4xx (Client Error)</dfn> class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
          These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a id="status.400" href="#status.400">400 Bad Request</a></h3>
       <p id="rfc.section.6.5.1.p.1">The <dfn>400 (Bad Request)</dfn> status code indicates that the server cannot or will not process the request due to something which is perceived to be a client
          error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.2"><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;<a id="status.402" href="#status.402">402 Payment Required</a></h3>
       <p id="rfc.section.6.5.2.p.1">The <dfn>402 (Payment Required)</dfn> status code is reserved for future use.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.3"><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;<a id="status.403" href="#status.403">403 Forbidden</a></h3>
       <p id="rfc.section.6.5.3.p.1">The <dfn>403 (Forbidden)</dfn> status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public
@@ -2691 +2686 @@
       <p id="rfc.section.6.5.3.p.3">An origin server that wishes to "hide" the current existence of a forbidden <a href="#resources" class="smpl">target resource</a> <em class="bcp14">MAY</em> instead respond with a status code of <a href="#status.404" class="smpl">404 (Not Found)</a>.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
       <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status does not indicate whether this lack of representation is temporary
@@ -2699 +2694 @@
       <p id="rfc.section.6.5.4.p.2">A 404 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
       <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method specified in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.
@@ -2705 +2700 @@
       <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
       <p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation that would be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a>), and the server is unwilling to supply a default representation.
@@ -2713 +2708 @@
          for such automatic selection, as described in <a href="#status.300" id="rfc.xref.status.300.2" title="300 Multiple Choices">Section&nbsp;6.4.1</a>.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;<a id="status.408" href="#status.408">408 Request Timeout</a></h3>
       <p id="rfc.section.6.5.7.p.1">The <dfn>408 (Request Timeout)</dfn> status code indicates that the server did not receive a complete request message within the time that it was prepared to wait.
@@ -2719 +2714 @@
          the client has an outstanding request in transit, the client <em class="bcp14">MAY</em> repeat that request on a new connection.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;<a id="status.409" href="#status.409">409 Conflict</a></h3>
       <p id="rfc.section.6.5.8.p.1">The <dfn>409 (Conflict)</dfn> status code indicates that the request could not be completed due to a conflict with the current state of the target resource.
@@ -2729 +2724 @@
          contain information useful for merging the differences based on the revision history.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.9"><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
       <p id="rfc.section.6.5.9.p.1">The <dfn>410 (Gone)</dfn> status code indicates that access to the <a href="#resources" class="smpl">target resource</a> is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not
@@ -2742 +2737 @@
       <p id="rfc.section.6.5.9.p.3">A 410 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;<a id="status.411" href="#status.411">411 Length Required</a></h3>
       <p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> (<a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
          message.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.11"><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;<a id="status.413" href="#status.413">413 Payload Too Large</a></h3>
       <p id="rfc.section.6.5.11.p.1">The <dfn>413 (Payload Too Large)</dfn> status code indicates that the server is refusing to process a request because the request payload is larger than the server
@@ -2754 +2749 @@
       <p id="rfc.section.6.5.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> generate a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
       <p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly
@@ -2763 +2758 @@
       <p id="rfc.section.6.5.12.p.2">A 414 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
       <p id="rfc.section.6.5.13.p.1">The <dfn>415 (Unsupported Media Type)</dfn> status code indicates that the origin server is refusing to service the request because the payload is in a format not supported
          by the <a href="#resources" class="smpl">target resource</a> for this method. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
       </p>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.14"><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
-      <p id="rfc.section.6.5.14.p.1">The <dfn>417 (Expectation Failed)</dfn> status code indicates that the expectation given in the request's <a href="#header.expect" class="smpl">Expect</a> header field (<a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;5.1.1</a>) could not be met by at least one of the inbound servers.
-      </p>
-      <div id="rfc.iref.76"></div>
+      <p id="rfc.section.6.5.14.p.1">The <dfn>417 (Expectation Failed)</dfn> status code indicates that the expectation given in the request's <a href="#header.expect" class="smpl">Expect</a> header field (<a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;5.1.1</a>) could not be met by at least one of the inbound servers.
+      </p>
+      <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
       <p id="rfc.section.6.5.15.p.1">The <dfn>426 (Upgrade Required)</dfn> status code indicates that the server refuses to perform the request using the current protocol but might be willing to do
          so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
       </p>
-      <div id="rfc.figure.u.41"></div>
+      <div id="rfc.figure.u.42"></div>
       <p>Example:</p><pre class="text">HTTP/1.1 426 Upgrade Required
 Upgrade: HTTP/3.0
@@ -2786 +2781 @@
 <span id="s426body">This service requires use of the HTTP/3.0 protocol.
 </span></pre><h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
-      <div id="rfc.iref.76"></div>
+      <div id="rfc.iref.71"></div>
       <div id="rfc.iref.s.7"></div>
       <p id="rfc.section.6.6.p.1">The <dfn>5xx (Server Error)</dfn> class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method.
@@ -2792 +2787 @@
          User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
       </p>
-      <div id="rfc.iref.77"></div>
+      <div id="rfc.iref.72"></div>
       <h3 id="rfc.section.6.6.1"><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;<a id="status.500" href="#status.500">500 Internal Server Error</a></h3>
       <p id="rfc.section.6.6.1.p.1">The <dfn>500 (Internal Server Error)</dfn> status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
       </p>
-      <div id="rfc.iref.77"></div>
+      <div id="rfc.iref.72"></div>
       <h3 id="rfc.section.6.6.2"><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;<a id="status.501" href="#status.501">501 Not Implemented</a></h3>
       <p id="rfc.section.6.6.2.p.1">The <dfn>501 (Not Implemented)</dfn> status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate
@@ -2803 +2798 @@
       <p id="rfc.section.6.6.2.p.2">A 501 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
-      <div id="rfc.iref.77"></div>
+      <div id="rfc.iref.72"></div>
       <h3 id="rfc.section.6.6.3"><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;<a id="status.502" href="#status.502">502 Bad Gateway</a></h3>
       <p id="rfc.section.6.6.3.p.1">The <dfn>502 (Bad Gateway)</dfn> status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server
          it accessed while attempting to fulfill the request.
       </p>
-      <div id="rfc.iref.77"></div>
+      <div id="rfc.iref.72"></div>
       <h3 id="rfc.section.6.6.4"><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
       <p id="rfc.section.6.6.4.p.1">The <dfn>503 (Service Unavailable)</dfn> status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance,
@@ -2818 +2813 @@
          </p> 
       </div>
-      <div id="rfc.iref.77"></div>
+      <div id="rfc.iref.72"></div>
       <h3 id="rfc.section.6.6.5"><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;<a id="status.504" href="#status.504">504 Gateway Timeout</a></h3>
       <p id="rfc.section.6.6.5.p.1">The <dfn>504 (Gateway Timeout)</dfn> status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream
          server it needed to access in order to complete the request.
       </p>
-      <div id="rfc.iref.77"></div>
+      <div id="rfc.iref.72"></div>
       <h3 id="rfc.section.6.6.6"><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;<a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3>
       <p id="rfc.section.6.6.6.p.1">The <dfn>505 (HTTP Version Not Supported)</dfn> status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in
@@ -2891 +2886 @@
          and time specification used by the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>.
       </p>
-      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.39"></span>  <a href="#http.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
-</pre><div id="rfc.figure.u.43"></div>
+      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#http.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
+</pre><div id="rfc.figure.u.44"></div>
       <p>An example of the preferred format is</p><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
-</pre><div id="rfc.figure.u.44"></div>
+</pre><div id="rfc.figure.u.45"></div>
       <p>Examples of the two obsolete formats are</p><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
 Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
@@ -2907 +2902 @@
          <p id="rfc.section.7.1.1.1.p.7">          Preferred format:</p>
       </div>
-      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span>  <a href="#preferred.date.format" class="smpl">IMF-fixdate</a>  = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#imported.abnf" class="smpl">SP</a> date1 <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
+      <div id="rfc.figure.u.46"></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><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span>  <a href="#preferred.date.format" class="smpl">IMF-fixdate</a>  = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#imported.abnf" class="smpl">SP</a> date1 <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
   ; fixed length/zone subset of the format defined in
   ; <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>
@@ -2948 +2943 @@
          <p id="rfc.section.7.1.1.1.p.9">       Obsolete formats:</p>
       </div>
-      <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.52"></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.47"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
+      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.48"></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.48"></div><pre class="inline"><span id="rfc.iref.g.49"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" 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="#imported.abnf" class="smpl">DIGIT</a>
                ; e.g., 02-Jun-82
@@ -2960 +2955 @@
          / %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.48"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
+</pre><div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" 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="#imported.abnf" class="smpl">SP</a> ( 2<a href="#imported.abnf" class="smpl">DIGIT</a> / ( <a href="#imported.abnf" class="smpl">SP</a> 1<a href="#imported.abnf" class="smpl">DIGIT</a> ))
                ; e.g., Jun  2
@@ -2982 +2977 @@
          Origination Date Field (orig-date) defined 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.6"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1.1.1</a>.
       </p>
-      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
+      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
 </pre><p id="rfc.section.7.1.1.2.p.3">An example is</p>
-      <div id="rfc.figure.u.50"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
+      <div id="rfc.figure.u.51"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
 </pre><p id="rfc.section.7.1.1.2.p.5">When a Date header field is generated, the sender <em class="bcp14">SHOULD</em> generate its field value as the best available approximation of the date and time of message generation. In theory, the date
          ought to represent the moment just before the payload is generated. In practice, the date can be generated at any time during
@@ -3004 +2999 @@
          of relationship is defined by the combination of request method and status code semantics.
       </p>
-      <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#imported.abnf" class="smpl">URI-reference</a>
+      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#imported.abnf" class="smpl">URI-reference</a>
 </pre><p id="rfc.section.7.1.2.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>).
       </p>
@@ -3013 +3008 @@
          not have a fragment component, the user agent <em class="bcp14">SHOULD</em> interpret the Location reference as if it had the original reference's fragment.
       </p>
-      <div id="rfc.figure.u.52"></div>
+      <div id="rfc.figure.u.53"></div>
       <p>For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a <a href="#status.303" class="smpl">303 (See Other)</a> response containing the header field:
       </p><pre class="text">  Location: /People.html#tim
 </pre><p>which suggests that the user agent redirect to "http://www.example.org/People.html#tim"</p>
-      <div id="rfc.figure.u.53"></div>
+      <div id="rfc.figure.u.54"></div>
       <p>Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a <a href="#status.301" class="smpl">301 (Moved Permanently)</a> response containing the header field:
       </p><pre class="text">  Location: http://www.example.net/index.html
@@ -3042 +3037 @@
       </p>
       <p id="rfc.section.7.1.3.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
-      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.57"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
+      <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
 </pre><div id="rule.delta-seconds">
          <p id="rfc.section.7.1.3.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p>
       </div>
-      <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.58"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
+      <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
 </pre><p id="rfc.section.7.1.3.p.6">Two examples of its use are</p>
-      <div id="rfc.figure.u.56"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
+      <div id="rfc.figure.u.57"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
   Retry-After: 120
 </pre><p id="rfc.section.7.1.3.p.8">In the latter example, the delay is 2 minutes.</p>
@@ -3057 +3052 @@
          of either a single asterisk ("*") or a list of header field names (case-insensitive).
       </p>
-      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.59"></span>  <a href="#header.vary" class="smpl">Vary</a> = "*" / 1#<a href="#imported.abnf" class="smpl">field-name</a>
+      <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.vary" class="smpl">Vary</a> = "*" / 1#<a href="#imported.abnf" class="smpl">field-name</a>
 </pre><p id="rfc.section.7.1.4.p.3">A Vary field value of "*" signals that anything about the request might play a role in selecting the response representation,
          possibly including elements outside the message syntax (e.g., the client's network address), and thus a recipient will not
@@ -3067 +3062 @@
          not limited to those defined by this specification.
       </p>
-      <div id="rfc.figure.u.58"></div>
+      <div id="rfc.figure.u.59"></div>
       <p>For example, a response that contains</p><pre class="text">  Vary: accept-encoding, accept-language
 </pre><p>indicates that the origin server might have used the request's <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> and <a href="#header.accept-language" class="smpl">Accept-Language</a> fields (or lack thereof) as determining factors while choosing the content for this response.
@@ -3175 +3170 @@
       <p id="rfc.section.7.4.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the <a href="#resources" class="smpl">target resource</a>. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.
       </p>
-      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.60"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method.overview" class="smpl">method</a>
+      <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method.overview" class="smpl">method</a>
 </pre><p id="rfc.section.7.4.1.p.3">Example of use:</p>
-      <div id="rfc.figure.u.60"></div><pre class="text">  Allow: GET, HEAD, PUT
+      <div id="rfc.figure.u.61"></div><pre class="text">  Allow: GET, HEAD, PUT
 </pre><p id="rfc.section.7.4.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request. An origin server <em class="bcp14">MUST</em> generate an Allow field in a <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> response and <em class="bcp14">MAY</em> do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in
          a 405 response if the resource has been temporarily disabled by configuration.
@@ -3190 +3185 @@
          to avoid particular server limitations, and for analytics regarding server or operating system use. An origin server <em class="bcp14">MAY</em> generate a Server field in its responses.
       </p>
-      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.61"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) )
+      <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.57"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) )
 </pre><p id="rfc.section.7.4.2.p.3">The Server field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the origin server software and its significant subproducts. By convention, the product identifiers
          are listed in decreasing order of their significance for identifying the origin server software. Each product identifier consists
@@ -3196 +3191 @@
       </p>
       <p id="rfc.section.7.4.2.p.4">Example:</p>
-      <div id="rfc.figure.u.62"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
+      <div id="rfc.figure.u.63"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
 </pre><p id="rfc.section.7.4.2.p.6">An origin server <em class="bcp14">SHOULD NOT</em> generate a Server field containing needlessly fine-grained detail and <em class="bcp14">SHOULD</em> limit the addition of subproducts by third parties. Overly long and detailed Server field values increase response latency
          and potentially reveal internal implementation details that might make it (slightly) easier for attackers to find and exploit
@@ -3611 +3606 @@
          these:
       </p>
-      <div id="rfc.figure.u.63"></div><pre class="text">  Example-URI-Field: "http://example.com/a.html,foo",
+      <div id="rfc.figure.u.64"></div><pre class="text">  Example-URI-Field: "http://example.com/a.html,foo",
                      "http://without-a-comma.example.com/"
   Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
@@ -3753 +3748 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;5.1.1</a> 
+                  <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;5.1.1</a> 
                   </td>
                </tr>
@@ -4264 +4259 @@
       <p id="rfc.section.B.p.9">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods have been defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section&nbsp;4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>)
       </p>
-      <p id="rfc.section.B.p.10">The definition of the <a href="#header.expect" class="smpl">Expect</a> header field has been fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons. (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;5.1.1</a>)
+      <p id="rfc.section.B.p.10">The definition of the <a href="#header.expect" class="smpl">Expect</a> header field has been fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons. (<a href="#header.expect" id="rfc.xref.header.expect.5" title="Expect">Section&nbsp;5.1.1</a>)
       </p>
       <p id="rfc.section.B.p.11">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field has been restricted to the <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> methods; previously, extension methods could have used it as well. (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;5.1.2</a>)
@@ -4317 +4312 @@
       <p id="rfc.section.C.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
       </p>
-      <div id="rfc.figure.u.64"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
+      <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
   <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
@@ -4331 +4326 @@
       <p id="rfc.section.D.p.1">In the collected ABNF below, list rules are expanded as per <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.62"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
       </p>
-      <div id="rfc.figure.u.65"></div><pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
+      <div id="rfc.figure.u.66"></div><pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
  OWS ( media-range [ accept-params ] ) ] ) ]
 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
@@ -4352 +4347 @@
 <a href="#header.date" class="smpl">Date</a> = HTTP-date
 
-<a href="#header.expect" class="smpl">Expect</a> = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
+<a href="#header.expect" class="smpl">Expect</a> = "100-continue"
 
 <a href="#header.from" class="smpl">From</a> = mailbox
@@ -4411 +4406 @@
 <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT
 
-<a href="#header.expect" class="smpl">expect-name</a> = token
-<a href="#header.expect" class="smpl">expect-param</a> = expect-name [ BWS "=" BWS expect-value ]
-<a href="#header.expect" class="smpl">expect-value</a> = token / quoted-string
-<a href="#header.expect" class="smpl">expectation</a> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
- OWS expect-param ] )
-
 <a href="#imported.abnf" class="smpl">field-name</a> = &lt;comment, defined in [Part1], Section 3.2&gt;
 
@@ -4545 +4534 @@
          <ul class="ind">
             <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
-                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">6.1</a>, <a href="#rfc.iref.73"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.2">8.2.3</a></li>
-                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.45"><b>5.1.1.1</b></a></li>
-                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.73"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">8.2.3</a></li>
-                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.72"><b>6.2</b></a></li>
+                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">6.1</a>, <a href="#rfc.iref.68"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.2">8.2.3</a></li>
+                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.40"><b>5.1.1</b></a></li>
+                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.68"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">8.2.3</a></li>
+                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.67"><b>6.2</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
-                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">6.1</a>, <a href="#rfc.iref.74"><b>6.3.1</b></a>, <a href="#rfc.xref.status.200.2">8.2.3</a></li>
-                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.74"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">8.2.3</a>, <a href="#rfc.xref.status.201.3">B</a></li>
-                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">6.1</a>, <a href="#rfc.iref.74"><b>6.3.3</b></a>, <a href="#rfc.xref.status.202.2">8.2.3</a></li>
-                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.74"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">8.2.3</a>, <a href="#rfc.xref.status.203.3">B</a></li>
-                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">6.1</a>, <a href="#rfc.iref.74"><b>6.3.5</b></a>, <a href="#rfc.xref.status.204.2">8.2.3</a></li>
-                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">6.1</a>, <a href="#rfc.iref.74"><b>6.3.6</b></a>, <a href="#rfc.xref.status.205.2">8.2.3</a></li>
-                  <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.73"><b>6.3</b></a></li>
+                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">6.1</a>, <a href="#rfc.iref.69"><b>6.3.1</b></a>, <a href="#rfc.xref.status.200.2">8.2.3</a></li>
+                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.69"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">8.2.3</a>, <a href="#rfc.xref.status.201.3">B</a></li>
+                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">6.1</a>, <a href="#rfc.iref.69"><b>6.3.3</b></a>, <a href="#rfc.xref.status.202.2">8.2.3</a></li>
+                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.69"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">8.2.3</a>, <a href="#rfc.xref.status.203.3">B</a></li>
+                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">6.1</a>, <a href="#rfc.iref.69"><b>6.3.5</b></a>, <a href="#rfc.xref.status.204.2">8.2.3</a></li>
+                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">6.1</a>, <a href="#rfc.iref.69"><b>6.3.6</b></a>, <a href="#rfc.xref.status.205.2">8.2.3</a></li>
+                  <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.68"><b>6.3</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
-                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">6.1</a>, <a href="#rfc.iref.75"><b>6.4.1</b></a>, <a href="#rfc.xref.status.300.2">6.5.6</a>, <a href="#rfc.xref.status.300.3">8.2.3</a></li>
-                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.75"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">8.2.3</a>, <a href="#rfc.xref.status.301.3">B</a></li>
-                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.75"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">8.2.3</a>, <a href="#rfc.xref.status.302.3">B</a></li>
-                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.75"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">8.2.3</a>, <a href="#rfc.xref.status.303.3">B</a></li>
-                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.75"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">8.2.3</a>, <a href="#rfc.xref.status.305.3">B</a></li>
-                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.75"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">8.2.3</a></li>
-                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.75"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">8.2.3</a></li>
-                  <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.74"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li>
+                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">6.1</a>, <a href="#rfc.iref.70"><b>6.4.1</b></a>, <a href="#rfc.xref.status.300.2">6.5.6</a>, <a href="#rfc.xref.status.300.3">8.2.3</a></li>
+                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.70"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">8.2.3</a>, <a href="#rfc.xref.status.301.3">B</a></li>
+                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.70"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">8.2.3</a>, <a href="#rfc.xref.status.302.3">B</a></li>
+                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.70"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">8.2.3</a>, <a href="#rfc.xref.status.303.3">B</a></li>
+                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.70"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">8.2.3</a>, <a href="#rfc.xref.status.305.3">B</a></li>
+                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.70"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">8.2.3</a></li>
+                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.70"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">8.2.3</a></li>
+                  <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.69"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li>
                </ul>
             </li>
             <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
-                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">8.2.3</a>, <a href="#rfc.xref.status.400.3">B</a></li>
-                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.2</b></a>, <a href="#rfc.xref.status.402.2">8.2.3</a></li>
-                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">8.2.3</a></li>
-                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.4</b></a>, <a href="#rfc.xref.status.404.2">8.2.3</a></li>
-                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.5</b></a>, <a href="#rfc.xref.status.405.2">8.2.3</a></li>
-                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.6</b></a>, <a href="#rfc.xref.status.406.2">8.2.3</a></li>
-                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.7</b></a>, <a href="#rfc.xref.status.408.2">8.2.3</a></li>
-                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.8</b></a>, <a href="#rfc.xref.status.409.2">8.2.3</a></li>
-                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.9</b></a>, <a href="#rfc.xref.status.410.2">8.2.3</a></li>
-                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.10</b></a>, <a href="#rfc.xref.status.411.2">8.2.3</a></li>
-                  <li>413 Payload Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">8.2.3</a></li>
-                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.12</b></a>, <a href="#rfc.xref.status.414.2">8.2.3</a></li>
-                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">8.2.3</a></li>
-                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.14</b></a>, <a href="#rfc.xref.status.417.2">8.2.3</a></li>
-                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.76"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">8.2.3</a>, <a href="#rfc.xref.status.426.3">B</a></li>
-                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.75"><b>6.5</b></a></li>
+                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">8.2.3</a>, <a href="#rfc.xref.status.400.3">B</a></li>
+                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.2</b></a>, <a href="#rfc.xref.status.402.2">8.2.3</a></li>
+                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">8.2.3</a></li>
+                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.4</b></a>, <a href="#rfc.xref.status.404.2">8.2.3</a></li>
+                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.5</b></a>, <a href="#rfc.xref.status.405.2">8.2.3</a></li>
+                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.6</b></a>, <a href="#rfc.xref.status.406.2">8.2.3</a></li>
+                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.7</b></a>, <a href="#rfc.xref.status.408.2">8.2.3</a></li>
+                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.8</b></a>, <a href="#rfc.xref.status.409.2">8.2.3</a></li>
+                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.9</b></a>, <a href="#rfc.xref.status.410.2">8.2.3</a></li>
+                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.10</b></a>, <a href="#rfc.xref.status.411.2">8.2.3</a></li>
+                  <li>413 Payload Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">8.2.3</a></li>
+                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.12</b></a>, <a href="#rfc.xref.status.414.2">8.2.3</a></li>
+                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">8.2.3</a></li>
+                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.14</b></a>, <a href="#rfc.xref.status.417.2">8.2.3</a></li>
+                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.71"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">8.2.3</a>, <a href="#rfc.xref.status.426.3">B</a></li>
+                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.70"><b>6.5</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul>
-                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">6.1</a>, <a href="#rfc.iref.77"><b>6.6.1</b></a>, <a href="#rfc.xref.status.500.2">8.2.3</a></li>
-                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">6.1</a>, <a href="#rfc.iref.77"><b>6.6.2</b></a>, <a href="#rfc.xref.status.501.2">8.2.3</a></li>
-                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">6.1</a>, <a href="#rfc.iref.77"><b>6.6.3</b></a>, <a href="#rfc.xref.status.502.2">8.2.3</a></li>
-                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">6.1</a>, <a href="#rfc.iref.77"><b>6.6.4</b></a>, <a href="#rfc.xref.status.503.2">8.2.3</a></li>
-                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">6.1</a>, <a href="#rfc.iref.77"><b>6.6.5</b></a>, <a href="#rfc.xref.status.504.2">8.2.3</a></li>
-                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">6.1</a>, <a href="#rfc.iref.77"><b>6.6.6</b></a>, <a href="#rfc.xref.status.505.2">8.2.3</a></li>
-                  <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.76"><b>6.6</b></a></li>
+                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">6.1</a>, <a href="#rfc.iref.72"><b>6.6.1</b></a>, <a href="#rfc.xref.status.500.2">8.2.3</a></li>
+                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">6.1</a>, <a href="#rfc.iref.72"><b>6.6.2</b></a>, <a href="#rfc.xref.status.501.2">8.2.3</a></li>
+                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">6.1</a>, <a href="#rfc.iref.72"><b>6.6.3</b></a>, <a href="#rfc.xref.status.502.2">8.2.3</a></li>
+                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">6.1</a>, <a href="#rfc.iref.72"><b>6.6.4</b></a>, <a href="#rfc.xref.status.503.2">8.2.3</a></li>
+                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">6.1</a>, <a href="#rfc.iref.72"><b>6.6.5</b></a>, <a href="#rfc.xref.status.504.2">8.2.3</a></li>
+                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">6.1</a>, <a href="#rfc.iref.72"><b>6.6.6</b></a>, <a href="#rfc.xref.status.505.2">8.2.3</a></li>
+                  <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.71"><b>6.6</b></a></li>
                </ul>
             </li>
@@ -4635 +4624 @@
             </li>
             <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
-                  <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1.1</b></a>, <a href="#rfc.xref.header.expect.2">6.5.14</a>, <a href="#rfc.xref.header.expect.3">8.3.2</a>, <a href="#rfc.xref.header.expect.4">B</a></li>
-                  <li>Expect Values&nbsp;&nbsp;
-                     <ul>
-                        <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>5.1.1.1</b></a></li>
-                     </ul>
-                  </li>
+                  <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1.1</b></a>, <a href="#rfc.xref.header.expect.2">6.2.1</a>, <a href="#rfc.xref.header.expect.3">6.5.14</a>, <a href="#rfc.xref.header.expect.4">8.3.2</a>, <a href="#rfc.xref.header.expect.5">B</a></li>
                </ul>
             </li>
@@ -4651 +4635 @@
                   <li><tt>Grammar</tt>&nbsp;&nbsp;
                      <ul>
-                        <li><tt>Accept</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>5.3.2</b></a></li>
-                        <li><tt>Accept-Charset</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>5.3.3</b></a></li>
-                        <li><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>5.3.4</b></a></li>
-                        <li><tt>accept-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>5.3.2</b></a></li>
-                        <li><tt>Accept-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>5.3.5</b></a></li>
-                        <li><tt>accept-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>5.3.2</b></a></li>
-                        <li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>7.4.1</b></a></li>
-                        <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>7.1.1.1</b></a></li>
+                        <li><tt>Accept</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>5.3.2</b></a></li>
+                        <li><tt>Accept-Charset</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>5.3.3</b></a></li>
+                        <li><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>5.3.4</b></a></li>
+                        <li><tt>accept-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>5.3.2</b></a></li>
+                        <li><tt>Accept-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>5.3.5</b></a></li>
+                        <li><tt>accept-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>5.3.2</b></a></li>
+                        <li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>7.4.1</b></a></li>
+                        <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>7.1.1.1</b></a></li>
                         <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>3.1.1.1</b></a></li>
                         <li><tt>charset</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>3.1.1.2</b></a></li>
-                        <li><tt>codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>5.3.4</b></a></li>
+                        <li><tt>codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>5.3.4</b></a></li>
                         <li><tt>content-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>3.1.2.1</b></a></li>
                         <li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>3.1.2.2</b></a></li>
@@ -4667 +4651 @@
                         <li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>3.1.4.2</b></a></li>
                         <li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>3.1.1.5</b></a></li>
-                        <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>7.1.1.2</b></a></li>
-                        <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>7.1.1.1</b></a></li>
-                        <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>7.1.1.1</b></a></li>
-                        <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>7.1.1.1</b></a></li>
-                        <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>7.1.1.1</b></a></li>
-                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>7.1.3</b></a></li>
+                        <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>7.1.1.2</b></a></li>
+                        <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>7.1.1.1</b></a></li>
+                        <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>7.1.1.1</b></a></li>
+                        <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>7.1.1.1</b></a></li>
+                        <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>7.1.1.1</b></a></li>
+                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>7.1.3</b></a></li>
                         <li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>5.1.1</b></a></li>
-                        <li><tt>expect-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>5.1.1</b></a></li>
-                        <li><tt>expect-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>5.1.1</b></a></li>
-                        <li><tt>expect-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>5.1.1</b></a></li>
-                        <li><tt>expectation</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>5.1.1</b></a></li>
-                        <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>5.5.1</b></a></li>
-                        <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>7.1.1.1</b></a></li>
-                        <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>7.1.1.1</b></a></li>
-                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>7.1.1.1</b></a></li>
-                        <li><tt>IMF-fixdate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li>
-                        <li><tt>language-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>5.3.5</b></a></li>
+                        <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>5.5.1</b></a></li>
+                        <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>7.1.1.1</b></a></li>
+                        <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>7.1.1.1</b></a></li>
+                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>7.1.1.1</b></a></li>
+                        <li><tt>IMF-fixdate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>7.1.1.1</b></a></li>
+                        <li><tt>language-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>5.3.5</b></a></li>
                         <li><tt>language-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>3.1.3.1</b></a></li>
-                        <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>7.1.2</b></a></li>
-                        <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>5.1.2</b></a></li>
-                        <li><tt>media-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>5.3.2</b></a></li>
+                        <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>7.1.2</b></a></li>
+                        <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>5.1.2</b></a></li>
+                        <li><tt>media-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>5.3.2</b></a></li>
                         <li><tt>media-type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.1.1.1</b></a></li>
                         <li><tt>method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>4.1</b></a></li>
-                        <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>7.1.1.1</b></a></li>
-                        <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>7.1.1.1</b></a></li>
-                        <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>7.1.1.1</b></a></li>
+                        <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li>
+                        <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>7.1.1.1</b></a></li>
+                        <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>7.1.1.1</b></a></li>
                         <li><tt>parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.1.1.1</b></a></li>
-                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>5.5.3</b></a></li>
-                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>5.5.3</b></a></li>
-                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>5.3.1</b></a></li>
-                        <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>5.5.2</b></a></li>
-                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>7.1.3</b></a></li>
-                        <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>7.1.1.1</b></a></li>
-                        <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>7.1.1.1</b></a></li>
-                        <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>7.4.2</b></a></li>
+                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>5.5.3</b></a></li>
+                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>5.5.3</b></a></li>
+                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>5.3.1</b></a></li>
+                        <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>5.5.2</b></a></li>
+                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>7.1.3</b></a></li>
+                        <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>7.1.1.1</b></a></li>
+                        <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>7.1.1.1</b></a></li>
+                        <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>7.4.2</b></a></li>
                         <li><tt>subtype</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.1.1.1</b></a></li>
-                        <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>7.1.1.1</b></a></li>
+                        <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>7.1.1.1</b></a></li>
                         <li><tt>type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.1.1.1</b></a></li>
-                        <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>5.5.3</b></a></li>
+                        <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>5.5.3</b></a></li>
                         <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>3.1.1.1</b></a></li>
-                        <li><tt>Vary</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>7.1.4</b></a></li>
-                        <li><tt>weight</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>5.3.1</b></a></li>
-                        <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>7.1.1.1</b></a></li>
+                        <li><tt>Vary</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>7.1.4</b></a></li>
+                        <li><tt>weight</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>5.3.1</b></a></li>
+                        <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>7.1.1.1</b></a></li>
                      </ul>
                   </li>
@@ -4733 +4713 @@
             </li>
             <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
-                  <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.2</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.13">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.14">B</a></li>
+                  <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.2</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.11">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.12">B</a></li>
                </ul>
             </li>
             <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
-                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1.1.1</a>, <a href="#rfc.xref.Part1.22">5.5.3</a>, <a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.3.4</a>, <a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.26">6.5.10</a>, <a href="#rfc.xref.Part1.27">6.5.12</a>, <a href="#rfc.xref.Part1.28">6.5.15</a>, <a href="#rfc.xref.Part1.29">6.6.6</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.1.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.4</a>, <a href="#rfc.xref.Part1.40">8.4.1</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">8.4.2</a>, <a href="#rfc.xref.Part1.44">8.4.2</a>, <a href="#rfc.xref.Part1.45">8.4.2</a>, <a href="#rfc.xref.Part1.46">8.4.2</a>, <a href="#rfc.xref.Part1.47">9.4</a>, <a href="#rfc.xref.Part1.48">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.49">B</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a>, <a href="#rfc.xref.Part1.58">C</a>, <a href="#rfc.xref.Part1.59">C</a>, <a href="#rfc.xref.Part1.60">C</a>, <a href="#rfc.xref.Part1.61">C</a>, <a href="#rfc.xref.Part1.62">D</a><ul>
+                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1.1</a>, <a href="#rfc.xref.Part1.22">5.5.3</a>, <a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.3.4</a>, <a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.26">6.5.10</a>, <a href="#rfc.xref.Part1.27">6.5.12</a>, <a href="#rfc.xref.Part1.28">6.5.15</a>, <a href="#rfc.xref.Part1.29">6.6.6</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.1.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.4</a>, <a href="#rfc.xref.Part1.40">8.4.1</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">8.4.2</a>, <a href="#rfc.xref.Part1.44">8.4.2</a>, <a href="#rfc.xref.Part1.45">8.4.2</a>, <a href="#rfc.xref.Part1.46">8.4.2</a>, <a href="#rfc.xref.Part1.47">9.4</a>, <a href="#rfc.xref.Part1.48">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.49">B</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a>, <a href="#rfc.xref.Part1.58">C</a>, <a href="#rfc.xref.Part1.59">C</a>, <a href="#rfc.xref.Part1.60">C</a>, <a href="#rfc.xref.Part1.61">C</a>, <a href="#rfc.xref.Part1.62">D</a><ul>
                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.62">D</a></li>
                         <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
@@ -4762 +4742 @@
                         <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.3.4</a></li>
                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.37">8.3.1</a></li>
-                        <li><em>Section 6.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.1.1.1</a></li>
+                        <li><em>Section 6.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.1.1</a></li>
                         <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.28">6.5.15</a></li>
                         <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.33">8.3.1</a></li>
@@ -4920 +4900 @@
             </li>
             <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
-                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.2</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">B</a>, <a href="#rfc.xref.TRACE.4">B</a>, <a href="#rfc.extref.t.51">B</a></li>
+                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.2</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.48">B</a>, <a href="#rfc.xref.TRACE.4">B</a>, <a href="#rfc.extref.t.49">B</a></li>
                </ul>
             </li>