Changeset 1440 for draft-ietf-httpbis


Ignore:
Timestamp:
Sep 9, 2011, 4:04:01 AM (8 years ago)
Author:
julian.reschke@…
Message:

Update org for Mark in references to P6 for consistency (doesn't affect generated docs) (see [1438])

Location:
draft-ietf-httpbis/latest
Files:
11 edited

Legend:

Unmodified
Added
Removed

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

    r1435 r1440  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 5, 2012";
     361       content: "Expires March 12, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-09-02">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-09-09">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: March 5, 2012</td>
     442               <td class="left">Expires: March 12, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">September 2, 2011</td>
     495               <td class="right">September 9, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on March 5, 2012.</p>
     528      <p>This Internet-Draft will expire on March 12, 2012.</p>
    529529      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    530530      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    600600         </li>
    601601         <li>5.&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul>
    602                <li>5.1&nbsp;&nbsp;&nbsp;<a href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></li>
    603                <li>5.2&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
    604                      <li>5.2.1&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></li>
    605                      <li>5.2.2&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
    606                            <li>5.2.2.1&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
    607                            <li>5.2.2.2&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
    608                            <li>5.2.2.3&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
     602               <li>5.1&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
     603                     <li>5.1.1&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></li>
     604                     <li>5.1.2&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
     605                           <li>5.1.2.1&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
     606                           <li>5.1.2.2&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
     607                           <li>5.1.2.3&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
    609608                        </ul>
    610609                     </li>
    611                      <li>5.2.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
     610                     <li>5.1.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
    612611                  </ul>
    613612               </li>
    614                <li>5.3&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
    615                <li>5.4&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
     613               <li>5.2&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
     614               <li>5.3&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
    616615            </ul>
    617616         </li>
    … …  
    652651               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    653652               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
    654                <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a><ul>
    655                      <li>8.3.1&nbsp;&nbsp;&nbsp;<a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li>
     653               <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
     654               <li>8.4&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
     655               <li>8.5&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
     656               <li>8.6&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
     657               <li>8.7&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
     658                     <li>8.7.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    656659                  </ul>
    657660               </li>
    658                <li>8.4&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    659                <li>8.5&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
    660                <li>8.6&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
    661                <li>8.7&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
    662                <li>8.8&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
    663                      <li>8.8.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    664                   </ul>
    665                </li>
    666                <li>8.9&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     661               <li>8.8&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    667662            </ul>
    668663         </li>
    … …  
    909904<span id="exbody">Hello World!
    910905</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="message-orientation-and-buffering" href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2>
    911       <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations
     906      <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations
    912907         only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some
    913908         amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide
    … …  
    973968         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    974969         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    975          However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.9</a>) header fields for both connections.
     970         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.8</a>) header fields for both connections.
    976971      </p>
    977972      <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    … …  
    12481243  <a href="#header.fields" class="smpl">field-content</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12491244</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1250          the Date header field is defined in <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a> as containing the origination timestamp for the message in which it appears.
     1245         the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12511246      </p>
    12521247      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
    … …  
    12561251         them.
    12571252      </p>
    1258       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1253      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    12591254      </p>
    12601255      <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    … …  
    13011296      <div id="rule.token.separators">
    13021297         <p id="rfc.section.3.2.3.p.1">        Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.
    1303             These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>).
     1298            These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>).
    13041299         </p>
    13051300      </div>
    … …  
    13481343      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
    13491344</pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
    1350          header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.7</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
     1345         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.6</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
    13511346      </p>
    13521347      <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
    1353          field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>.
     1348         field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>.
    13541349      </p>
    13551350      <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;8.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
    … …  
    13771372         </li>
    13781373         <li>
    1379             <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
     1374            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
    13801375               indicates the data is complete.
    13811376            </p>
    … …  
    14811476      <p id="rfc.section.4.1.p.7">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    14821477      </p>
    1483       <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1478      <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    14841479      </p>
    14851480      <p id="rfc.section.4.1.p.9"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,
    … …  
    15511546         </li>
    15521547         <li>the octet sequence "://",</li>
    1553          <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;8.4</a>), and
     1548         <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;8.3</a>), and
    15541549         </li>
    15551550         <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li>
    … …  
    15741569      </p>
    15751570      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    1576       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2>
    1577       <p id="rfc.section.5.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is
    1578          a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
    1579       </p>
    1580       <div id="rfc.figure.u.41"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
    1581 </pre><p id="rfc.section.5.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
    1582       <div id="rfc.figure.u.42"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    1583 Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    1584 </pre><p id="rfc.section.5.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields.
    1585       </p>
    1586       <p id="rfc.section.5.1.p.6">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
    1587          Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    1588          time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar.
    1589       </p>
    1590       <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
    1591 </pre><div id="preferred.date.format">
    1592          <p id="rfc.section.5.1.p.8">                    Preferred format:</p>
    1593       </div>
    1594       <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    1595   ; fixed length subset of the format defined in
    1596   ; <a href="http://tools.ietf.org/html/rfc1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>
    1597  
    1598   <a href="#preferred.date.format" class="smpl">day-name</a>     = %x4D.6F.6E ; "Mon", case-sensitive
    1599                / %x54.75.65 ; "Tue", case-sensitive
    1600                / %x57.65.64 ; "Wed", case-sensitive
    1601                / %x54.68.75 ; "Thu", case-sensitive
    1602                / %x46.72.69 ; "Fri", case-sensitive
    1603                / %x53.61.74 ; "Sat", case-sensitive
    1604                / %x53.75.6E ; "Sun", case-sensitive
    1605                
    1606   <a href="#obsolete.date.formats" class="smpl">date1</a>        = <a href="#preferred.date.format" class="smpl">day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
    1607                ; e.g., 02 Jun 1982
    1608 
    1609   <a href="#preferred.date.format" class="smpl">day</a>          = 2<a href="#core.rules" class="smpl">DIGIT</a>
    1610   <a href="#preferred.date.format" class="smpl">month</a>        = %x4A.61.6E ; "Jan", case-sensitive
    1611                / %x46.65.62 ; "Feb", case-sensitive
    1612                / %x4D.61.72 ; "Mar", case-sensitive
    1613                / %x41.70.72 ; "Apr", case-sensitive
    1614                / %x4D.61.79 ; "May", case-sensitive
    1615                / %x4A.75.6E ; "Jun", case-sensitive
    1616                / %x4A.75.6C ; "Jul", case-sensitive
    1617                / %x41.75.67 ; "Aug", case-sensitive
    1618                / %x53.65.70 ; "Sep", case-sensitive
    1619                / %x4F.63.74 ; "Oct", case-sensitive
    1620                / %x4E.6F.76 ; "Nov", case-sensitive
    1621                / %x44.65.63 ; "Dec", case-sensitive
    1622   <a href="#preferred.date.format" class="smpl">year</a>         = 4<a href="#core.rules" class="smpl">DIGIT</a>
    1623 
    1624   <a href="#preferred.date.format" class="smpl">GMT</a>   = %x47.4D.54 ; "GMT", case-sensitive
    1625 
    1626   <a href="#preferred.date.format" class="smpl">time-of-day</a>  = <a href="#preferred.date.format" class="smpl">hour</a> ":" <a href="#preferred.date.format" class="smpl">minute</a> ":" <a href="#preferred.date.format" class="smpl">second</a>
    1627                  ; 00:00:00 - 23:59:59
    1628                  
    1629   <a href="#preferred.date.format" class="smpl">hour</a>         = 2<a href="#core.rules" class="smpl">DIGIT</a>               
    1630   <a href="#preferred.date.format" class="smpl">minute</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
    1631   <a href="#preferred.date.format" class="smpl">second</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
    1632 </pre><p id="rfc.section.5.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
    1633       </p>
    1634       <div id="obsolete.date.formats">
    1635          <p id="rfc.section.5.1.p.11">                Obsolete formats:</p>
    1636       </div>
    1637       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.65"></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>
    1638 </pre><div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.66"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    1639   <a href="#obsolete.date.formats" class="smpl">date2</a>        = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a>
    1640                  ; day-month-year (e.g., 02-Jun-82)
    1641 
    1642   <a href="#obsolete.date.formats" class="smpl">day-name-l</a>   = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
    1643          / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
    1644          / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
    1645          / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
    1646          / %x46.72.69.64.61.79 ; "Friday", case-sensitive
    1647          / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
    1648          / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
    1649 </pre><div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
    1650   <a href="#obsolete.date.formats" class="smpl">date3</a>        = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> ))
    1651                  ; month day (e.g., Jun  2)
    1652 </pre><div class="note" id="rfc.section.5.1.p.15">
    1653          <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications,
    1654             as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
    1655          </p>
    1656       </div>
    1657       <div class="note" id="rfc.section.5.1.p.16">
    1658          <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
    1659             are not required to use these formats for user presentation, request logging, etc.
    1660          </p>
    1661       </div>
    1662       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
    1663       <p id="rfc.section.5.2.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
     1571      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
     1572      <p id="rfc.section.5.1.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
    16641573         to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the
    16651574         transfer-coding is a property of the message rather than a property of the representation that is being transferred.
    16661575      </p>
    1667       <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>
    1668                           / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.2.1</a>
    1669                           / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2.2</a>
    1670                           / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.2.3</a>
     1576      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>
     1577                          / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.1.2.1</a>
     1578                          / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.1.2.2</a>
     1579                          / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.1.2.3</a>
    16711580                          / <a href="#transfer.codings" class="smpl">transfer-extension</a>
    16721581  <a href="#transfer.codings" class="smpl">transfer-extension</a>      = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> )
    16731582</pre><div id="rule.parameter">
    1674          <p id="rfc.section.5.2.p.3">      Parameters are in the form of attribute/value pairs.</p>
     1583         <p id="rfc.section.5.1.p.3">      Parameters are in the form of attribute/value pairs.</p>
    16751584      </div>
    1676       <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
     1585      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
    16771586  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    16781587  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
    1679 </pre><p id="rfc.section.5.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;8.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;8.7</a>).
    1680       </p>
    1681       <p id="rfc.section.5.2.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
     1588</pre><p id="rfc.section.5.1.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;8.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;8.6</a>).
     1589      </p>
     1590      <p id="rfc.section.5.1.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
    16821591         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic
    16831592         of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>), or the desire to encrypt data over a shared transport.
    16841593      </p>
    1685       <p id="rfc.section.5.2.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
     1594      <p id="rfc.section.5.1.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
    16861595      </p>
    16871596      <div id="rfc.iref.c.6"></div>
    16881597      <div id="rfc.iref.c.7"></div>
    1689       <h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
    1690       <p id="rfc.section.5.2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
     1598      <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
     1599      <p id="rfc.section.5.1.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
    16911600         indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary
    16921601         for the recipient to verify that it has received the full message.
    16931602      </p>
    1694       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     1603      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    16951604                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    16961605                   <a href="#chunked.encoding" class="smpl">trailer-part</a>
    … …  
    17121621                 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding
    17131622  <a href="#chunked.encoding" class="smpl">qdtext-nf</a>      = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    1714 </pre><p id="rfc.section.5.2.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
     1623</pre><p id="rfc.section.5.1.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
    17151624         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
    17161625      </p>
    1717       <p id="rfc.section.5.2.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
    1718          can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;8.6</a>).
    1719       </p>
    1720       <p id="rfc.section.5.2.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
     1626      <p id="rfc.section.5.1.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
     1627         can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;8.5</a>).
     1628      </p>
     1629      <p id="rfc.section.5.1.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
    17211630      </p>
    17221631      <ol>
    17231632         <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as
    1724             described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;8.5</a>; or,
     1633            described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;8.4</a>; or,
    17251634         </li>
    17261635         <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
    … …  
    17301639         </li>
    17311640      </ol>
    1732       <p id="rfc.section.5.2.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
     1641      <p id="rfc.section.5.1.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
    17331642         forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly
    17341643         infinite buffer on the proxy.
    17351644      </p>
    1736       <p id="rfc.section.5.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    1737       <div id="rfc.figure.u.51"></div><pre class="text">  length := 0
     1645      <p id="rfc.section.5.1.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
     1646      <div id="rfc.figure.u.44"></div><pre class="text">  length := 0
    17381647  read chunk-size, chunk-ext (if any) and CRLF
    17391648  while (chunk-size &gt; 0) {
    … …  
    17501659  Content-Length := length
    17511660  Remove "chunked" from Transfer-Encoding
    1752 </pre><p id="rfc.section.5.2.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
    1753       </p>
    1754       <p id="rfc.section.5.2.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
     1661</pre><p id="rfc.section.5.1.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
     1662      </p>
     1663      <p id="rfc.section.5.1.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
    17551664         messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding
    17561665         applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body.
    17571666      </p>
    1758       <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>
    1759       <p id="rfc.section.5.2.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
    1760       <div class="note" id="rfc.section.5.2.2.p.2">
     1667      <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>
     1668      <p id="rfc.section.5.1.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
     1669      <div class="note" id="rfc.section.5.1.2.p.2">
    17611670         <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
    17621671            Their use here is representative of historical practice, not good design.
    17631672         </p>
    17641673      </div>
    1765       <div class="note" id="rfc.section.5.2.2.p.3">
     1674      <div class="note" id="rfc.section.5.1.2.p.3">
    17661675         <p> <b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
    17671676         </p>
    … …  
    17691678      <div id="rfc.iref.c.8"></div>
    17701679      <div id="rfc.iref.c.9"></div>
    1771       <h4 id="rfc.section.5.2.2.1"><a href="#rfc.section.5.2.2.1">5.2.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h4>
    1772       <p id="rfc.section.5.2.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
     1680      <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h4>
     1681      <p id="rfc.section.5.1.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
    17731682         coding (LZW).
    17741683      </p>
    17751684      <div id="rfc.iref.d.2"></div>
    17761685      <div id="rfc.iref.c.10"></div>
    1777       <h4 id="rfc.section.5.2.2.2"><a href="#rfc.section.5.2.2.2">5.2.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>
    1778       <p id="rfc.section.5.2.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).
    1779       </p>
    1780       <div class="note" id="rfc.section.5.2.2.2.p.2">
     1686      <h4 id="rfc.section.5.1.2.2"><a href="#rfc.section.5.1.2.2">5.1.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>
     1687      <p id="rfc.section.5.1.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).
     1688      </p>
     1689      <div class="note" id="rfc.section.5.1.2.2.p.2">
    17811690         <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper.
    17821691         </p>
    17831692      </div>
    1784       <div id="rfc.iref.g.86"></div>
     1693      <div id="rfc.iref.g.70"></div>
    17851694      <div id="rfc.iref.c.11"></div>
    1786       <h4 id="rfc.section.5.2.2.3"><a href="#rfc.section.5.2.2.3">5.2.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>
    1787       <p id="rfc.section.5.2.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
    1788       </p>
    1789       <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3>
    1790       <p id="rfc.section.5.2.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
    1791       <p id="rfc.section.5.2.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     1695      <h4 id="rfc.section.5.1.2.3"><a href="#rfc.section.5.1.2.3">5.1.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>
     1696      <p id="rfc.section.5.1.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
     1697      </p>
     1698      <h3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3>
     1699      <p id="rfc.section.5.1.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
     1700      <p id="rfc.section.5.1.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    17921701      </p>
    17931702      <ul>
    … …  
    17961705         <li>Pointer to specification text</li>
    17971706      </ul>
    1798       <p id="rfc.section.5.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;5.2.2</a>).
    1799       </p>
    1800       <p id="rfc.section.5.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
    1801       </p>
    1802       <p id="rfc.section.5.2.3.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    1803       </p>
    1804       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
    1805       <p id="rfc.section.5.3.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
     1707      <p id="rfc.section.5.1.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;5.1.2</a>).
     1708      </p>
     1709      <p id="rfc.section.5.1.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
     1710      </p>
     1711      <p id="rfc.section.5.1.3.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     1712      </p>
     1713      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
     1714      <p id="rfc.section.5.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
    18061715         using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace.
    18071716         By convention, the products are listed in order of their significance for identifying the application.
    18081717      </p>
    1809       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
     1718      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
    18101719  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    1811 </pre><p id="rfc.section.5.3.p.3">Examples:</p>
    1812       <div id="rfc.figure.u.53"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     1720</pre><p id="rfc.section.5.2.p.3">Examples:</p>
     1721      <div id="rfc.figure.u.46"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    18131722  Server: Apache/0.8.4
    1814 </pre><p id="rfc.section.5.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
    1815       </p>
    1816       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1817       <p id="rfc.section.5.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;8.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1723</pre><p id="rfc.section.5.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
     1724      </p>
     1725      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
     1726      <p id="rfc.section.5.3.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;8.4</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    18181727         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    18191728         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    18201729      </p>
    1821       <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.89"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
     1730      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    18221731                 / ( "1" [ "." 0*3("0") ] )
    1823 </pre><div class="note" id="rfc.section.5.4.p.3">
     1732</pre><div class="note" id="rfc.section.5.3.p.3">
    18241733         <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.
    18251734         </p>
    … …  
    18791788      <p id="rfc.section.6.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    18801789      </p>
    1881       <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     1790      <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    18821791         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    18831792      </p>
    … …  
    19491858         </p>
    19501859      </div>
    1951       <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>).
     1860      <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>).
    19521861      </p>
    19531862      <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    … …  
    19651874      </p>
    19661875      <p id="rfc.section.6.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    1967          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     1876         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    19681877         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    19691878      </p>
    … …  
    19891898      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    19901899      <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    1991          status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
     1900         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    19921901      </p>
    19931902      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    1994       <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     1903      <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    19951904         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    19961905         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    19991908      <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    20001909      <ul>
    2001          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2002          </li>
    2003          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     1910         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     1911         </li>
     1912         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    20041913         </li>
    20051914      </ul>
    … …  
    20451954         <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    20461955            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    2047             1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1956            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    20481957         </li>
    20491958      </ul>
    … …  
    21092018               </tr>
    21102019               <tr>
    2111                   <td class="left">Date</td>
    2112                   <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;8.3</a></td>
    2113                </tr>
    2114                <tr>
    21152020                  <td class="left">Host</td>
    2116                   <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.4</a></td>
     2021                  <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.3</a></td>
    21172022               </tr>
    21182023               <tr>
    21192024                  <td class="left">TE</td>
    2120                   <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;8.5</a></td>
     2025                  <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;8.4</a></td>
    21212026               </tr>
    21222027               <tr>
    21232028                  <td class="left">Trailer</td>
    2124                   <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.6</a></td>
     2029                  <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.5</a></td>
    21252030               </tr>
    21262031               <tr>
    21272032                  <td class="left">Transfer-Encoding</td>
    2128                   <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.7</a></td>
     2033                  <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.6</a></td>
    21292034               </tr>
    21302035               <tr>
    21312036                  <td class="left">Upgrade</td>
    2132                   <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.8</a></td>
     2037                  <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.7</a></td>
    21332038               </tr>
    21342039               <tr>
    21352040                  <td class="left">Via</td>
    2136                   <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.9</a></td>
     2041                  <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.8</a></td>
    21372042               </tr>
    21382043            </tbody>
    … …  
    21502055      </p>
    21512056      <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p>
    2152       <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
     2057      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
    21532058  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    21542059</pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
    … …  
    21732078         of the response. For example,
    21742079      </p>
    2175       <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
     2080      <div id="rfc.figure.u.49"></div><pre class="text">  Connection: close
    21762081</pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.1</a>) after the current request/response is complete.
    21772082      </p>
    … …  
    21892094         body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
    21902095      </p>
    2191       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.92"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     2096      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.76"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    21922097</pre><p id="rfc.section.8.2.p.3">An example is</p>
    2193       <div id="rfc.figure.u.58"></div><pre class="text">  Content-Length: 3495
     2098      <div id="rfc.figure.u.51"></div><pre class="text">  Content-Length: 3495
    21942099</pre><p id="rfc.section.8.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
    21952100         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
    … …  
    21992104         an optional field used within the "message/external-body" content-type.
    22002105      </p>
    2201       <div id="rfc.iref.d.3"></div>
    22022106      <div id="rfc.iref.h.8"></div>
    2203       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    2204       <p id="rfc.section.8.3.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
    2205          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.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;5.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    2206       </p>
    2207       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.93"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>
    2208 </pre><p id="rfc.section.8.3.p.3">An example is</p>
    2209       <div id="rfc.figure.u.60"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    2210 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    2211       </p>
    2212       <ol>
    2213          <li>If the response status code is 100 (Continue) or 101 (Switching Protocols), the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
    2214          </li>
    2215          <li>If the response status code conveys a server error, e.g., 500 (Internal Server Error) or 503 (Service Unavailable), and it
    2216             is inconvenient or impossible to generate a valid Date.
    2217          </li>
    2218          <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section&nbsp;8.3.1</a>  <em class="bcp14">MUST</em> be followed.
    2219          </li>
    2220       </ol>
    2221       <p id="rfc.section.8.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
    2222       </p>
    2223       <p id="rfc.section.8.3.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
    2224          when it doesn't convey any useful information (as it is usually the case for requests that do not contain a payload).
    2225       </p>
    2226       <p id="rfc.section.8.3.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    2227          of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    2228          is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    2229          value.
    2230       </p>
    2231       <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>
    2232       <p id="rfc.section.8.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or
    2233          user with a reliable clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration"
    2234          of responses without storing separate Expires values for each resource).
    2235       </p>
    22362107      <div id="rfc.iref.h.9"></div>
    2237       <div id="rfc.iref.h.10"></div>
    2238       <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    2239       <p id="rfc.section.8.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
     2108      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
     2109      <p id="rfc.section.8.3.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
    22402110         server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the
    22412111         Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line.
    22422112      </p>
    2243       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.94"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
    2244 </pre><p id="rfc.section.8.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
     2113      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
     2114</pre><p id="rfc.section.8.3.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
    22452115         the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    22462116      </p>
    2247       <p id="rfc.section.8.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    2248       <div id="rfc.figure.u.62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
     2117      <p id="rfc.section.8.3.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
     2118      <div id="rfc.figure.u.53"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    22492119Host: www.example.org
    2250 </pre><p id="rfc.section.8.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
     2120</pre><p id="rfc.section.8.3.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
    22512121         to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
    22522122      </p>
    2253       <p id="rfc.section.8.4.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
     2123      <p id="rfc.section.8.3.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
    22542124         a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host.
    22552125      </p>
    2256       <p id="rfc.section.8.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
     2126      <p id="rfc.section.8.3.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
    22572127         poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
    22582128         relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared
    22592129         cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.
    22602130      </p>
    2261       <p id="rfc.section.8.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
     2131      <p id="rfc.section.8.3.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
    22622132         message that contains more than one Host header field or a Host header field with an invalid field-value.
    22632133      </p>
    2264       <p id="rfc.section.8.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
     2134      <p id="rfc.section.8.3.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
    22652135      </p>
    22662136      <div id="rfc.iref.t.5"></div>
    2267       <div id="rfc.iref.h.11"></div>
    2268       <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    2269       <p id="rfc.section.8.5.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not
     2137      <div id="rfc.iref.h.10"></div>
     2138      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
     2139      <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not
    22702140         it is willing to accept trailer fields in a chunked transfer-coding.
    22712141      </p>
    2272       <p id="rfc.section.8.5.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    2273          accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>).
    2274       </p>
    2275       <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     2142      <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
     2143         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>).
     2144      </p>
     2145      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    22762146  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] )
    22772147  <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
    22782148  <a href="#header.te" class="smpl">te-ext</a>    = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
    2279 </pre><p id="rfc.section.8.5.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    2280          as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
    2281       </p>
    2282       <p id="rfc.section.8.5.p.5">Examples of its use are:</p>
    2283       <div id="rfc.figure.u.64"></div><pre class="text">  TE: deflate
     2149</pre><p id="rfc.section.8.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
     2150         as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
     2151      </p>
     2152      <p id="rfc.section.8.4.p.5">Examples of its use are:</p>
     2153      <div id="rfc.figure.u.55"></div><pre class="text">  TE: deflate
    22842154  TE:
    22852155  TE: trailers, deflate;q=0.5
    2286 </pre><p id="rfc.section.8.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a>) whenever TE is present in an HTTP/1.1 message.
    2287       </p>
    2288       <p id="rfc.section.8.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
     2156</pre><p id="rfc.section.8.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a>) whenever TE is present in an HTTP/1.1 message.
     2157      </p>
     2158      <p id="rfc.section.8.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    22892159      <ol>
    22902160         <li>
    … …  
    23002170         <li>
    23012171            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    2302                is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.4</a>, a qvalue of 0 means "not acceptable".)
     2172               is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3</a>, a qvalue of 0 means "not acceptable".)
    23032173            </p>
    23042174         </li>
    … …  
    23092179         </li>
    23102180      </ol>
    2311       <p id="rfc.section.8.5.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
     2181      <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
    23122182         is always acceptable.
    23132183      </p>
    23142184      <div id="rfc.iref.t.6"></div>
    2315       <div id="rfc.iref.h.12"></div>
    2316       <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
    2317       <p id="rfc.section.8.6.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
     2185      <div id="rfc.iref.h.11"></div>
     2186      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
     2187      <p id="rfc.section.8.5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
    23182188         chunked transfer-coding.
    23192189      </p>
    2320       <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.99"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    2321 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
     2190      <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.82"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
     2191</pre><p id="rfc.section.8.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
    23222192         to know which header fields to expect in the trailer.
    23232193      </p>
    2324       <p id="rfc.section.8.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
    2325       </p>
    2326       <p id="rfc.section.8.6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
     2194      <p id="rfc.section.8.5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
     2195      </p>
     2196      <p id="rfc.section.8.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
    23272197      </p>
    23282198      <ul>
    … …  
    23322202      </ul>
    23332203      <div id="rfc.iref.t.7"></div>
    2334       <div id="rfc.iref.h.13"></div>
    2335       <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    2336       <p id="rfc.section.8.7.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
     2204      <div id="rfc.iref.h.12"></div>
     2205      <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
     2206      <p id="rfc.section.8.6.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
    23372207         from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
    23382208         are not.
    23392209      </p>
    2340       <div id="rfc.figure.u.66"></div><pre class="inline"><span id="rfc.iref.g.100"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    2341 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>. An example is:
    2342       </p>
    2343       <div id="rfc.figure.u.67"></div><pre class="text">  Transfer-Encoding: chunked
    2344 </pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    2345       </p>
    2346       <p id="rfc.section.8.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
     2210      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.83"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
     2211</pre><p id="rfc.section.8.6.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>. An example is:
     2212      </p>
     2213      <div id="rfc.figure.u.58"></div><pre class="text">  Transfer-Encoding: chunked
     2214</pre><p id="rfc.section.8.6.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     2215      </p>
     2216      <p id="rfc.section.8.6.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
    23472217      <div id="rfc.iref.u.5"></div>
    2348       <div id="rfc.iref.h.14"></div>
    2349       <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2350       <p id="rfc.section.8.8.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
     2218      <div id="rfc.iref.h.13"></div>
     2219      <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
     2220      <p id="rfc.section.8.7.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
    23512221         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    23522222      </p>
    2353       <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.101"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>
    2354 </pre><p id="rfc.section.8.8.p.3">For example,</p>
    2355       <div id="rfc.figure.u.69"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2356 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
     2223      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>
     2224</pre><p id="rfc.section.8.7.p.3">For example,</p>
     2225      <div id="rfc.figure.u.60"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     2226</pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
    23572227         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    23582228         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    23612231         the server, possibly according to the nature of the request method or target resource).
    23622232      </p>
    2363       <p id="rfc.section.8.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
     2233      <p id="rfc.section.8.7.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
    23642234         Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    23652235         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
    23662236         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
    23672237      </p>
    2368       <p id="rfc.section.8.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    2369       </p>
    2370       <p id="rfc.section.8.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2371          is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    2372       </p>
    2373       <p id="rfc.section.8.8.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
     2238      <p id="rfc.section.8.7.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2239      </p>
     2240      <p id="rfc.section.8.7.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
     2241         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2242      </p>
     2243      <p id="rfc.section.8.7.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    23742244         to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    23752245      </p>
    2376       <p id="rfc.section.8.8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     2246      <p id="rfc.section.8.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    23772247         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    23782248         below.
    23792249      </p>
    2380       <h3 id="rfc.section.8.8.1"><a href="#rfc.section.8.8.1">8.8.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
    2381       <p id="rfc.section.8.8.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header
     2250      <h3 id="rfc.section.8.7.1"><a href="#rfc.section.8.7.1">8.7.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
     2251      <p id="rfc.section.8.7.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header
    23822252         field. Each registered token is associated with contact information and an optional set of specifications that details how
    23832253         the connection will be processed after it has been upgraded.
    23842254      </p>
    2385       <p id="rfc.section.8.8.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:
     2255      <p id="rfc.section.8.7.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:
    23862256      </p>
    23872257      <ol>
    … …  
    24012271      </ol>
    24022272      <div id="rfc.iref.v.1"></div>
    2403       <div id="rfc.iref.h.15"></div>
    2404       <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    2405       <p id="rfc.section.8.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
     2273      <div id="rfc.iref.h.14"></div>
     2274      <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
     2275      <p id="rfc.section.8.8.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
    24062276         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
    2407          systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
     2277         systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
    24082278         of all senders along the request/response chain.
    24092279      </p>
    2410       <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
     2280      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    24112281                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    24122282  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a>
    … …  
    24152285  <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
    24162286  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    2417 </pre><p id="rfc.section.8.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
     2287</pre><p id="rfc.section.8.8.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    24182288         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    24192289         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    24202290      </p>
    2421       <p id="rfc.section.8.9.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
     2291      <p id="rfc.section.8.8.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
    24222292         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    24232293         be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    24242294      </p>
    2425       <p id="rfc.section.8.9.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    2426       </p>
    2427       <p id="rfc.section.8.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
     2295      <p id="rfc.section.8.8.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
     2296      </p>
     2297      <p id="rfc.section.8.8.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
    24282298         fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    24292299      </p>
    2430       <p id="rfc.section.8.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     2300      <p id="rfc.section.8.8.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    24312301         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
    24322302         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    24332303      </p>
    2434       <div id="rfc.figure.u.71"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    2435 </pre><p id="rfc.section.8.9.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     2304      <div id="rfc.figure.u.62"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2305</pre><p id="rfc.section.8.8.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    24362306         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    24372307      </p>
    2438       <p id="rfc.section.8.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
     2308      <p id="rfc.section.8.8.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
    24392309         For example,
    24402310      </p>
    2441       <div id="rfc.figure.u.72"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    2442 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p>
    2443       <div id="rfc.figure.u.73"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    2444 </pre><p id="rfc.section.8.9.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
     2311      <div id="rfc.figure.u.63"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2312</pre><p id="rfc.section.8.8.p.12">could be collapsed to</p>
     2313      <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2314</pre><p id="rfc.section.8.8.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    24452315         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    24462316      </p>
    … …  
    24762346               </tr>
    24772347               <tr>
    2478                   <td class="left">Date</td>
    2479                   <td class="left">http</td>
    2480                   <td class="left">standard</td>
    2481                   <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section&nbsp;8.3</a>
    2482                   </td>
    2483                </tr>
    2484                <tr>
    24852348                  <td class="left">Host</td>
    24862349                  <td class="left">http</td>
    24872350                  <td class="left">standard</td>
    2488                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;8.4</a>
     2351                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;8.3</a>
    24892352                  </td>
    24902353               </tr>
    … …  
    24932356                  <td class="left">http</td>
    24942357                  <td class="left">standard</td>
    2495                   <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;8.5</a>
     2358                  <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;8.4</a>
    24962359                  </td>
    24972360               </tr>
    … …  
    25002363                  <td class="left">http</td>
    25012364                  <td class="left">standard</td>
    2502                   <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;8.6</a>
     2365                  <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;8.5</a>
    25032366                  </td>
    25042367               </tr>
    … …  
    25072370                  <td class="left">http</td>
    25082371                  <td class="left">standard</td>
    2509                   <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.7</a>
     2372                  <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.6</a>
    25102373                  </td>
    25112374               </tr>
    … …  
    25142377                  <td class="left">http</td>
    25152378                  <td class="left">standard</td>
    2516                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.8</a>
     2379                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.7</a>
    25172380                  </td>
    25182381               </tr>
    … …  
    25212384                  <td class="left">http</td>
    25222385                  <td class="left">standard</td>
    2523                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.9</a>
     2386                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.8</a>
    25242387                  </td>
    25252388               </tr>
    … …  
    26702533      </dl>
    26712534      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2>
    2672       <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;5.2.3</a> of this document.
     2535      <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;5.1.3</a> of this document.
    26732536      </p>
    26742537      <p id="rfc.section.9.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
    … …  
    26882551                  <td class="left">chunked</td>
    26892552                  <td class="left">Transfer in a series of chunks</td>
    2690                   <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>
     2553                  <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>
    26912554                  </td>
    26922555               </tr>
    … …  
    26942557                  <td class="left">compress</td>
    26952558                  <td class="left">UNIX "compress" program method</td>
    2696                   <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.2.1</a>
     2559                  <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.1.2.1</a>
    26972560                  </td>
    26982561               </tr>
    … …  
    27012564                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.2"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.2"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    27022565                  </td>
    2703                   <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2.2</a>
     2566                  <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.1.2.2</a>
    27042567                  </td>
    27052568               </tr>
    … …  
    27072570                  <td class="left">gzip</td>
    27082571                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.2"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    2709                   <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.2.3</a>
     2572                  <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.1.2.3</a>
    27102573                  </td>
    27112574               </tr>
    … …  
    27142577      </div>
    27152578      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
    2716       <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.8.1</a> of this document.
     2579      <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.7.1</a> of this document.
    27172580      </p>
    27182581      <p id="rfc.section.9.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    … …  
    27972660         that most implementations will choose substantially higher limits.
    27982661      </p>
    2799       <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2662      <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    28002663      </p>
    28012664      <p id="rfc.section.10.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
    … …  
    28312694         <tr>
    28322695            <td class="reference"><b id="Part6">[Part6]</b></td>
    2833             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
     2696            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
    28342697            </td>
    28352698         </tr>
    … …  
    28742737      <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References
    28752738      </h2>
    2876       <table>                                                   
     2739      <table>                                                 
    28772740         <tr>
    28782741            <td class="reference"><b id="BCP97">[BCP97]</b></td>
    … …  
    28942757            <td class="reference"><b id="Pad1995">[Pad1995]</b></td>
    28952758            <td class="top">Padmanabhan, V. and J. Mogul, “<a href="http://portal.acm.org/citation.cfm?id=219094">Improving HTTP Latency</a>”, Computer Networks and ISDN Systems&nbsp;v. 28, pp. 25-35, December&nbsp;1995, &lt;<a href="http://portal.acm.org/citation.cfm?id=219094">http://portal.acm.org/citation.cfm?id=219094</a>&gt;.
    2896             </td>
    2897          </tr>
    2898          <tr>
    2899             <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
    2900             <td class="top"><a href="mailto:Braden@ISI.EDU" title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
    29012759            </td>
    29022760         </tr>
    … …  
    30512909      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30522910      <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3>
    3053       <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;8.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.
     2911      <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;8.3</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.
    30542912      </p>
    30552913      <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
    … …  
    30942952      <p id="rfc.section.A.2.p.6">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
    30952953      </p>
    3096       <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5.2</a>)
     2954      <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5.1</a>)
    30972955      </p>
    30982956      <p id="rfc.section.A.2.p.8">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    … …  
    31002958      </p>
    31012959      <p id="rfc.section.A.2.p.9">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore
    3102          disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>)
     2960         disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>)
    31032961      </p>
    31042962      <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.1.4</a>)
    … …  
    31082966      <p id="rfc.section.A.2.p.12">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section&nbsp;8.1</a>)
    31092967      </p>
    3110       <p id="rfc.section.A.2.p.13">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.8</a>)
     2968      <p id="rfc.section.A.2.p.13">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.7</a>)
    31112969      </p>
    31122970      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    3113       <div id="rfc.figure.u.74"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
     2971      <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    31142972
    31152973<a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF
    … …  
    31182976<a href="#header.content-length" class="smpl">Content-Length</a> = 1*DIGIT
    31192977
    3120 <a href="#header.date" class="smpl">Date</a> = HTTP-date
    3121 
    3122 <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; GMT
    3123 
    31242978<a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; HTTP
    31252979<a href="#http.version" class="smpl">HTTP-Version</a> = HTTP-Prot-Name "/" DIGIT "." DIGIT
    3126 <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date
    31272980<a href="#http.message" class="smpl">HTTP-message</a> = start-line *( header-field CRLF ) CRLF [ message-body
    31282981 ]
    … …  
    31533006
    31543007<a href="#uri" class="smpl">absolute-URI</a> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;
    3155 <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = day-name SP date3 SP time-of-day SP year
    31563008<a href="#rule.parameter" class="smpl">attribute</a> = token
    31573009<a href="#uri" class="smpl">authority</a> = &lt;authority, defined in [RFC3986], Section 3.2&gt;
    … …  
    31703022 / obs-text
    31713023
    3172 <a href="#obsolete.date.formats" class="smpl">date1</a> = day SP month SP year
    3173 <a href="#obsolete.date.formats" class="smpl">date2</a> = day "-" month "-" 2DIGIT
    3174 <a href="#obsolete.date.formats" class="smpl">date3</a> = month SP ( 2DIGIT / ( SP DIGIT ) )
    3175 <a href="#preferred.date.format" class="smpl">day</a> = 2DIGIT
    3176 <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; Mon
    3177  / %x54.75.65 ; Tue
    3178  / %x57.65.64 ; Wed
    3179  / %x54.68.75 ; Thu
    3180  / %x46.72.69 ; Fri
    3181  / %x53.61.74 ; Sat
    3182  / %x53.75.6E ; Sun
    3183 <a href="#obsolete.date.formats" class="smpl">day-name-l</a> = %x4D.6F.6E.64.61.79 ; Monday
    3184  / %x54.75.65.73.64.61.79 ; Tuesday
    3185  / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
    3186  / %x54.68.75.72.73.64.61.79 ; Thursday
    3187  / %x46.72.69.64.61.79 ; Friday
    3188  / %x53.61.74.75.72.64.61.79 ; Saturday
    3189  / %x53.75.6E.64.61.79 ; Sunday
    3190 
    31913024<a href="#header.fields" class="smpl">field-content</a> = *( HTAB / SP / VCHAR / obs-text )
    31923025<a href="#header.fields" class="smpl">field-name</a> = token
    … …  
    31943027
    31953028<a href="#header.fields" class="smpl">header-field</a> = field-name ":" OWS field-value BWS
    3196 <a href="#preferred.date.format" class="smpl">hour</a> = 2DIGIT
    31973029<a href="#http.uri" class="smpl">http-URI</a> = "http://" authority path-abempty [ "?" query ]
    31983030<a href="#https.uri" class="smpl">https-URI</a> = "https://" authority path-abempty [ "?" query ]
    … …  
    32013033
    32023034<a href="#message.body" class="smpl">message-body</a> = *OCTET
    3203 <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT
    3204 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan
    3205  / %x46.65.62 ; Feb
    3206  / %x4D.61.72 ; Mar
    3207  / %x41.70.72 ; Apr
    3208  / %x4D.61.79 ; May
    3209  / %x4A.75.6E ; Jun
    3210  / %x4A.75.6C ; Jul
    3211  / %x41.75.67 ; Aug
    3212  / %x53.65.70 ; Sep
    3213  / %x4F.63.74 ; Oct
    3214  / %x4E.6F.76 ; Nov
    3215  / %x44.65.63 ; Dec
    32163035
    3217 <a href="#obsolete.date.formats" class="smpl">obs-date</a> = rfc850-date / asctime-date
    32183036<a href="#rule.whitespace" class="smpl">obs-fold</a> = CRLF ( SP / HTAB )
    32193037<a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF
    … …  
    32473065<a href="#request-target" class="smpl">request-target</a> = "*" / absolute-URI / ( path-absolute [ "?" query ] )
    32483066 / authority
    3249 <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT
    3250 <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT
    32513067
    3252 <a href="#preferred.date.format" class="smpl">second</a> = 2DIGIT
    32533068<a href="#rule.token.separators" class="smpl">special</a> = "(" / ")" / "&lt;" / "&gt;" / "@" / "," / ";" / ":" / "\" /
    32543069 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
    … …  
    32603075<a href="#header.te" class="smpl">te-ext</a> = OWS ";" OWS token [ "=" word ]
    32613076<a href="#header.te" class="smpl">te-params</a> = OWS ";" OWS "q=" qvalue *te-ext
    3262 <a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second
    32633077<a href="#rule.token.separators" class="smpl">token</a> = 1*tchar
    32643078<a href="#chunked.encoding" class="smpl">trailer-part</a> = *( header-field CRLF )
    … …  
    32733087
    32743088<a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string
    3275 
    3276 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    3277 </pre> <div id="rfc.figure.u.75"></div>
     3089</pre> <div id="rfc.figure.u.66"></div>
    32783090      <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used
    32793091; Connection defined but not used
    32803092; Content-Length defined but not used
    3281 ; Date defined but not used
    32823093; HTTP-message defined but not used
    32833094; Host defined but not used
    … …  
    36663477                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.5</b></a></li>
    36673478                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li>
    3668                   <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">5.2.1</a></li>
     3479                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">5.1.1</a></li>
    36693480                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    36703481                  <li>Coding Format&nbsp;&nbsp;
    36713482                     <ul>
    3672                         <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.7">5.2.1</a></li>
    3673                         <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.9">5.2.2.1</a></li>
    3674                         <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.10">5.2.2.2</a></li>
    3675                         <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.11">5.2.2.3</a></li>
     3483                        <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.7">5.1.1</a></li>
     3484                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.9">5.1.2.1</a></li>
     3485                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.10">5.1.2.2</a></li>
     3486                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.11">5.1.2.3</a></li>
    36763487                     </ul>
    36773488                  </li>
    3678                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.2.2.1</a></li>
     3489                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.1.2.1</a></li>
    36793490                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3680                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.5</a>, <a href="#rfc.xref.header.connection.9">8.8</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
     3491                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
    36813492                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    36823493               </ul>
    36833494            </li>
    36843495            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    3685                   <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">8</a>, <a href="#rfc.iref.d.3"><b>8.3</b></a>, <a href="#rfc.xref.header.date.3">9.1</a></li>
    3686                   <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">5.2.2.2</a></li>
     3496                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">5.1.2.2</a></li>
    36873497                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.4</b></a></li>
    36883498               </ul>
    … …  
    36983508                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    36993509                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    3700                         <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>5.1</b></a></li>
    3701                         <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>5.2</b></a></li>
     3510                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>5.1</b></a></li>
    37023511                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    37033512                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>1.2.2</b></a></li>
    3704                         <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>5.2.1</b></a></li>
    3705                         <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>5.2.1</b></a></li>
    3706                         <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.2.1</b></a></li>
    3707                         <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.2.1</b></a></li>
    3708                         <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>5.2.1</b></a></li>
    3709                         <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>5.2.1</b></a></li>
    3710                         <li><tt>Chunked-Body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>5.2.1</b></a></li>
     3513                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>5.1.1</b></a></li>
     3514                        <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>5.1.1</b></a></li>
     3515                        <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>5.1.1</b></a></li>
     3516                        <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>5.1.1</b></a></li>
     3517                        <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>5.1.1</b></a></li>
     3518                        <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>5.1.1</b></a></li>
     3519                        <li><tt>Chunked-Body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>5.1.1</b></a></li>
    37113520                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.3</b></a></li>
    3712                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>8.1</b></a></li>
    3713                         <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>8.1</b></a></li>
    3714                         <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>8.2</b></a></li>
     3521                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>8.1</b></a></li>
     3522                        <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>8.1</b></a></li>
     3523                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>8.2</b></a></li>
    37153524                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    37163525                        <li>CRLF&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>1.2</b></a></li>
    37173526                        <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.3</b></a></li>
    37183527                        <li>CTL&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>1.2</b></a></li>
    3719                         <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>8.3</b></a></li>
    3720                         <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>5.1</b></a></li>
    3721                         <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>5.2</b></a></li>
    3722                         <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>5.2</b></a></li>
    3723                         <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>5.1</b></a></li>
    3724                         <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>5.1</b></a></li>
    3725                         <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>5.1</b></a></li>
     3528                        <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>5.1</b></a></li>
     3529                        <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>5.1</b></a></li>
    37263530                        <li>DIGIT&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>1.2</b></a></li>
    37273531                        <li>DQUOTE&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>1.2</b></a></li>
    … …  
    37293533                        <li><tt>field-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2</b></a></li>
    37303534                        <li><tt>field-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2</b></a></li>
    3731                         <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>5.1</b></a></li>
    37323535                        <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>3.2</b></a></li>
    37333536                        <li>HEXDIG&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>1.2</b></a></li>
    3734                         <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.94"><b>8.4</b></a></li>
    3735                         <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>5.1</b></a></li>
     3537                        <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>8.3</b></a></li>
    37363538                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    3737                         <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>5.1</b></a></li>
    37383539                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3</b></a></li>
    37393540                        <li><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.6</b></a></li>
    … …  
    37413542                        <li><tt>HTTP-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.6</b></a></li>
    37423543                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>2.7.2</b></a></li>
    3743                         <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>5.2.1</b></a></li>
     3544                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>5.1.1</b></a></li>
    37443545                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    37453546                        <li><tt>message-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.3</b></a></li>
    37463547                        <li><tt>Method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.1.1</b></a></li>
    3747                         <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>5.1</b></a></li>
    3748                         <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>5.1</b></a></li>
    3749                         <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>5.1</b></a></li>
    37503548                        <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.3</b></a></li>
    37513549                        <li>OCTET&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>1.2</b></a></li>
    … …  
    37533551                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    37543552                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7</b></a></li>
    3755                         <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.3</b></a></li>
    3756                         <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.3</b></a></li>
    3757                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.104"><b>8.9</b></a></li>
    3758                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.105"><b>8.9</b></a></li>
    3759                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.107"><b>8.9</b></a></li>
     3553                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>5.2</b></a></li>
     3554                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>5.2</b></a></li>
     3555                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.8</b></a></li>
     3556                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.8</b></a></li>
     3557                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>8.8</b></a></li>
    37603558                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.3</b></a></li>
    3761                         <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.2.1</b></a></li>
     3559                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>5.1.1</b></a></li>
    37623560                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7</b></a></li>
    37633561                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.3</b></a></li>
    37643562                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.3</b></a></li>
    3765                         <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>5.2.1</b></a></li>
     3563                        <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>5.1.1</b></a></li>
    37663564                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.3</b></a></li>
    3767                         <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>5.4</b></a></li>
     3565                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>5.3</b></a></li>
    37683566                        <li><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>3.1.2.2</b></a></li>
    3769                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.106"><b>8.9</b></a></li>
    3770                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.103"><b>8.9</b></a></li>
     3567                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.8</b></a></li>
     3568                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.8</b></a></li>
    37713569                        <li><tt>Request-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.1</b></a></li>
    37723570                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.1.2</b></a></li>
    3773                         <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>5.1</b></a></li>
    3774                         <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>5.1</b></a></li>
    37753571                        <li><tt>RWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>1.2.2</b></a></li>
    3776                         <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>5.1</b></a></li>
    37773572                        <li>SP&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>1.2</b></a></li>
    37783573                        <li><tt>special</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.3</b></a></li>
    … …  
    37803575                        <li><tt>Status-Code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>3.1.2.1</b></a></li>
    37813576                        <li><tt>Status-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>3.1.2</b></a></li>
    3782                         <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.96"><b>8.5</b></a></li>
     3577                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>8.4</b></a></li>
    37833578                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.3</b></a></li>
    3784                         <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.95"><b>8.5</b></a></li>
    3785                         <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.98"><b>8.5</b></a></li>
    3786                         <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.97"><b>8.5</b></a></li>
    3787                         <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>5.1</b></a></li>
     3579                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>8.4</b></a></li>
     3580                        <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>8.4</b></a></li>
     3581                        <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>8.4</b></a></li>
    37883582                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.3</b></a></li>
    3789                         <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.99"><b>8.6</b></a></li>
    3790                         <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>5.2.1</b></a></li>
    3791                         <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>5.2</b></a></li>
    3792                         <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.100"><b>8.7</b></a></li>
    3793                         <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>5.2</b></a></li>
    3794                         <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>5.2</b></a></li>
    3795                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.101"><b>8.8</b></a></li>
     3583                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>8.5</b></a></li>
     3584                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>5.1.1</b></a></li>
     3585                        <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>5.1</b></a></li>
     3586                        <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>8.6</b></a></li>
     3587                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>5.1</b></a></li>
     3588                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>5.1</b></a></li>
     3589                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.7</b></a></li>
    37963590                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.7</b></a></li>
    37973591                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    3798                         <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>5.2</b></a></li>
     3592                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>5.1</b></a></li>
    37993593                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3800                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.102"><b>8.9</b></a></li>
     3594                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.8</b></a></li>
    38013595                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.3</b></a></li>
    3802                         <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>5.1</b></a></li>
    38033596                     </ul>
    38043597                  </li>
    3805                   <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.86">5.2.2.3</a></li>
     3598                  <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.70">5.1.2.3</a></li>
    38063599               </ul>
    38073600            </li>
    … …  
    38103603                  <li>Header Fields&nbsp;&nbsp;
    38113604                     <ul>
    3812                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.5</a>, <a href="#rfc.xref.header.connection.9">8.8</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
     3605                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
    38133606                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    3814                         <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">8</a>, <a href="#rfc.iref.h.8"><b>8.3</b></a>, <a href="#rfc.xref.header.date.3">9.1</a></li>
    3815                         <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.10"><b>8.4</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
    3816                         <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.2</a>, <a href="#rfc.xref.header.te.2">5.2.1</a>, <a href="#rfc.xref.header.te.3">5.4</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.h.11"><b>8.5</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
    3817                         <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.2.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
    3818                         <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    3819                         <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    3820                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.15"><b>8.9</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3607                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3608                        <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.h.10"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
     3609                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.h.11"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3610                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
     3611                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3612                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    38213613                     </ul>
    38223614                  </li>
    38233615                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    38243616                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3825                   <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.4</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3617                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.8"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
    38263618                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    38273619                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    … …  
    38633655            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38643656                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    3865                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">4.1</a>, <a href="#rfc.xref.Part2.8">6.1.2.2</a>, <a href="#rfc.xref.Part2.9">6.1.4</a>, <a href="#rfc.xref.Part2.10">6.2.3</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">8.8</a>, <a href="#rfc.xref.Part2.15">10.6</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3657                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">8.7</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
    38663658                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
    3867                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
     3659                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    38683660                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
    3869                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">6.1.2.2</a>, <a href="#rfc.xref.Part2.9">6.1.4</a></li>
    3870                         <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">4.1</a></li>
    3871                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">6.2.3</a></li>
    3872                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a></li>
     3661                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a></li>
     3662                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">4.1</a></li>
     3663                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">6.2.3</a></li>
     3664                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.2.3</a></li>
    38733665                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a></li>
    3874                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">8.8</a></li>
    3875                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">10.6</a></li>
    3876                         <li><em>Section 7.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.15">10.6</a></li>
    3877                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a></li>
     3666                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">8.7</a></li>
     3667                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">10.6</a></li>
     3668                        <li><em>Section 7.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.16">10.6</a></li>
     3669                        <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
     3670                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a></li>
    38783671                     </ul>
    38793672                  </li>
    3880                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">5.2.3</a>, <a href="#rfc.xref.Part3.3">5.4</a>, <a href="#rfc.xref.Part3.4">6.1.3.2</a>, <a href="#rfc.xref.Part3.5">8.7</a>, <a href="#Part3"><b>12.1</b></a><ul>
    3881                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">5.2.3</a>, <a href="#rfc.xref.Part3.5">8.7</a></li>
    3882                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">5.4</a></li>
     3673                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">5.1.3</a>, <a href="#rfc.xref.Part3.3">5.3</a>, <a href="#rfc.xref.Part3.4">6.1.3.2</a>, <a href="#rfc.xref.Part3.5">8.6</a>, <a href="#Part3"><b>12.1</b></a><ul>
     3674                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">5.1.3</a>, <a href="#rfc.xref.Part3.5">8.6</a></li>
     3675                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">5.3</a></li>
    38833676                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
    38843677                     </ul>
    … …  
    39003693                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li>
    39013694                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.4</b></a></li>
    3902                   <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">5.1</a>, <a href="#rfc.xref.RFC1123.2">5.1</a>, <a href="#RFC1123"><b>12.2</b></a><ul>
    3903                         <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">5.1</a></li>
    3904                      </ul>
    3905                   </li>
    39063695                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>12.2</b></a></li>
    39073696                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
    3908                   <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">5.2.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
    3909                   <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">5.2.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
    3910                   <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">5.2.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
    3911                   <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5.2</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
    3912                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">5.2</a></li>
     3697                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
     3698                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
     3699                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">5.1.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
     3700                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
     3701                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">5.1</a></li>
    39133702                     </ul>
    39143703                  </li>
    … …  
    39513740                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li>
    39523741                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.2</a>, <a href="#RFC4559"><b>12.2</b></a></li>
    3953                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.2.3</a>, <a href="#rfc.xref.RFC5226.2">8.8.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
    3954                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.2.3</a>, <a href="#rfc.xref.RFC5226.2">8.8.1</a></li>
     3742                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
     3743                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a></li>
    39553744                     </ul>
    39563745                  </li>
    … …  
    39593748                     </ul>
    39603749                  </li>
    3961                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.1</a>, <a href="#rfc.xref.RFC5322.4">8.3</a>, <a href="#rfc.xref.RFC5322.5">8.9</a>, <a href="#RFC5322"><b>12.2</b></a><ul>
    3962                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.1</a></li>
    3963                         <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">8.3</a></li>
    3964                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.5">8.9</a></li>
     3750                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8.8</a>, <a href="#RFC5322"><b>12.2</b></a><ul>
     3751                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">8.8</a></li>
    39653752                     </ul>
    39663753                  </li>
    … …  
    39773764            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    39783765                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.4"><b>4.3</b></a></li>
    3979                   <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.2</a>, <a href="#rfc.xref.header.te.2">5.2.1</a>, <a href="#rfc.xref.header.te.3">5.4</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.t.5"><b>8.5</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
     3766                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.t.5"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
    39803767                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li>
    3981                   <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.2.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.6</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
    3982                   <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
     3768                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3769                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    39833770                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.4</b></a></li>
    39843771                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.4</b></a></li>
    … …  
    39873774            </li>
    39883775            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3989                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.8</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3776                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    39903777                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li>
    39913778                  <li>URI scheme&nbsp;&nbsp;
    … …  
    40003787            </li>
    40013788            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    4002                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.9</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3789                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    40033790               </ul>
    40043791            </li>

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

    r1436 r1440  
    42484248    </author>
    42494249    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
     4250      <organization>Rackspace</organization>
    42504251      <address><email>mnot@mnot.net</email></address>
    42514252    </author>

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

    r1436 r1440  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 5, 2012";
     361       content: "Expires March 12, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2011-09-02">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-09-09">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: March 5, 2012</td>
     442               <td class="left">Expires: March 12, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">September 2, 2011</td>
     495               <td class="right">September 9, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    523523         in progress”.
    524524      </p>
    525       <p>This Internet-Draft will expire on March 5, 2012.</p>
     525      <p>This Internet-Draft will expire on March 12, 2012.</p>
    526526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    527527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    931931               <tr>
    932932                  <td class="left">If-Match</td>
    933                   <td class="left"><a href="p4-conditional.html#header.if-match" title="ERROR: Anchor 'header.if-match' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-match' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     933                  <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    934934               </tr>
    935935               <tr>
    936936                  <td class="left">If-Modified-Since</td>
    937                   <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="ERROR: Anchor 'header.if-modified-since' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-modified-since' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     937                  <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    938938               </tr>
    939939               <tr>
    940940                  <td class="left">If-None-Match</td>
    941                   <td class="left"><a href="p4-conditional.html#header.if-none-match" title="ERROR: Anchor 'header.if-none-match' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-none-match' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     941                  <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    942942               </tr>
    943943               <tr>
    … …  
    947947               <tr>
    948948                  <td class="left">If-Unmodified-Since</td>
    949                   <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="ERROR: Anchor 'header.if-unmodified-since' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-unmodified-since' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     949                  <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    950950               </tr>
    951951               <tr>
    … …  
    10071007               <tr>
    10081008                  <td class="left">ETag</td>
    1009                   <td class="left"><a href="p4-conditional.html#header.etag" title="ERROR: Anchor 'header.etag' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.etag' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1009                  <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    10101010               </tr>
    10111011               <tr>
    … …  
    10501050      </p>
    10511051      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    1052       <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section&nbsp;7</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="ERROR: Anchor 'status.code.definitions' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.code.definitions' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
     1052      <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section&nbsp;7</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
    10531053         protocol.
    10541054      </p>
    … …  
    11311131                  <td class="left">304</td>
    11321132                  <td class="left">Not Modified</td>
    1133                   <td class="left"><a href="p4-conditional.html#status.304" title="ERROR: Anchor 'status.304' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.304' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1133                  <td class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    11341134               </tr>
    11351135               <tr>
    … …  
    12061206                  <td class="left">412</td>
    12071207                  <td class="left">Precondition Failed</td>
    1208                   <td class="left"><a href="p4-conditional.html#status.412" title="ERROR: Anchor 'status.412' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.412' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1208                  <td class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    12091209               </tr>
    12101210               <tr>
    … …  
    16451645      </p>
    16461646      <p id="rfc.section.7.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource
    1647          just created (see <a href="p4-conditional.html#header.etag" title="ERROR: Anchor 'header.etag' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.etag' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
     1647         just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    16481648      </p>
    16491649      <div id="rfc.iref.26"></div>
    … …  
    18211821      <h3 id="rfc.section.7.3.5"><a href="#rfc.section.7.3.5">7.3.5</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h3>
    18221822      <p id="rfc.section.7.3.5.p.1">The response to the request has not been modified since the conditions indicated by the client's conditional GET request,
    1823          as defined in <a href="p4-conditional.html#status.304" title="ERROR: Anchor 'status.304' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.304' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     1823         as defined in <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    18241824      </p>
    18251825      <div id="rfc.iref.36"></div>
    … …  
    19541954      <h3 id="rfc.section.7.4.13"><a href="#rfc.section.7.4.13">7.4.13</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h3>
    19551955      <p id="rfc.section.7.4.13.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server, as defined
    1956          in <a href="p4-conditional.html#status.412" title="ERROR: Anchor 'status.412' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.412' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     1956         in <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    19571957      </p>
    19581958      <div id="rfc.iref.52"></div>
    … …  
    28362836         <tr>
    28372837            <td class="reference"><b id="Part6">[Part6]</b></td>
    2838             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
     2838            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
    28392839            </td>
    28402840         </tr>
    … …  
    35653565                  </li>
    35663566                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3.5</a>, <a href="#rfc.xref.Part4.11">7.4.13</a>, <a href="#Part4"><b>13.1</b></a>, <a href="#rfc.xref.Part4.12">C.2</a><ul>
    3567                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a></li>
    3568                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.2</a></li>
    3569                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">3.2</a></li>
    3570                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">3.2</a></li>
    3571                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li>
    3572                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">4.1</a></li>
    3573                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10">7.3.5</a></li>
    3574                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.11">7.4.13</a></li>
     3567                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li>
     3568                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a></li>
     3569                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">3.2</a></li>
     3570                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.2</a></li>
     3571                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">3.2</a></li>
     3572                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">4.1</a></li>
     3573                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10">7.3.5</a></li>
     3574                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.11">7.4.13</a></li>
    35753575                     </ul>
    35763576                  </li>

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

    r1436 r1440  
    35703570    </author>
    35713571    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
     3572      <organization>Rackspace</organization>
    35723573      <address><email>mnot@mnot.net</email></address>
    35733574    </author>

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

    r1426 r1440  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 4, 2012";
     361       content: "Expires March 12, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-09-01">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-09-09">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: March 4, 2012</td>
     436               <td class="left">Expires: March 12, 2012</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    491491            <tr>
    492492               <td class="left"></td>
    493                <td class="right">September 1, 2011</td>
     493               <td class="right">September 9, 2011</td>
    494494            </tr>
    495495         </tbody>
    … …  
    519519         in progress”.
    520520      </p>
    521       <p>This Internet-Draft will expire on March 4, 2012.</p>
     521      <p>This Internet-Draft will expire on March 12, 2012.</p>
    522522      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    523523      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    685685      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>   = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    686686  <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    687   <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a>&gt;
     687  <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a>&gt;
    688688</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    689689      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2>
    … …  
    717717      </p>
    718718      <ul class="empty">
    719          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     719         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    720720         </li>
    721721      </ul>
    … …  
    723723      </p>
    724724      <ul class="empty">
    725          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     725         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    726726         </li>
    727727      </ul>
    … …  
    729729      </p>
    730730      <ul class="empty">
    731          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     731         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    732732         </li>
    733733      </ul>
    … …  
    741741         <li>Pointer to specification text</li>
    742742      </ul>
    743       <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 6.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     743      <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    744744      </p>
    745745      <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
    … …  
    841841               <tr>
    842842                  <td class="left">Content-Length</td>
    843                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     843                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    844844               </tr>
    845845               <tr>
    … …  
    987987         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
    988988      </p>
    989       <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
     989      <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
    990990      </p>
    991991      <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    992          and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
     992         and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    993993         within extension header fields not defined by this specification.
    994994      </p>
    … …  
    10401040      <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
    10411041         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    1042          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
     1042         agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
    10431043      </p>
    10441044      <div class="note" id="rfc.section.6.1.p.5">
    … …  
    11701170         </li>
    11711171         <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable
    1172             unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
     1172            unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    11731173         </li>
    11741174         <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
    … …  
    14321432                  <td class="left">compress</td>
    14331433                  <td class="left">UNIX "compress" program method</td>
    1434                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1434                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14351435                  </td>
    14361436               </tr>
    … …  
    14391439                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    14401440                  </td>
    1441                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1441                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14421442                  </td>
    14431443               </tr>
    … …  
    14451445                  <td class="left">gzip</td>
    14461446                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    1447                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1447                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14481448                  </td>
    14491449               </tr>
    … …  
    14821482      </p>
    14831483      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1484       <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1484      <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    14851485      </p>
    14861486      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    … …  
    15111511         <tr>
    15121512            <td class="reference"><b id="Part6">[Part6]</b></td>
    1513             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
     1513            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
    15141514            </td>
    15151515         </tr>
    … …  
    17031703      </p>
    17041704      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
    1705       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     1705      <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    17061706      </p>
    17071707      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
    … …  
    17201720      </p>
    17211721      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
    1722       <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
     1722      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
    17231723      </p>
    17241724      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    … …  
    17971797<a href="#abnf.dependencies" class="smpl">partial-URI</a> = &lt;partial-URI, defined in [Part1], Section 2.7&gt;
    17981798
    1799 <a href="#abnf.dependencies" class="smpl">qvalue</a> = &lt;qvalue, defined in [Part1], Section 6.4&gt;
     1799<a href="#abnf.dependencies" class="smpl">qvalue</a> = &lt;qvalue, defined in [Part1], Section 5.3&gt;
    18001800
    18011801<a href="#media.types" class="smpl">subtype</a> = token
    … …  
    21212121            </li>
    21222122            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2123                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.24">A.3</a>, <a href="#rfc.xref.Part1.25">A.6</a><ul>
     2123                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.24">A.6</a><ul>
    21242124                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
    21252125                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.3.1</a></li>
    … …  
    21282128                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.2</a></li>
    21292129                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.7</a></li>
    2130                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">A.3</a></li>
    2131                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2.1</a></li>
    2132                         <li><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li>
    2133                         <li><em>Section 6.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
    2134                         <li><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
    2135                         <li><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
    2136                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li>
    2137                         <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">3.1</a></li>
    2138                         <li><em>Section 9.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">A.6</a></li>
    2139                         <li><em>Section 12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">9</a></li>
     2130                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2.1</a></li>
     2131                        <li><em>Section 5.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li>
     2132                        <li><em>Section 5.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
     2133                        <li><em>Section 5.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
     2134                        <li><em>Section 5.1.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
     2135                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li>
     2136                        <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">3.1</a></li>
     2137                        <li><em>Section 8.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">A.6</a></li>
     2138                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">9</a></li>
    21402139                     </ul>
    21412140                  </li>
    2142                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a><ul>
    2143                         <li><em>Section 8.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
     2141                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.2">A.3</a><ul>
     2142                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">A.3</a></li>
     2143                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
    21442144                     </ul>
    21452145                  </li>

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

    r1436 r1440  
    18431843    </author>
    18441844    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
     1845      <organization>Rackspace</organization>
    18451846      <address><email>mnot@mnot.net</email></address>
    18461847    </author>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r1437 r1440  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 6, 2012";
     361       content: "Expires March 12, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-09-03">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-09-09">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    430430            </tr>
    431431            <tr>
    432                <td class="left">Expires: March 6, 2012</td>
     432               <td class="left">Expires: March 12, 2012</td>
    433433               <td class="right">J. Mogul</td>
    434434            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">September 3, 2011</td>
     489               <td class="right">September 9, 2011</td>
    490490            </tr>
    491491         </tbody>
    … …  
    517517         in progress”.
    518518      </p>
    519       <p>This Internet-Draft will expire on March 6, 2012.</p>
     519      <p>This Internet-Draft will expire on March 12, 2012.</p>
    520520      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521521      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    12201220         <tr>
    12211221            <td class="reference"><b id="Part6">[Part6]</b></td>
    1222             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
     1222            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
    12231223            </td>
    12241224         </tr>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1437 r1440  
    14211421    </author>
    14221422    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
     1423      <organization>Rackspace</organization>
    14231424      <address><email>mnot@mnot.net</email></address>
    14241425    </author>

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

    r1436 r1440  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 5, 2012";
     361       content: "Expires March 12, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    406406      <meta name="dct.creator" content="Reschke, J. F.">
    407407      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    408       <meta name="dct.issued" scheme="ISO8601" content="2011-09-02">
     408      <meta name="dct.issued" scheme="ISO8601" content="2011-09-09">
    409409      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    410410      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    432432            </tr>
    433433            <tr>
    434                <td class="left">Expires: March 5, 2012</td>
     434               <td class="left">Expires: March 12, 2012</td>
    435435               <td class="right">J. Mogul</td>
    436436            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">September 2, 2011</td>
     491               <td class="right">September 9, 2011</td>
    492492            </tr>
    493493         </tbody>
    … …  
    517517         in progress”.
    518518      </p>
    519       <p>This Internet-Draft will expire on March 5, 2012.</p>
     519      <p>This Internet-Draft will expire on March 12, 2012.</p>
    520520      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521521      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r1426 r1440  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 4, 2012";
     361       content: "Expires March 12, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-09-01">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-09-09">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: March 4, 2012</td>
     437               <td class="left">Expires: March 12, 2012</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">September 1, 2011</td>
     490               <td class="right">September 9, 2011</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on March 4, 2012.</p>
     518      <p>This Internet-Draft will expire on March 12, 2012.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    944944         Lawrence C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
    945945      </p>
    946       <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision.
     946      <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision.
    947947      </p>
    948948      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
    … …  
    958958         <tr>
    959959            <td class="reference"><b id="Part6">[Part6]</b></td>
    960             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
     960            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2011.
    961961            </td>
    962962         </tr>
    … …  
    12351235                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li>
    12361236                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">2.2</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a></li>
    1237                         <li><em>Section 12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">7</a></li>
     1237                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">7</a></li>
    12381238                     </ul>
    12391239                  </li>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r1426 r1440  
    911911    </author>
    912912    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
     913      <organization>Rackspace</organization>
    913914      <address><email>mnot@mnot.net</email></address>
    914915    </author>
Note: See TracChangeset for help on using the changeset viewer.