Changeset 853
- Timestamp:
- 17/07/10 05:57:33 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r849 r853 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 2">406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-16"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: January 1 3, 2011</td>437 <td class="left">Expires: January 17, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">July 1 2, 2010</td>490 <td class="right">July 16, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire in January 1 3, 2011.</p>518 <p>This Internet-Draft will expire in January 17, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 562 562 <li class="tocline1">3.2 <a href="#header.fields">Header Fields</a></li> 563 563 <li class="tocline1">3.3 <a href="#message.body">Message Body</a></li> 564 <li class="tocline1">3.4 <a href="#message.length">Message Length</a></li> 565 <li class="tocline1">3.5 <a href="#general.header.fields">General Header Fields</a></li> 564 <li class="tocline1">3.4 <a href="#general.header.fields">General Header Fields</a></li> 566 565 </ul> 567 566 </li> … … 801 800 <h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h3> 802 801 <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 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 A</a> for tolerant applications). 805 803 </p> 806 804 </div> … … 861 859 <div id="rfc.figure.u.12"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">request-header</a> = <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>> 862 860 <a href="#abnf.dependencies" class="smpl">response-header</a> = <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>> 863 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">entity-body</a> = <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>> 864 <a href="#abnf.dependencies" class="smpl">entity-header</a> = <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>> 861 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">entity-header</a> = <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>> 865 862 </pre><div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <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>> 866 863 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <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>> … … 1122 1119 <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 1123 1120 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 3.4</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different1121 and in the algorithm for determining the length of the message-body (<a href="#message.body.length">Paragraph 7</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different 1125 1122 start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown 1126 1123 or invalid request method) and clients are implemented to only expect a response. … … 1145 1142 <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 1146 1143 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 read1148 or the connection is closed. Care must be taken to parse an HTTP message as a sequence of OCTETs in an encoding that is a1149 superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16 may introduce1150 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. 1151 1148 </p> 1152 1149 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.fields" href="#header.fields">Header Fields</a></h2> … … 1204 1201 </p> 1205 1202 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <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. The1207 message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding1203 <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 1208 1205 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 9.7</a>). 1209 1206 </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 / <entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>> 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 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 6.2</a>. 1214 1211 </p> 1215 1212 <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> 1216 1213 <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. 1220 1216 </p> 1221 1217 <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 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> <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 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> 1231 1226 <ol> 1232 1227 <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 terminated1234 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. 1235 1230 </p> 1236 1231 </li> 1237 1232 <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 9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>) is used, the transfer-length is defined by the use of this transfer-coding. If a Transfer-Encoding header field is present1239 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 9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 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. 1240 1235 </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> 1241 1245 </li> 1242 1246 <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 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 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. 1245 1251 </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> 1246 1258 </li> 1247 1259 <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. 1251 1265 </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, since1259 that would leave no possibility for the server to send back a response.)1260 </p>1261 1266 </li> 1262 1267 </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 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> <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> <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> 1278 1291 / <a href="#header.connection" class="smpl">Connection</a> ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 9.1</a> 1279 1292 / <a href="#header.date" class="smpl">Date</a> ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 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> 1281 1294 / <a href="#header.trailer" class="smpl">Trailer</a> ; <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 9.6</a> 1282 1295 / <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 9.7</a> 1283 1296 / <a href="#header.upgrade" class="smpl">Upgrade</a> ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 9.8</a> 1284 1297 / <a href="#header.via" class="smpl">Via</a> ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 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, new1298 / <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 1287 1300 or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize 1288 1301 them to be general-header fields. Unrecognized header fields are treated as entity-header fields. … … 1293 1306 </p> 1294 1307 <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 4.1</a> 1295 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3. 5</a>1308 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.4</a> 1296 1309 / <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> 1298 1311 <a href="#core.rules" class="smpl">CRLF</a> 1299 1312 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> … … 1359 1372 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>). 1360 1373 </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. 1362 1375 </p> 1363 1376 <div class="note" id="rfc.section.4.1.2.p.21"> … … 1423 1436 <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1424 1437 <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 5.1</a> 1425 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3. 5</a>1438 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.4</a> 1426 1439 / <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> 1428 1441 <a href="#core.rules" class="smpl">CRLF</a> 1429 1442 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> … … 1454 1467 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 1455 1468 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <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 representsa 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>: 1458 1471 </p> 1459 1472 <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> 1461 1474 <div id="rfc.figure.u.46"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1462 1475 Sun 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 thedate 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 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 (Coordinated1476 </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 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 1466 1479 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for 1467 1480 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. … … 1469 1482 <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> 1470 1483 </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> 1472 1485 </div> 1473 1486 <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> … … 1507 1520 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1508 1521 <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.1 1">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>). 1510 1523 </p> 1511 1524 <div id="obsolete.date.formats"> 1512 <p id="rfc.section.6.1.p.1 2"> Obsolete formats:</p>1525 <p id="rfc.section.6.1.p.11"> Obsolete formats:</p> 1513 1526 </div> 1514 1527 <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> … … 1527 1540 <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> )) 1528 1541 ; month day (e.g., Jun 2) 1529 </pre><div class="note" id="rfc.section.6.1.p.1 6">1542 </pre><div class="note" id="rfc.section.6.1.p.15"> 1530 1543 <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, 1531 1544 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 1532 1545 </p> 1533 1546 </div> 1534 <div class="note" id="rfc.section.6.1.p.1 7">1547 <div class="note" id="rfc.section.6.1.p.16"> 1535 1548 <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers 1536 1549 are not required to use these formats for user presentation, request logging, etc. … … 1539 1552 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2> 1540 1553 <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 a n entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding1542 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. 1543 1556 </p> 1544 1557 <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 6.2.1</a> … … 1556 1569 </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 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 9.7</a>). 1557 1570 </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-coding1559 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 message1560 (<a href="#message. length" title="Message Length">Section 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 7</a>). 1561 1574 </p> 1562 1575 <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 1563 1576 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 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), andclose 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 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. 1567 1580 </p> 1568 1581 <div id="rfc.iref.c.5"></div> … … 1620 1633 while (chunk-size > 0) { 1621 1634 read chunk-data and CRLF 1622 append chunk-data to entity-body1635 append chunk-data to decoded-body 1623 1636 length := length + chunk-size 1624 1637 read chunk-size and CRLF 1625 1638 } 1626 read entity-header1627 while ( entity-headernot empty) {1628 append entity-headerto existing header fields1629 read entity-header1639 read header-field 1640 while (header-field not empty) { 1641 append header-field to existing header fields 1642 read header-field 1630 1643 } 1631 1644 Content-Length := length 1632 1645 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. 1634 1647 </p> 1635 1648 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h3> … … 1673 1686 <li>Pointer to specification text</li> 1674 1687 </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 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 6.2.2</a>). 1676 1689 </p> 1677 1690 <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" … … 1693 1706 </p> 1694 1707 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <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 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 weight1708 <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 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 1696 1709 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 1697 1710 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. … … 1750 1763 <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 B.2</a> for more information on backward compatibility with HTTP/1.0 clients. 1751 1764 </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 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 7</a>. 1753 1766 </p> 1754 1767 <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> … … 1818 1831 <li>Content-Type</li> 1819 1832 </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>). 1821 1834 </p> 1822 1835 <div class="note" id="rfc.section.7.1.3.2.p.7"> … … 1825 1838 </p> 1826 1839 </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 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 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 6.2</a>). 1828 1841 </p> 1829 1842 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 2003 2016 <div id="rfc.iref.h.7"></div> 2004 2017 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <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. 2007 2023 </p> 2008 2024 <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> … … 2010 2026 </pre><p id="rfc.section.9.2.p.3">An example is</p> 2011 2027 <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 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 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 7</a> describes how to determine the length of a message-body if a Content-Length is not given. 2015 2032 </p> 2016 2033 <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 3.4</a>. 2034 field used within the "message/external-body" content-type. 2019 2035 </p> 2020 2036 <div id="rfc.iref.d.3"></div> … … 2042 2058 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. 2043 2059 </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 a n entity-body, as in the case of thePUT and POST requests, and even2060 <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 2045 2061 then it is optional. A client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request. 2046 2062 </p> 2047 2063 <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 entity2064 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload 2049 2065 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic 2050 2066 value. … … 2151 2167 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2152 2168 <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-codings2169 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 2154 2170 are not. 2155 2171 </p> … … 2847 2863 recognize a single LF as a line terminator and ignore the leading CR. 2848 2864 </p> 2849 <p id="rfc.section.A.p.4">The character set of a n 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 labeling2850 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>. 2851 2867 </p> 2852 2868 <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> … … 2940 2956 <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 2941 2957 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>) 2943 2959 </p> 2944 2960 <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 … … 2965 2981 <p id="rfc.section.B.4.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section 2.5</a>) 2966 2982 </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>) 2968 2984 </p> 2969 2985 <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 3.2</a>) … … 3075 3091 / %x53.75.6E.64.61.79 ; Sunday 3076 3092 3077 <a href="#abnf.dependencies" class="smpl">entity-body</a> = <entity-body, defined in [Part3], Section 3.2>3078 3093 <a href="#abnf.dependencies" class="smpl">entity-header</a> = <entity-header, defined in [Part3], Section 3.1> 3079 3094 … … 3092 3107 <a href="#chunked.encoding" class="smpl">last-chunk</a> = 1*"0" *WSP [ chunk-ext ] CRLF 3093 3108 3094 <a href="#message.body" class="smpl">message-body</a> = entity-body / 3095 <entity-body encoded as per Transfer-Encoding> 3109 <a href="#message.body" class="smpl">message-body</a> = *OCTET 3096 3110 <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT 3097 3111 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan … … 3463 3477 <li class="indline1">compress (Coding Format) <a class="iref" href="#rfc.iref.c.7">6.2.2.1</a></li> 3464 3478 <li class="indline1">connection <a class="iref" href="#rfc.iref.c.2">2.1</a></li> 3465 <li class="indline1">Connection header <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 <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 <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 <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> 3467 3481 </ul> 3468 3482 </li> 3469 3483 <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 <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 <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> 3471 3485 <li class="indline1">deflate (Coding Format) <a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li> 3472 3486 <li class="indline1">downstream <a class="iref" href="#rfc.iref.d.1">2.2</a></li> … … 3519 3533 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.2</b></a></li> 3520 3534 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.2</b></a></li> 3521 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.45"><b>3. 5</b></a></li>3535 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.45"><b>3.4</b></a></li> 3522 3536 <li class="indline1"><tt>GMT</tt> <a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li> 3523 3537 <li class="indline1"><tt>header-field</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.2</b></a></li> … … 3610 3624 <li class="indline1">Headers 3611 3625 <ul class="ind"> 3612 <li class="indline1">Connection <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 <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 <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 <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 <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 <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> 3615 3629 <li class="indline1">Host <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> 3616 3630 <li class="indline1">TE <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 <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 <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 <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 <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 <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 <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 <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 <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> 3621 3635 </ul> 3622 3636 </li> … … 3669 3683 </ul> 3670 3684 </li> 3671 <li class="indline1"><em>Part3</em> <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> <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> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li> 3674 <li class="indline1"><em>Section 3.1</em> <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> <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li> 3676 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.Part3.9">7.1.3.2</a></li> 3677 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.8">6.4</a></li> 3685 <li class="indline1"><em>Part3</em> <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> <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> <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> <a class="iref" href="#rfc.xref.Part3.6">6.4</a></li> 3678 3689 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a></li> 3679 3690 </ul> 3680 3691 </li> 3681 3692 <li class="indline1"><em>Part5</em> <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> <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> <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"> 3683 3694 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part6.4">2.3</a></li> 3684 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part6.5">3.5</a></li> 3685 <li class="indline1"><em>Section 3.4</em> <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> <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> <a class="iref" href="#rfc.xref.Part6.5">3.3</a></li> 3696 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part6.6">3.4</a></li> 3697 <li class="indline1"><em>Section 3.4</em> <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> <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> 3687 3699 </ul> 3688 3700 </li> … … 3762 3774 <li class="indline1">TE header <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> 3763 3775 <li class="indline1"><em>Tou1998</em> <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 <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 <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 <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 <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> 3766 3778 <li class="indline1">tunnel <a class="iref" href="#rfc.iref.t.1">2.2</a></li> 3767 3779 </ul> 3768 3780 </li> 3769 3781 <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 <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 <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> 3771 3783 <li class="indline1">upstream <a class="iref" href="#rfc.iref.u.2">2.2</a></li> 3772 3784 <li class="indline1">URI scheme … … 3781 3793 </li> 3782 3794 <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 <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 <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> 3784 3796 </ul> 3785 3797 </li> -
draft-ietf-httpbis/latest/p2-semantics.html
r848 r853 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 2">405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-16"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <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 "HTTP/1.1" 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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: January 1 3, 2011</td>436 <td class="left">Expires: January 17, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">July 1 2, 2010</td>489 <td class="right">July 16, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in January 1 3, 2011.</p>516 <p>This Internet-Draft will expire in January 17, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <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 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 2">403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-16"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: January 1 3, 2011</td>429 <td class="left">Expires: January 17, 2011</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">July 1 2, 2010</td>486 <td class="right">July 16, 2010</td> 487 487 </tr> 488 488 </tbody> … … 510 510 in progress”. 511 511 </p> 512 <p>This Internet-Draft will expire in January 1 3, 2011.</p>512 <p>This Internet-Draft will expire in January 17, 2011.</p> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 559 559 <li class="tocline1">3.2 <a href="#entity.body">Entity Body</a><ul class="toc"> 560 560 <li class="tocline1">3.2.1 <a href="#type">Type</a></li> 561 <li class="tocline1">3.2.2 <a href="#entity.length">Entity Length</a></li>562 561 </ul> 563 562 </li> … … 843 842 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3> 844 843 <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 851 848 each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics. 852 849 </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". 855 851 </p> 856 852 <div class="note" id="rfc.section.2.3.2.p.4"> … … 891 887 / <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 5.7</a> 892 888 / <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 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> 894 890 / <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 5.9</a> 895 891 / <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> … … 925 921 <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 926 922 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> <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.930 923 </p> 931 924 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> … … 1032 1025 <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 1033 1026 "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. 1035 1028 </p> 1036 1029 <div class="note" id="rfc.section.5.1.p.5"> … … 1156 1149 <ol> 1157 1150 <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.2 1"><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.") 1159 1152 </li> 1160 1153 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header … … 1235 1228 </p> 1236 1229 <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.2 2"><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, 1238 1231 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 1239 1232 directive is present in the message. … … 1285 1278 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1286 1279 <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.2 3"><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. 1288 1281 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. 1289 1282 </p> … … 1462 1455 <td class="left">compress</td> 1463 1456 <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.2 4"><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> 1465 1458 </td> 1466 1459 </tr> … … 1469 1462 <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>) 1470 1463 </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.2 5"><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> 1472 1465 </td> 1473 1466 </tr> … … 1475 1468 <td class="left">gzip</td> 1476 1469 <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.2 6"><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> 1478 1471 </td> 1479 1472 </tr> … … 1742 1735 </p> 1743 1736 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <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.2 7"><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. 1745 1738 </p> 1746 1739 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> … … 1759 1752 </p> 1760 1753 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <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.2 8"><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. 1762 1755 </p> 1763 1756 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 1804 1797 <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 1805 1798 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 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. 1807 1800 </p> 1808 1801 <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 5.2</a>) … … 2213 2206 </li> 2214 2207 <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> <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> <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"> 2216 2209 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a></li> 2217 2210 <li class="indline1"><em>Section 1.2.2</em> <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> … … 2219 2212 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a></li> 2220 2213 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.18">3.2</a></li> 2221 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part1.19">3.2.2</a></li> 2222 <li class="indline1"><em>Section 4.3</em> <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> <a class="iref" href="#rfc.xref.Part1.27">A.3</a></li> 2214 <li class="indline1"><em>Section 4.3</em> <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> <a class="iref" href="#rfc.xref.Part1.26">A.3</a></li> 2224 2216 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li> 2225 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 4">6.2</a></li>2217 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a></li> 2226 2218 <li class="indline1"><em>Section 6.2.2</em> <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li> 2227 <li class="indline1"><em>Section 6.2.2.2</em> <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 5">6.2</a></li>2228 <li class="indline1"><em>Section 6.2.2.3</em> <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 6">6.2</a></li>2229 <li class="indline1"><em>Section 6.4</em> <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> <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> <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> <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> 2230 2222 <li class="indline1"><em>Section 9.2</em> <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> <a class="iref" href="#rfc.xref.Part1.2 8">A.6</a></li>2223 <li class="indline1"><em>Section 9.7</em> <a class="iref" href="#rfc.xref.Part1.27">A.6</a></li> 2232 2224 </ul> 2233 2225 </li> … … 2241 2233 </ul> 2242 2234 </li> 2243 <li class="indline1"><em>Part5</em> <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> <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> <a class="iref" href="#rfc.xref.Part5.2">2.3.2</a></li> 2235 <li class="indline1"><em>Part5</em> <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> <a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li> 2246 2237 </ul> 2247 2238 </li> 2248 <li class="indline1"><em>Part6</em> <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> <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"> 2249 2240 <li class="indline1"><em>Section 2.7</em> <a class="iref" href="#rfc.xref.Part6.4">5.7</a></li> 2250 2241 <li class="indline1"><em>Section 3.3</em> <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 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 2">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-16"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <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 "HTTP/1.1" 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."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: January 1 3, 2011</td>428 <td class="left">Expires: January 17, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">July 1 2, 2010</td>485 <td class="right">July 16, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 1 3, 2011.</p>511 <p>This Internet-Draft will expire in January 17, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <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 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 2">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-16"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: January 1 3, 2011</td>428 <td class="left">Expires: January 17, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">July 1 2, 2010</td>485 <td class="right">July 16, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 1 3, 2011.</p>511 <p>This Internet-Draft will expire in January 17, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 653 653 <ul> 654 654 <li>Either a Content-Range header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section 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. 656 656 </li> 657 657 <li>Date</li> -
draft-ietf-httpbis/latest/p6-cache.html
r848 r853 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 2">404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-16"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <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 "HTTP/1.1" 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."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: January 1 3, 2011</td>430 <td class="left">Expires: January 17, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">July 1 2, 2010</td>491 <td class="right">July 16, 2010</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire in January 1 3, 2011.</p>517 <p>This Internet-Draft will expire in January 17, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <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 394 394 <meta name="dct.creator" content="Reschke, J. F."> 395 395 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 396 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 2">396 <meta name="dct.issued" scheme="ISO8601" content="2010-07-16"> 397 397 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 398 398 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 425 425 </tr> 426 426 <tr> 427 <td class="left">Expires: January 1 3, 2011</td>427 <td class="left">Expires: January 17, 2011</td> 428 428 <td class="right">HP</td> 429 429 </tr> … … 478 478 <tr> 479 479 <td class="left"></td> 480 <td class="right">July 1 2, 2010</td>480 <td class="right">July 16, 2010</td> 481 481 </tr> 482 482 </tbody> … … 504 504 in progress”. 505 505 </p> 506 <p>This Internet-Draft will expire in January 1 3, 2011.</p>506 <p>This Internet-Draft will expire in January 17, 2011.</p> 507 507 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 508 508 <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.