Changeset 853


Ignore:
Timestamp:
Jul 16, 2010, 10:57:33 PM (9 years ago)
Author:
fielding@…
Message:

regenerate html

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

Legend:

Unmodified
Added
Removed

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

    r849 r853  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-07-12">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
    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 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: January 13, 2011</td>
     437               <td class="left">Expires: January 17, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">July 12, 2010</td>
     490               <td class="right">July 16, 2010</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire in January 13, 2011.</p>
     518      <p>This Internet-Draft will expire in January 17, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    562562               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a></li>
    563563               <li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a></li>
    564                <li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#message.length">Message Length</a></li>
    565                <li class="tocline1">3.5&nbsp;&nbsp;&nbsp;<a href="#general.header.fields">General Header Fields</a></li>
     564               <li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#general.header.fields">General Header Fields</a></li>
    566565            </ul>
    567566         </li>
    … …  
    801800      <h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="basic.rules" href="#basic.rules">Basic Rules</a></h3>
    802801      <div id="rule.CRLF">
    803          <p id="rfc.section.1.2.2.p.1">  HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described
    804             in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</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>.
     802         <p id="rfc.section.1.2.2.p.1">  HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements other than the message-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for tolerant applications).
    805803         </p>
    806804      </div>
    … …  
    861859      <div id="rfc.figure.u.12"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">request-header</a>  = &lt;request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>&gt;
    862860  <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>&gt;
    863 </pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">entity-body</a>     = &lt;entity-body, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.body" title="Entity Body">Section 3.2</a>&gt;
    864   <a href="#abnf.dependencies" class="smpl">entity-header</a>   = &lt;entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>&gt;
     861</pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">entity-header</a>   = &lt;entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>&gt;
    865862</pre><div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    866863  <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    … …  
    11221119      <p id="rfc.section.3.p.2">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two
    11231120         types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses),
    1124          and in the algorithm for determining the length of the message-body (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
     1121         and in the algorithm for determining the length of the message-body (<a href="#message.body.length">Paragraph&nbsp;7</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
    11251122         start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown
    11261123         or invalid request method) and clients are implemented to only expect a response.
    … …  
    11451142      <p id="rfc.section.3.1.p.3">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a
    11461143         hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If
    1147          a message-body has been indicated, then it is read as a stream until an amount of OCTETs equal to the message-length is read
    1148          or the connection is closed. Care must be taken to parse an HTTP message as a sequence of OCTETs in an encoding that is a
    1149          superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16 may introduce
    1150          security flaws due to the differing ways that such parsers interpret invalid characters.
     1144         a message-body has been indicated, then it is read as a stream until an amount of octets equal to the message-body length
     1145         is read or the connection is closed. Care must be taken to parse an HTTP message as a sequence of octets in an encoding that
     1146         is a superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16
     1147         may introduce security flaws due to the differing ways that such parsers interpret invalid characters.
    11511148      </p>
    11521149      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h2>
    … …  
    12041201      </p>
    12051202      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
    1206       <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The
    1207          message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
     1203      <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response. The
     1204         message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
    12081205         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;9.7</a>).
    12091206      </p>
    1210       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>
    1211                / &lt;entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>&gt;
    1212 </pre><p id="rfc.section.3.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding
    1213          is a property of the message, not of the entity, and thus <em class="bcp14">MAY</em> be added or removed by any application along the request/response chain. (However, <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a> places restrictions on when certain transfer-codings may be used.)
     1207      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
     1208</pre><p id="rfc.section.3.3.p.3">When one or more transfer-codings are applied to a payload body, usually for the sake of stream-delimiting or data compression,
     1209         the Transfer-Encoding header field <em class="bcp14">MUST</em> be provided with the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload,
     1210         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;6.2</a>.
    12141211      </p>
    12151212      <p id="rfc.section.3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    12161213      <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    1217          in the request's header fields. When a request message contains both a message-body of non-zero length and a method that does
    1218          not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented
    1219          the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response.
     1214         in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
     1215         message framing algorithm to be independent of method semantics. A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response.
    12201216      </p>
    12211217      <p id="rfc.section.3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
    1222          the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section&nbsp;5.1.1</a>). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (Informational),
    1223          204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length.
    1224       </p>
    1225       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="message.length" href="#message.length">Message Length</a></h2>
    1226       <p id="rfc.section.3.4.p.1">The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings
    1227          have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of
    1228          the following (in order of precedence):
    1229       </p>
    1230       <p id="rfc.section.3.4.p.2"> </p>
     1218         the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section&nbsp;5.1.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,
     1219         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the method had been GET. All 1xx
     1220         (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
     1221      </p>
     1222      <div id="message.body.length">
     1223         <p id="rfc.section.3.3.p.7">The length of the message-body is determined by one of the following (in order of precedence):</p>
     1224      </div>
     1225      <p id="rfc.section.3.3.p.8"> </p>
    12311226      <ol>
    12321227         <li>
    1233             <p>Any response message which "<em class="bcp14">MUST NOT</em>" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated
    1234                by the first empty line after the header fields, regardless of the entity-header fields present in the message.
     1228            <p>Any response to a HEAD request and any response with a status code of 100-199, 204, or 304 is always terminated by the first
     1229               empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message-body.
    12351230            </p>
    12361231         </li>
    12371232         <li>
    1238             <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>) is used, the transfer-length is defined by the use of this transfer-coding. If a Transfer-Encoding header field is present
    1239                and the "chunked" transfer-coding is not present, the transfer-length is defined by the sender closing the connection.
     1233            <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>) is used, the message-body length is determined by reading and decoding the chunked data until the transfer-coding indicates
     1234               the data is complete.
    12401235            </p>
     1236            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
     1237               overrides the Content-Length. Such a message may indicate an attempt to perform request or response smuggling (bypass of security-related
     1238               checks on message routing or content) and thus should be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding
     1239               is decoded.
     1240            </p>
     1241            <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not present, the message-body
     1242               length is determined by reading the connection until it is closed. If a Transfer-Encoding header field is present in a request
     1243               and the "chunked" transfer-coding is not present, the message-body length cannot be determined reliably; the server <em class="bcp14">MUST</em> respond with 400 (Bad Request) and then close the connection.
     1244            </p>
    12411245         </li>
    12421246         <li>
    1243             <p>If a Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;9.2</a>) is present, its value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field <em class="bcp14">MUST NOT</em> be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received
    1244                with both a Transfer-Encoding header field and a Content-Length header field, the latter <em class="bcp14">MUST</em> be ignored.
     1247            <p>If a valid Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;9.2</a>) is present without Transfer-Encoding, its decimal value in octets defines the message-body length. If the actual number
     1248               of octets sent in the message is less than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in
     1249               the message is less than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message-body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on on a connection
     1250               and the connection has been closed by the server.
    12451251            </p>
     1252            <p>If a message is received with multiple Content-Length header fields or a Content-Length header field with an invalid value,
     1253               the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status and then close the connection. If this is a response message received by a proxy or
     1254               gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status as its downstream response, and then close the connection.
     1255               If this is a response message received by a user-agent, the message-body length is determined by reading the connection until
     1256               it is closed; an error <em class="bcp14">SHOULD</em> be indicated to the user.
     1257            </p>
    12461258         </li>
    12471259         <li>
    1248             <p>If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self-delimiting
    1249                media type defines the transfer-length. This media type <em class="bcp14">MUST NOT</em> be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple
    1250                byte-range specifiers from a HTTP/1.1 client implies that the client can parse multipart/byteranges responses.
     1260            <p>If this is a request message and none of the above are true, then the message-body length is zero (no message-body is present).</p>
     1261         </li>
     1262         <li>
     1263            <p>Otherwise, this is a response message without a declared message-body length, so the message-body length is determined by
     1264               the number of octets received prior to the server closing the connection.
    12511265            </p>
    1252             <ul class="empty">
    1253                <li>A range header might be forwarded by a HTTP/1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.
    1254                </li>
    1255             </ul>
    1256          </li>
    1257          <li>
    1258             <p>By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since
    1259                that would leave no possibility for the server to send back a response.)
    1260             </p>
    12611266         </li>
    12621267      </ol>
    1263       <p id="rfc.section.3.4.p.3">For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body
    1264          and a Content-Length is not given, the server <em class="bcp14">SHOULD</em> respond with 400 (Bad Request) if it cannot determine the length of the message, or with 411 (Length Required) if it wishes
    1265          to insist on receiving a valid Content-Length.
    1266       </p>
    1267       <p id="rfc.section.3.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
    1268       </p>
    1269       <p id="rfc.section.3.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.
    1270       </p>
    1271       <p id="rfc.section.3.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected.
    1272       </p>
    1273       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2>
    1274       <p id="rfc.section.3.5.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply
    1275          to the entity being transferred. These header fields apply only to the message being transmitted.
    1276       </p>
    1277       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>
     1268      <p id="rfc.section.3.3.p.9">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
     1269         by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
     1270         with HTTP/1.0.
     1271      </p>
     1272      <p id="rfc.section.3.3.p.10">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required).
     1273      </p>
     1274      <p id="rfc.section.3.3.p.11">A client that sends a request containing a message-body <em class="bcp14">SHOULD</em> include a valid Content-Length header field if the message-body length is known in advance, since many existing services will
     1275         otherwise respond with a 411 (Length Required) status code though they can handle the chunked encoding. This is typically
     1276         because such services are implemented via a gateway that requires a content-length in advance of being called and the server
     1277         is unable or unwilling to buffer the entire request before processing.
     1278      </p>
     1279      <p id="rfc.section.3.3.p.12">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
     1280         knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.
     1281      </p>
     1282      <p id="rfc.section.3.3.p.13">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the given number
     1283         of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an
     1284         error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1285      </p>
     1286      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2>
     1287      <p id="rfc.section.3.4.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply
     1288         to the payload being transferred. These header fields apply only to the message being transmitted.
     1289      </p>
     1290      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>
    12781291                 / <a href="#header.connection" class="smpl">Connection</a>               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>
    12791292                 / <a href="#header.date" class="smpl">Date</a>                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;9.3</a>
    1280                  / <a href="#abnf.dependencies" class="smpl">Pragma</a>                   ; <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>
     1293                 / <a href="#abnf.dependencies" class="smpl">Pragma</a>                   ; <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>
    12811294                 / <a href="#header.trailer" class="smpl">Trailer</a>                  ; <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;9.6</a>
    12821295                 / <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>        ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;9.7</a>
    12831296                 / <a href="#header.upgrade" class="smpl">Upgrade</a>                  ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;9.8</a>
    12841297                 / <a href="#header.via" class="smpl">Via</a>                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>
    1285                  / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
    1286 </pre><p id="rfc.section.3.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
     1298                 / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
     1299</pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    12871300         or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize
    12881301         them to be general-header fields. Unrecognized header fields are treated as entity-header fields.
    … …  
    12931306      </p>
    12941307      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;4.1</a>
    1295                   *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.5</a>
     1308                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
    12961309                   / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>
    1297                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1310                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
    12981311                  <a href="#core.rules" class="smpl">CRLF</a>
    12991312                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
    … …  
    13591372         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13601373      </p>
    1361       <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.
     1374      <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets.
    13621375      </p>
    13631376      <div class="note" id="rfc.section.4.1.2.p.21">
    … …  
    14231436      <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
    14241437      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;5.1</a>
    1425                   *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.5</a>
     1438                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
    14261439                   / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>
    1427                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1440                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
    14281441                  <a href="#core.rules" class="smpl">CRLF</a>
    14291442                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
    … …  
    14541467</pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    14551468      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2>
    1456       <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps.</p>
    1457       <p id="rfc.section.6.1.p.2">The first format is preferred as an Internet standard and represents 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>:
     1469      <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is
     1470        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>:
    14581471      </p>
    14591472      <div id="rfc.figure.u.45"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
    1460 </pre><p id="rfc.section.6.1.p.4">The other formats are described here only for compatibility with obsolete implementations.</p>
     1473</pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
    14611474      <div id="rfc.figure.u.46"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    14621475Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    1463 </pre><p id="rfc.section.6.1.p.6">HTTP/1.1 clients and servers that parse the 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. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for further information.
    1464       </p>
    1465       <p id="rfc.section.6.1.p.7">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
     1476</pre><p id="rfc.section.6.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. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for further information.
     1477      </p>
     1478      <p id="rfc.section.6.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
    14661479         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    14671480         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.
    … …  
    14691482      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
    14701483</pre><div id="preferred.date.format">
    1471          <p id="rfc.section.6.1.p.9">                    Preferred format:</p>
     1484         <p id="rfc.section.6.1.p.8">                    Preferred format:</p>
    14721485      </div>
    14731486      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    … …  
    15071520  <a href="#preferred.date.format" class="smpl">minute</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
    15081521  <a href="#preferred.date.format" class="smpl">second</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
    1509 </pre><p id="rfc.section.6.1.p.11">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>).
     1522</pre><p id="rfc.section.6.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>).
    15101523      </p>
    15111524      <div id="obsolete.date.formats">
    1512          <p id="rfc.section.6.1.p.12">                Obsolete formats:</p>
     1525         <p id="rfc.section.6.1.p.11">                Obsolete formats:</p>
    15131526      </div>
    15141527      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.69"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>
    … …  
    15271540  <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> ))
    15281541                 ; month day (e.g., Jun  2)
    1529 </pre><div class="note" id="rfc.section.6.1.p.16">
     1542</pre><div class="note" id="rfc.section.6.1.p.15">
    15301543         <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,
    15311544            as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
    15321545         </p>
    15331546      </div>
    1534       <div class="note" id="rfc.section.6.1.p.17">
     1547      <div class="note" id="rfc.section.6.1.p.16">
    15351548         <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
    15361549            are not required to use these formats for user presentation, request logging, etc.
    … …  
    15391552      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
    15401553      <p id="rfc.section.6.2.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to
    1541          an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding
    1542          is a property of the message, not of the original entity.
     1554         a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding
     1555         is a property of the message rather than a property of the representation that is being transferred.
    15431556      </p>
    15441557      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>
    … …  
    15561569</pre><p id="rfc.section.6.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;9.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;9.7</a>).
    15571570      </p>
    1558       <p id="rfc.section.6.2.p.6">Whenever a transfer-coding is applied to a message-body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding
    1559          is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message
    1560          (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>).
     1571      <p id="rfc.section.6.2.p.6">Whenever a transfer-coding is applied to a payload body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding
     1572         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 to a message-body. These rules allow the recipient to determine the message-body length of the message
     1573         (<a href="#message.body.length">Paragraph&nbsp;7</a>).
    15611574      </p>
    15621575      <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
    15631576         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
    1564          of message-bodies is the difficulty in determining the exact body length (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>), or the desire to encrypt data over a shared transport.
    1565       </p>
    1566       <p id="rfc.section.6.2.p.8">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
     1577         of message-bodies is the difficulty in determining the exact body length (<a href="#message.body.length">Paragraph&nbsp;7</a>), or the desire to encrypt data over a shared transport.
     1578      </p>
     1579      <p id="rfc.section.6.2.p.8">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.
    15671580      </p>
    15681581      <div id="rfc.iref.c.5"></div>
    … …  
    16201633  while (chunk-size &gt; 0) {
    16211634     read chunk-data and CRLF
    1622      append chunk-data to entity-body
     1635     append chunk-data to decoded-body
    16231636     length := length + chunk-size
    16241637     read chunk-size and CRLF
    16251638  }
    1626   read entity-header
    1627   while (entity-header not empty) {
    1628      append entity-header to existing header fields
    1629      read entity-header
     1639  read header-field
     1640  while (header-field not empty) {
     1641     append header-field to existing header fields
     1642     read header-field
    16301643  }
    16311644  Content-Length := length
    16321645  Remove "chunked" from Transfer-Encoding
    1633 </pre><p id="rfc.section.6.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.
     1646</pre><p id="rfc.section.6.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.
    16341647      </p>
    16351648      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>
    … …  
    16731686         <li>Pointer to specification text</li>
    16741687      </ul>
    1675       <p id="rfc.section.6.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.7"><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;6.2.2</a>).
     1688      <p id="rfc.section.6.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.5"><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;6.2.2</a>).
    16761689      </p>
    16771690      <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require expert review and a specification (see "Expert Review" and "Specification Required"
    … …  
    16931706      </p>
    16941707      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1695       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.8"><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
     1708      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><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
    16961709         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
    16971710         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.
    … …  
    17501763      <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    17511764      </p>
    1752       <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.length" title="Message Length">Section&nbsp;3.4</a>.
     1765      <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body.length">Paragraph&nbsp;7</a>.
    17531766      </p>
    17541767      <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
    … …  
    18181831         <li>Content-Type</li>
    18191832      </ul>
    1820       <p id="rfc.section.7.1.3.2.p.6">A non-transparent proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1833      <p id="rfc.section.7.1.3.2.p.6">A non-transparent proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    18211834      </p>
    18221835      <div class="note" id="rfc.section.7.1.3.2.p.7">
    … …  
    18251838         </p>
    18261839      </div>
    1827       <p id="rfc.section.7.1.3.2.p.8">The Content-Length field of a request or response is added or deleted according to the rules in <a href="#message.length" title="Message Length">Section&nbsp;3.4</a>. A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a href="p3-payload.html#entity.length" title="Entity Length">Section 3.2.2</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) of the entity-body, although it <em class="bcp14">MAY</em> change the transfer-length (<a href="#message.length" title="Message Length">Section&nbsp;3.4</a>).
     1840      <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.7"><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;6.2</a>).
    18281841      </p>
    18291842      <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    … …  
    20032016      <div id="rfc.iref.h.7"></div>
    20042017      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
    2005       <p id="rfc.section.9.2.p.1">The "Content-Length" entity-header field indicates the size of the entity-body, in number of OCTETs. In the case of responses
    2006          to the HEAD method, it indicates the size of the entity-body that would have been sent had the request been a GET.
     2018      <p id="rfc.section.9.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
     2019         than a response to the HEAD method or a response with a status code of 304. In the case of responses to the HEAD method, it
     2020         indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
     2021         been a GET. In the case of the 304 (Not Modified) response, it indicates the size of the payload body (not including any potential
     2022         transfer-coding) that would have been sent in a 200 (OK) response.
    20072023      </p>
    20082024      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span>  <a href="#header.content-length" class="smpl">Content-Length</a>   = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>
    … …  
    20102026</pre><p id="rfc.section.9.2.p.3">An example is</p>
    20112027      <div id="rfc.figure.u.62"></div><pre class="text">  Content-Length: 3495
    2012 </pre><p id="rfc.section.9.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section&nbsp;3.4</a>.
    2013       </p>
    2014       <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.length" title="Message Length">Section&nbsp;3.4</a> describes how to determine the length of a message-body if a Content-Length is not given.
     2028</pre><p id="rfc.section.9.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
     2029         can be determined prior to being transferred.
     2030      </p>
     2031      <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.body.length">Paragraph&nbsp;7</a> describes how to determine the length of a message-body if a Content-Length is not given.
    20152032      </p>
    20162033      <p id="rfc.section.9.2.p.7">Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional
    2017          field used within the "message/external-body" content-type. In HTTP, it <em class="bcp14">SHOULD</em> be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules
    2018          in <a href="#message.length" title="Message Length">Section&nbsp;3.4</a>.
     2034         field used within the "message/external-body" content-type.
    20192035      </p>
    20202036      <div id="rfc.iref.d.3"></div>
    … …  
    20422058         a Date. An HTTP implementation without a clock <em class="bcp14">MUST NOT</em> cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.
    20432059      </p>
    2044       <p id="rfc.section.9.3.p.7">Clients <em class="bcp14">SHOULD</em> only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even
     2060      <p id="rfc.section.9.3.p.7">Clients <em class="bcp14">SHOULD</em> only send a Date header field in messages that include a payload, as is usually the case for PUT and POST requests, and even
    20452061         then it is optional. A client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request.
    20462062      </p>
    20472063      <p id="rfc.section.9.3.p.8">The HTTP-date sent in a Date header <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
    2048          of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the entity
     2064         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    20492065         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    20502066         value.
    … …  
    21512167      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    21522168      <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body.
    2153          It differs 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.10"><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
     2169         It differs 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.8"><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
    21542170         are not.
    21552171      </p>
    … …  
    28472863         recognize a single LF as a line terminator and ignore the leading CR.
    28482864      </p>
    2849       <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling
    2850          the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2865      <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that
     2866         not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    28512867      </p>
    28522868      <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
    … …  
    29402956      <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    29412957         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    2942          computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
     2958         computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body.length">3.3.p.7</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
    29432959      </p>
    29442960      <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0
    … …  
    29652981      <p id="rfc.section.B.4.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section&nbsp;2.5</a>)
    29662982      </p>
    2967       <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.length" title="Message Length">3.4</a>)
     2983      <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.body.length">3.3.p.7</a>)
    29682984      </p>
    29692985      <p id="rfc.section.B.4.p.5">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
    … …  
    30753091 / %x53.75.6E.64.61.79 ; Sunday
    30763092
    3077 <a href="#abnf.dependencies" class="smpl">entity-body</a> = &lt;entity-body, defined in [Part3], Section 3.2&gt;
    30783093<a href="#abnf.dependencies" class="smpl">entity-header</a> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
    30793094
    … …  
    30923107<a href="#chunked.encoding" class="smpl">last-chunk</a> = 1*"0" *WSP [ chunk-ext ] CRLF
    30933108
    3094 <a href="#message.body" class="smpl">message-body</a> = entity-body /
    3095  &lt;entity-body encoded as per Transfer-Encoding&gt;
     3109<a href="#message.body" class="smpl">message-body</a> = *OCTET
    30963110<a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT
    30973111<a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan
    … …  
    34633477                  <li class="indline1">compress (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.7">6.2.2.1</a></li>
    34643478                  <li class="indline1">connection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">2.1</a></li>
    3465                   <li class="indline1">Connection header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.4</a></li>
    3466                   <li class="indline1">Content-Length header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.c.12"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>
     3479                  <li class="indline1">Connection header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.4</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.4</a></li>
     3480                  <li class="indline1">Content-Length header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.3</a>, <a class="iref" href="#rfc.iref.c.12"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>
    34673481               </ul>
    34683482            </li>
    34693483            <li class="indline0"><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind">
    3470                   <li class="indline1">Date header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.d.3"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li>
     3484                  <li class="indline1">Date header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.4</a>, <a class="iref" href="#rfc.iref.d.3"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li>
    34713485                  <li class="indline1">deflate (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li>
    34723486                  <li class="indline1">downstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
    … …  
    35193533                        <li class="indline1"><tt>field-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>3.2</b></a></li>
    35203534                        <li class="indline1"><tt>field-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>3.2</b></a></li>
    3521                         <li class="indline1"><tt>general-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>3.5</b></a></li>
     3535                        <li class="indline1"><tt>general-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>3.4</b></a></li>
    35223536                        <li class="indline1"><tt>GMT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li>
    35233537                        <li class="indline1"><tt>header-field</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>3.2</b></a></li>
    … …  
    36103624                  <li class="indline1">Headers&nbsp;&nbsp;
    36113625                     <ul class="ind">
    3612                         <li class="indline1">Connection&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.4</a></li>
    3613                         <li class="indline1">Content-Length&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>
    3614                         <li class="indline1">Date&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h.8"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li>
     3626                        <li class="indline1">Connection&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.4</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.4</a></li>
     3627                        <li class="indline1">Content-Length&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.3</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>
     3628                        <li class="indline1">Date&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.4</a>, <a class="iref" href="#rfc.iref.h.8"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li>
    36153629                        <li class="indline1">Host&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.host.1">4.3</a>, <a class="iref" href="#rfc.iref.h.10"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.2">10.1</a>, <a class="iref" href="#rfc.xref.header.host.3">B.1.1</a></li>
    36163630                        <li class="indline1">TE&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.h.11"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li>
    3617                         <li class="indline1">Trailer&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h.12"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
    3618                         <li class="indline1">Transfer-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.5</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.h.13"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
    3619                         <li class="indline1">Upgrade&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.5</a>, <a class="iref" href="#rfc.iref.h.14"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">10.1</a></li>
    3620                         <li class="indline1">Via&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.via.1">3.5</a>, <a class="iref" href="#rfc.iref.h.15"><b>9.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">10.1</a></li>
     3631                        <li class="indline1">Trailer&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h.12"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
     3632                        <li class="indline1">Transfer-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.h.13"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
     3633                        <li class="indline1">Upgrade&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.4</a>, <a class="iref" href="#rfc.iref.h.14"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">10.1</a></li>
     3634                        <li class="indline1">Via&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.via.1">3.4</a>, <a class="iref" href="#rfc.iref.h.15"><b>9.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">10.1</a></li>
    36213635                     </ul>
    36223636                  </li>
    … …  
    36693683                     </ul>
    36703684                  </li>
    3671                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">6.4</a>, <a class="iref" href="#rfc.xref.Part3.9">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a>, <a class="iref" href="#rfc.xref.Part3.12">B.3</a><ul class="ind">
    3672                         <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a></li>
    3673                         <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li>
    3674                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li>
    3675                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li>
    3676                         <li class="indline1"><em>Section 3.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.9">7.1.3.2</a></li>
    3677                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">6.4</a></li>
     3685                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">5</a>, <a class="iref" href="#rfc.xref.Part3.5">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">6.4</a>, <a class="iref" href="#rfc.xref.Part3.7">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.9">A</a>, <a class="iref" href="#rfc.xref.Part3.10">B.3</a><ul class="ind">
     3686                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a></li>
     3687                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">5</a></li>
     3688                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">6.4</a></li>
    36783689                        <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
    36793690                     </ul>
    36803691                  </li>
    36813692                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#Part5"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">B.3</a></li>
    3682                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.5</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="#rfc.xref.Part6.8">7.1.3.2</a>, <a class="iref" href="#Part6"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part6.9">B.3</a><ul class="ind">
     3693                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.3</a>, <a class="iref" href="#rfc.xref.Part6.6">3.4</a>, <a class="iref" href="#rfc.xref.Part6.7">3.4</a>, <a class="iref" href="#rfc.xref.Part6.8">3.4</a>, <a class="iref" href="#rfc.xref.Part6.9">7.1.3.2</a>, <a class="iref" href="#Part6"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part6.10">B.3</a><ul class="ind">
    36833694                        <li class="indline1"><em>Section 2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">2.3</a></li>
    3684                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">3.5</a></li>
    3685                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a></li>
    3686                         <li class="indline1"><em>Section 3.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="#rfc.xref.Part6.8">7.1.3.2</a></li>
     3695                        <li class="indline1"><em>Section 2.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">3.3</a></li>
     3696                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.6">3.4</a></li>
     3697                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">3.4</a></li>
     3698                        <li class="indline1"><em>Section 3.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.8">3.4</a>, <a class="iref" href="#rfc.xref.Part6.9">7.1.3.2</a></li>
    36873699                     </ul>
    36883700                  </li>
    … …  
    37623774                  <li class="indline1">TE header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.t.2"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li>
    37633775                  <li class="indline1"><em>Tou1998</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Tou1998.1">7.1.1</a>, <a class="iref" href="#Tou1998"><b>13.2</b></a></li>
    3764                   <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t.3"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
    3765                   <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.5</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t.4"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
     3776                  <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t.3"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
     3777                  <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t.4"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
    37663778                  <li class="indline1">tunnel&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.1">2.2</a></li>
    37673779               </ul>
    37683780            </li>
    37693781            <li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind">
    3770                   <li class="indline1">Upgrade header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.5</a>, <a class="iref" href="#rfc.iref.u.5"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">10.1</a></li>
     3782                  <li class="indline1">Upgrade header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.4</a>, <a class="iref" href="#rfc.iref.u.5"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">10.1</a></li>
    37713783                  <li class="indline1">upstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.2">2.2</a></li>
    37723784                  <li class="indline1">URI scheme&nbsp;&nbsp;
    … …  
    37813793            </li>
    37823794            <li class="indline0"><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul class="ind">
    3783                   <li class="indline1">Via header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.via.1">3.5</a>, <a class="iref" href="#rfc.iref.v.1"><b>9.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">10.1</a></li>
     3795                  <li class="indline1">Via header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.via.1">3.4</a>, <a class="iref" href="#rfc.iref.v.1"><b>9.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">10.1</a></li>
    37843796               </ul>
    37853797            </li>

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

    r848 r853  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-07-12">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <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 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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: January 13, 2011</td>
     436               <td class="left">Expires: January 17, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">July 12, 2010</td>
     489               <td class="right">July 16, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire in January 13, 2011.</p>
     516      <p>This Internet-Draft will expire in January 17, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r848 r853  
    401401      <meta name="dct.creator" content="Reschke, J. F.">
    402402      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    403       <meta name="dct.issued" scheme="ISO8601" content="2010-07-12">
     403      <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
    404404      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    405405      <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 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.">
    … …  
    427427            </tr>
    428428            <tr>
    429                <td class="left">Expires: January 13, 2011</td>
     429               <td class="left">Expires: January 17, 2011</td>
    430430               <td class="right">J. Mogul</td>
    431431            </tr>
    … …  
    484484            <tr>
    485485               <td class="left"></td>
    486                <td class="right">July 12, 2010</td>
     486               <td class="right">July 16, 2010</td>
    487487            </tr>
    488488         </tbody>
    … …  
    510510         in progress”.
    511511      </p>
    512       <p>This Internet-Draft will expire in January 13, 2011.</p>
     512      <p>This Internet-Draft will expire in January 17, 2011.</p>
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    514514      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    559559               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#entity.body">Entity Body</a><ul class="toc">
    560560                     <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#type">Type</a></li>
    561                      <li class="tocline1">3.2.2&nbsp;&nbsp;&nbsp;<a href="#entity.length">Entity Length</a></li>
    562561                  </ul>
    563562               </li>
    … …  
    843842      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    844843      <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All
    845          multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any multipart message <em class="bcp14">MUST</em> be empty; HTTP applications <em class="bcp14">MUST NOT</em> transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve
    846          the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart
    847          boundary.
    848       </p>
    849       <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception
    850          is the "multipart/byteranges" type (<a href="p5-range.html#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) when it appears in a 206 (Partial Content) response.  In all other cases, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
     844         multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
     845      </p>
     846      <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. HTTP does
     847         not use the multipart boundary as an indicator of message-body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
    851848         each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
    852849      </p>
    853       <p id="rfc.section.2.3.2.p.3">In general, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives
    854          an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
     850      <p id="rfc.section.2.3.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
    855851      </p>
    856852      <div class="note" id="rfc.section.2.3.2.p.4">
    … …  
    891887                 / <a href="#header.content-location" class="smpl">Content-Location</a>         ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;5.7</a>
    892888                 / <a href="#header.content-md5" class="smpl">Content-MD5</a>              ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section&nbsp;5.8</a>
    893                  / <a href="#abnf.dependencies" class="smpl">Content-Range</a>            ; <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a>
     889                 / <a href="#abnf.dependencies" class="smpl">Content-Range</a>            ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a>
    894890                 / <a href="#header.content-type" class="smpl">Content-Type</a>             ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;5.9</a>
    895891                 / <a href="#abnf.dependencies" class="smpl">Expires</a>                  ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a>
    … …  
    925921      <p id="rfc.section.3.2.1.p.7">Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data
    926922         compression, that are a property of the requested resource. There is no default encoding.
    927       </p>
    928       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="entity.length" href="#entity.length">Entity Length</a></h3>
    929       <p id="rfc.section.3.2.2.p.1">The entity-length of a message is the length of the message-body before any transfer-codings have been applied. <a href="p1-messaging.html#message.length" title="Message Length">Section 3.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> defines how the transfer-length of a message-body is determined.
    930923      </p>
    931924      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
    … …  
    10321025      <p id="rfc.section.5.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
    10331026         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    1034          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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
     1027         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.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
    10351028      </p>
    10361029      <div class="note" id="rfc.section.5.1.p.5">
    … …  
    11561149      <ol>
    11571150         <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
    1158             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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable.")
     1151            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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable.")
    11591152         </li>
    11601153         <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
    … …  
    12351228      </p>
    12361229      <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
    1237 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.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>). Typically, the entity-body is stored with this encoding and is only decoded before rendering or analogous usage. However,
     1230</pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>). Typically, the entity-body is stored with this encoding and is only decoded before rendering or analogous usage. However,
    12381231         a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
    12391232         directive is present in the message.
    … …  
    12851278  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    12861279                    <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1287 </pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>); it is only a statement of the location of the resource corresponding to this particular entity at the time of the request.
     1280</pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.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>); it is only a statement of the location of the resource corresponding to this particular entity at the time of the request.
    12881281         Future requests <em class="bcp14">MAY</em> may be addressed to the Content-Location URI if the desire is to identify the source of that particular entity.
    12891282      </p>
    … …  
    14621455                  <td class="left">compress</td>
    14631456                  <td class="left">UNIX "compress" program method</td>
    1464                   <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.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1457                  <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.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14651458                  </td>
    14661459               </tr>
    … …  
    14691462                  <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>)
    14701463                  </td>
    1471                   <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.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1464                  <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.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14721465                  </td>
    14731466               </tr>
    … …  
    14751468                  <td class="left">gzip</td>
    14761469                  <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>
    1477                   <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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1470                  <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.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14781471                  </td>
    14791472               </tr>
    … …  
    17421735      </p>
    17431736      <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>
    1744       <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.27"><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.
     1737      <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.26"><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.
    17451738      </p>
    17461739      <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>
    … …  
    17591752      </p>
    17601753      <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>
    1761       <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.28"><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.
     1754      <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.27"><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.
    17621755      </p>
    17631756      <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>
    … …  
    18041797      <p id="rfc.section.C.1.p.1">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    18051798         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    1806          computed. (<a href="#entity.length" title="Entity Length">Section&nbsp;3.2.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <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="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1799         computed.
    18071800      </p>
    18081801      <p id="rfc.section.C.1.p.2">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;5.2</a>)
    … …  
    22132206            </li>
    22142207            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    2215                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a>, <a class="iref" href="#rfc.xref.Part1.22">5.5</a>, <a class="iref" href="#rfc.xref.Part1.23">5.7</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a>, <a class="iref" href="#rfc.xref.Part1.26">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.27">A.3</a>, <a class="iref" href="#rfc.xref.Part1.28">A.6</a>, <a class="iref" href="#rfc.xref.Part1.29">C.1</a><ul class="ind">
     2208                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a>, <a class="iref" href="#rfc.xref.Part1.21">5.5</a>, <a class="iref" href="#rfc.xref.Part1.22">5.7</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.26">A.3</a>, <a class="iref" href="#rfc.xref.Part1.27">A.6</a><ul class="ind">
    22162209                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a></li>
    22172210                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a></li>
    … …  
    22192212                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.3.2</a></li>
    22202213                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3.2</a></li>
    2221                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">3.2.2</a></li>
    2222                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.22">5.5</a>, <a class="iref" href="#rfc.xref.Part1.23">5.7</a></li>
    2223                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">A.3</a></li>
     2214                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">5.5</a>, <a class="iref" href="#rfc.xref.Part1.22">5.7</a></li>
     2215                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">A.3</a></li>
    22242216                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li>
    2225                         <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li>
     2217                        <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a></li>
    22262218                        <li class="indline1"><em>Section 6.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li>
    2227                         <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a></li>
    2228                         <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">6.2</a></li>
    2229                         <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a></li>
     2219                        <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li>
     2220                        <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a></li>
     2221                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a></li>
    22302222                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a></li>
    2231                         <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.28">A.6</a></li>
     2223                        <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">A.6</a></li>
    22322224                     </ul>
    22332225                  </li>
    … …  
    22412233                     </ul>
    22422234                  </li>
    2243                   <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">2.3.2</a>, <a class="iref" href="#rfc.xref.Part5.3">3.1</a>, <a class="iref" href="#Part5"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part5.4">C.1</a><ul class="ind">
    2244                         <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.3">3.1</a></li>
    2245                         <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">2.3.2</a></li>
     2235                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>9.1</b></a><ul class="ind">
     2236                        <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li>
    22462237                     </ul>
    22472238                  </li>
    2248                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#rfc.xref.Part6.4">5.7</a>, <a class="iref" href="#Part6"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part6.5">C.1</a><ul class="ind">
     2239                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#rfc.xref.Part6.4">5.7</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind">
    22492240                        <li class="indline1"><em>Section 2.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">5.7</a></li>
    22502241                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a></li>

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

    r848 r853  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-12">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <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 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.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 13, 2011</td>
     428               <td class="left">Expires: January 17, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 12, 2010</td>
     485               <td class="right">July 16, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire in January 13, 2011.</p>
     511      <p>This Internet-Draft will expire in January 17, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r848 r853  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-12">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <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 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.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 13, 2011</td>
     428               <td class="left">Expires: January 17, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 12, 2010</td>
     485               <td class="right">July 16, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire in January 13, 2011.</p>
     511      <p>This Internet-Draft will expire in January 17, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    653653      <ul>
    654654         <li>Either a Content-Range header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;5.2</a>) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields
    655             for each part. If a Content-Length header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of OCTETs transmitted in the message-body.
     655            for each part. If a Content-Length header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of octets transmitted in the message-body.
    656656         </li>
    657657         <li>Date</li>

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

    r848 r853  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-07-12">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: January 13, 2011</td>
     430               <td class="left">Expires: January 17, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">July 12, 2010</td>
     491               <td class="right">July 16, 2010</td>
    492492            </tr>
    493493         </tbody>
    … …  
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire in January 13, 2011.</p>
     517      <p>This Internet-Draft will expire in January 17, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r848 r853  
    394394      <meta name="dct.creator" content="Reschke, J. F.">
    395395      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    396       <meta name="dct.issued" scheme="ISO8601" content="2010-07-12">
     396      <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
    397397      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    398398      <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 HTTP Authentication.">
    … …  
    425425            </tr>
    426426            <tr>
    427                <td class="left">Expires: January 13, 2011</td>
     427               <td class="left">Expires: January 17, 2011</td>
    428428               <td class="right">HP</td>
    429429            </tr>
    … …  
    478478            <tr>
    479479               <td class="left"></td>
    480                <td class="right">July 12, 2010</td>
     480               <td class="right">July 16, 2010</td>
    481481            </tr>
    482482         </tbody>
    … …  
    504504         in progress”.
    505505      </p>
    506       <p>This Internet-Draft will expire in January 13, 2011.</p>
     506      <p>This Internet-Draft will expire in January 17, 2011.</p>
    507507      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    508508      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.