Changeset 1544 for draft-ietf-httpbis/latest
- Timestamp:
- 21/02/12 02:12:49 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1540 r1544 1206 1206 <p id="rfc.section.3.p.1">All HTTP/1.1 messages consist of a start-line followed by a sequence of octets in a format similar to the Internet Message 1207 1207 Format <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating 1208 the end of the header section, and an optional message -body.1208 the end of the header section, and an optional message body. 1209 1209 </p> 1210 1210 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a> … … 1213 1213 [ <a href="#message.body" class="smpl">message-body</a> ] 1214 1214 </pre><p id="rfc.section.3.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 1215 hash table by field name until the empty line, and then use the parsed data to determine if a message -body is expected. If1216 a message -body has been indicated, then it is read as a stream until an amount of octets equal to the message-body length1215 hash table by field name until the empty line, and then use the parsed data to determine if a message body is expected. If 1216 a message body has been indicated, then it is read as a stream until an amount of octets equal to the message body length 1217 1217 is read or the connection is closed. 1218 1218 </p> … … 1229 1229 <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two 1230 1230 types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses), 1231 and in the algorithm for determining the length of the message -body (<a href="#message.body" title="Message Body">Section 3.3</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different1231 and in the algorithm for determining the length of the message body (<a href="#message.body" title="Message Body">Section 3.3</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different 1232 1232 start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown 1233 1233 or invalid request method) and clients are implemented to only expect a response. … … 1463 1463 status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., 1464 1464 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1465 All 1xx (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.1465 All 1xx (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. 1466 1466 </p> 1467 1467 <div id="rfc.iref.t.4"></div> 1468 1468 <div id="rfc.iref.h.6"></div> 1469 1469 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3> 1470 <p id="rfc.section.3.3.1.p.1">When one or more transfer encodings are applied to a payload body in order to form the message -body, a Transfer-Encoding header1470 <p id="rfc.section.3.3.1.p.1">When one or more transfer encodings are applied to a payload body in order to form the message body, a Transfer-Encoding header 1471 1471 field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer encodings are defined 1472 1472 in <a href="#transfer.codings" title="Transfer Codings">Section 5</a>. … … 1479 1479 </p> 1480 1480 <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size 1481 is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message -body. If any transfer-coding is applied to a request payload body, the final transfer-coding1481 is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message body. If any transfer-coding is applied to a request payload body, the final transfer-coding 1482 1482 applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. 1483 1483 </p> 1484 1484 <p id="rfc.section.3.3.1.p.5">For example,</p> 1485 1485 <div id="rfc.figure.u.35"></div><pre class="text"> Transfer-Encoding: chunked 1486 </pre><p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message -body length.1486 </pre><p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1487 1487 </p> 1488 1488 <p id="rfc.section.3.3.1.p.8">Unlike Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. … … 1497 1497 <div id="rfc.iref.h.7"></div> 1498 1498 <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h3> 1499 <p id="rfc.section.3.3.2.p.1">The "Content-Length" header field indicates the size of the message -body, in decimal number of octets, for any message other1499 <p id="rfc.section.3.3.2.p.1">The "Content-Length" header field indicates the size of the message body, in decimal number of octets, for any message other 1500 1500 than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length 1501 1501 indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request … … 1506 1506 </pre><p id="rfc.section.3.3.2.p.3">An example is</p> 1507 1507 <div id="rfc.figure.u.37"></div><pre class="text"> Content-Length: 3495 1508 </pre><p id="rfc.section.3.3.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 length1509 can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section 3.3</a> describes how recipients determine the length of a message -body.1508 </pre><p id="rfc.section.3.3.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 1509 can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section 3.3</a> describes how recipients determine the length of a message body. 1510 1510 </p> 1511 1511 <p id="rfc.section.3.3.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p> … … 1516 1516 a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields 1517 1517 have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing 1518 that decimal value prior to determining the message -body length.1518 that decimal value prior to determining the message body length. 1519 1519 </p> 1520 1520 <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="message.body.length" href="#message.body.length">Message Body Length</a></h3> 1521 <p id="rfc.section.3.3.3.p.1">The length of a message -body is determined by one of the following (in order of precedence):</p>1521 <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p> 1522 1522 <p id="rfc.section.3.3.3.p.2"> </p> 1523 1523 <ol> 1524 1524 <li> 1525 1525 <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 1526 empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message-body. 1526 empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message 1527 body. 1527 1528 </p> 1528 1529 </li> 1529 1530 <li> 1530 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>) is the final encoding, the message -body length is determined by reading and decoding the chunked data until the transfer-coding1531 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding 1531 1532 indicates the data is complete. 1532 1533 </p> 1533 1534 <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding, 1534 the message -body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header1535 field is present in a request and the "chunked" transfer-coding is not the final encoding, the message -body length cannot1535 the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header 1536 field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot 1536 1537 be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection. 1537 1538 </p> 1538 1539 <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding 1539 1540 overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of 1540 security-related checks on message routing or content) and thus ought to 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-coding1541 security-related checks on message routing or content) and thus ought to 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 1541 1542 is decoded. 1542 1543 </p> … … 1550 1551 </li> 1551 1552 <li> 1552 <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message -body length1553 <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message body length 1553 1554 in octets. If the actual number 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 1554 the message is more 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 a connection1555 the message is more 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 a connection 1555 1556 and the connection has been closed by the server. 1556 1557 </p> 1557 1558 </li> 1558 1559 <li> 1559 <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>1560 <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> 1560 1561 </li> 1561 1562 <li> 1562 <p>Otherwise, this is a response message without a declared message -body length, so the message-body length is determined by1563 <p>Otherwise, this is a response message without a declared message body length, so the message body length is determined by 1563 1564 the number of octets received prior to the server closing the connection. 1564 1565 </p> … … 1569 1570 with HTTP/1.0. 1570 1571 </p> 1571 <p id="rfc.section.3.3.3.p.4">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).1572 </p> 1573 <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message -body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding,1572 <p id="rfc.section.3.3.3.p.4">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). 1573 </p> 1574 <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message body length is known in advance, rather than the "chunked" encoding, 1574 1575 since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the 1575 1576 chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in 1576 1577 advance of being called and the server is unable or unwilling to buffer the entire request before processing. 1577 1578 </p> 1578 <p id="rfc.section.3.3.3.p.6">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; such1579 <p id="rfc.section.3.3.3.p.6">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 1579 1580 knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. 1580 1581 </p> … … 1583 1584 </p> 1584 1585 <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number 1585 of octets or by failure to decode a transfer-encoded message -body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received)1586 of octets or by failure to decode a transfer-encoded message body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received) 1586 1587 cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error. 1587 1588 </p> 1588 <p id="rfc.section.3.4.p.3">A message -body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding1589 has not been received. A message that uses a valid Content-Length is incomplete if the size of the message -body received (in1589 <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding 1590 has not been received. A message that uses a valid Content-Length is incomplete if the size of the message body received (in 1590 1591 octets) is less than the value given by Content-Length. A response that has neither chunked transfer encoding nor Content-Length 1591 is terminated by closure of the connection, and thus is considered complete regardless of the number of message -body octets1592 is terminated by closure of the connection, and thus is considered complete regardless of the number of message body octets 1592 1593 received, provided that the header block was received intact. 1593 1594 </p> 1594 <p id="rfc.section.3.4.p.4">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 an1595 <p id="rfc.section.3.4.p.4">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 1595 1596 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1596 1597 </p> 1597 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message -body or close the connection after sending its response, since otherwise the remaining data1598 on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message -body if it intends to reuse the same connection for a subsequent request. Pipelining multiple1598 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data 1599 on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple 1599 1600 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 6.1.2.2</a>. 1600 1601 </p> 1601 1602 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> 1602 1603 <p id="rfc.section.3.5.p.1">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server 1603 applications that failed to read message -body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then1604 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message -body length.1604 applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then 1605 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length. 1605 1606 </p> 1606 1607 <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol … … 2076 2077 </p> 2077 2078 </div> 2078 <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><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 5</a>).2079 <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><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 5</a>). 2079 2080 </p> 2080 2081 <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 2114 2115 </p> 2115 2116 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> 2116 <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message -body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error2117 <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 2117 2118 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 5</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection. 2118 2119 </p> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1540 r1544 1042 1042 <xref target="RFC5322"/>: zero or more header fields (collectively 1043 1043 referred to as the "headers" or the "header section"), an empty line 1044 indicating the end of the header section, and an optional message -body.1044 indicating the end of the header section, and an optional message body. 1045 1045 </t> 1046 1046 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/> … … 1054 1054 start-line into a structure, read each header field into a hash 1055 1055 table by field name until the empty line, and then use the parsed 1056 data to determine if a message -body is expected. If a message-body1056 data to determine if a message body is expected. If a message body 1057 1057 has been indicated, then it is read as a stream until an amount 1058 of octets equal to the message -body length is read or the connection1058 of octets equal to the message body length is read or the connection 1059 1059 is closed. 1060 1060 </t> … … 1085 1085 differ only in the start-line, which is either a Request-Line (for requests) 1086 1086 or a Status-Line (for responses), and in the algorithm for determining 1087 the length of the message -body (<xref target="message.body"/>).1087 the length of the message body (<xref target="message.body"/>). 1088 1088 In theory, a client could receive requests and a server could receive 1089 1089 responses, distinguishing them by their different start-line formats, … … 1578 1578 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1579 1579 responses &MUST-NOT; include a message body. 1580 All other responses do include a message -body, although the body1580 All other responses do include a message body, although the body 1581 1581 &MAY; be of zero length. 1582 1582 </t> … … 1588 1588 <t> 1589 1589 When one or more transfer encodings are applied to a payload body in order 1590 to form the message -body, a Transfer-Encoding header field &MUST; be sent1590 to form the message body, a Transfer-Encoding header field &MUST; be sent 1591 1591 in the message and &MUST; contain the list of corresponding 1592 1592 transfer-coding names in the same order that they were applied. … … 1613 1613 When the "chunked" transfer-coding is used, it &MUST; be the last 1614 1614 transfer-coding applied to form the message body and &MUST-NOT; 1615 be applied more than once in a message -body.1615 be applied more than once in a message body. 1616 1616 If any transfer-coding is applied to a request payload body, 1617 1617 the final transfer-coding applied &MUST; be "chunked". … … 1630 1630 the multiple field-values &MUST; be combined into one field-value, 1631 1631 according to the algorithm defined in <xref target="header.fields"/>, 1632 before determining the message -body length.1632 before determining the message body length. 1633 1633 </t> 1634 1634 <t> … … 1663 1663 <t> 1664 1664 The "Content-Length" header field indicates the size of the 1665 message -body, in decimal number of octets, for any message other than1665 message body, in decimal number of octets, for any message other than 1666 1666 a response to a HEAD request or a response with a status code of 304. 1667 1667 In the case of a response to a HEAD request, Content-Length indicates … … 1683 1683 </artwork></figure> 1684 1684 <t> 1685 Implementations &SHOULD; use this field to indicate the message -body1685 Implementations &SHOULD; use this field to indicate the message body 1686 1686 length when no transfer-coding is being applied and the 1687 1687 payload's body length can be determined prior to being transferred. 1688 1688 <xref target="message.body"/> describes how recipients determine the length 1689 of a message -body.1689 of a message body. 1690 1690 </t> 1691 1691 <t> … … 1706 1706 processor, then the recipient &MUST; either reject the message as invalid 1707 1707 or replace the duplicated field-values with a single valid Content-Length 1708 field containing that decimal value prior to determining the message -body1708 field containing that decimal value prior to determining the message body 1709 1709 length. 1710 1710 </t> … … 1713 1713 <section title="Message Body Length" anchor="message.body.length"> 1714 1714 <t> 1715 The length of a message -body is determined by one of the following1715 The length of a message body is determined by one of the following 1716 1716 (in order of precedence): 1717 1717 </t> … … 1722 1722 code of 100-199, 204, or 304 is always terminated by the first 1723 1723 empty line after the header fields, regardless of the header 1724 fields present in the message, and thus cannot contain a message -body.1724 fields present in the message, and thus cannot contain a message body. 1725 1725 </t></x:lt> 1726 1726 <x:lt><t> 1727 1727 If a Transfer-Encoding header field is present 1728 1728 and the "chunked" transfer-coding (<xref target="chunked.encoding"/>) 1729 is the final encoding, the message -body length is determined by reading1729 is the final encoding, the message body length is determined by reading 1730 1730 and decoding the chunked data until the transfer-coding indicates the 1731 1731 data is complete. … … 1733 1733 <t> 1734 1734 If a Transfer-Encoding header field is present in a response and the 1735 "chunked" transfer-coding is not the final encoding, the message -body1735 "chunked" transfer-coding is not the final encoding, the message body 1736 1736 length is determined by reading the connection until it is closed by 1737 1737 the server. 1738 1738 If a Transfer-Encoding header field is present in a request and the 1739 "chunked" transfer-coding is not the final encoding, the message -body1739 "chunked" transfer-coding is not the final encoding, the message body 1740 1740 length cannot be determined reliably; the server &MUST; respond with 1741 1741 the 400 (Bad Request) status code and then close the connection. … … 1749 1749 and thus ought to be handled as an error. The provided Content-Length &MUST; 1750 1750 be removed, prior to forwarding the message downstream, or replaced with 1751 the real message -body length after the transfer-coding is decoded.1751 the real message body length after the transfer-coding is decoded. 1752 1752 </t></x:lt> 1753 1753 <x:lt><t> … … 1768 1768 If a valid Content-Length header field 1769 1769 is present without Transfer-Encoding, its decimal value defines the 1770 message -body length in octets. If the actual number of octets sent in1770 message body length in octets. If the actual number of octets sent in 1771 1771 the message is less than the indicated Content-Length, the recipient 1772 1772 &MUST; consider the message to be incomplete and treat the connection 1773 1773 as no longer usable. 1774 1774 If the actual number of octets sent in the message is more than the indicated 1775 Content-Length, the recipient &MUST; only process the message -body up to the1775 Content-Length, the recipient &MUST; only process the message body up to the 1776 1776 field value's number of octets; the remainder of the message &MUST; either 1777 1777 be discarded or treated as the next message in a pipeline. For the sake of … … 1782 1782 <x:lt><t> 1783 1783 If this is a request message and none of the above are true, then the 1784 message -body length is zero (no message-body is present).1784 message body length is zero (no message body is present). 1785 1785 </t></x:lt> 1786 1786 <x:lt><t> 1787 Otherwise, this is a response message without a declared message -body1788 length, so the message -body length is determined by the number of octets1787 Otherwise, this is a response message without a declared message body 1788 length, so the message body length is determined by the number of octets 1789 1789 received prior to the server closing the connection. 1790 1790 </t></x:lt> … … 1799 1799 </t> 1800 1800 <t> 1801 A server &MAY; reject a request that contains a message -body but1801 A server &MAY; reject a request that contains a message body but 1802 1802 not a Content-Length by responding with 411 (Length Required). 1803 1803 </t> 1804 1804 <t> 1805 1805 Unless a transfer-coding other than "chunked" has been applied, 1806 a client that sends a request containing a message -body &SHOULD;1807 use a valid Content-Length header field if the message -body length1806 a client that sends a request containing a message body &SHOULD; 1807 use a valid Content-Length header field if the message body length 1808 1808 is known in advance, rather than the "chunked" encoding, since some 1809 1809 existing services respond to "chunked" with a 411 (Length Required) … … 1814 1814 </t> 1815 1815 <t> 1816 A client that sends a request containing a message -body &MUST; include a1816 A client that sends a request containing a message body &MUST; include a 1817 1817 valid Content-Length header field if it does not know the server will 1818 1818 handle HTTP/1.1 (or later) requests; such knowledge can be in the form … … 1833 1833 Response messages that are prematurely terminated, usually by closure 1834 1834 of the connection prior to receiving the expected number of octets or by 1835 failure to decode a transfer-encoded message -body, &MUST; be recorded1835 failure to decode a transfer-encoded message body, &MUST; be recorded 1836 1836 as incomplete. A response that terminates in the middle of the header 1837 1837 block (before the empty line is received) cannot be assumed to convey the … … 1839 1839 </t> 1840 1840 <t> 1841 A message -body that uses the chunked transfer encoding is1841 A message body that uses the chunked transfer encoding is 1842 1842 incomplete if the zero-sized chunk that terminates the encoding has not 1843 1843 been received. A message that uses a valid Content-Length is incomplete 1844 if the size of the message -body received (in octets) is less than the1844 if the size of the message body received (in octets) is less than the 1845 1845 value given by Content-Length. A response that has neither chunked 1846 1846 transfer encoding nor Content-Length is terminated by closure of the 1847 1847 connection, and thus is considered complete regardless of the number of 1848 message -body octets received, provided that the header block was received1848 message body octets received, provided that the header block was received 1849 1849 intact. 1850 1850 </t> 1851 1851 <t> 1852 A user agent &MUST-NOT; render an incomplete response message -body as if1852 A user agent &MUST-NOT; render an incomplete response message body as if 1853 1853 it were complete (i.e., some indication must be given to the user that an 1854 1854 error occurred). Cache requirements for incomplete responses are defined … … 1856 1856 </t> 1857 1857 <t> 1858 A server &MUST; read the entire request message -body or close1858 A server &MUST; read the entire request message body or close 1859 1859 the connection after sending its response, since otherwise the 1860 1860 remaining data on a persistent connection would be misinterpreted 1861 1861 as the next request. Likewise, 1862 a client &MUST; read the entire response message -body if it intends1862 a client &MUST; read the entire response message body if it intends 1863 1863 to reuse the same connection for a subsequent request. Pipelining 1864 1864 multiple requests on a connection is described in <xref target="pipelining"/>. … … 1870 1870 Older HTTP/1.0 client implementations might send an extra CRLF 1871 1871 after a POST request as a lame workaround for some early server 1872 applications that failed to read message -body content that was1872 applications that failed to read message body content that was 1873 1873 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT; 1874 1874 preface or follow a request with an extra CRLF. If terminating 1875 the request message -body with a line-ending is desired, then the1875 the request message body with a line-ending is desired, then the 1876 1876 client &MUST; include the terminating CRLF octets as part of the 1877 message -body length.1877 message body length. 1878 1878 </t> 1879 1879 <t> … … 2790 2790 <t> 2791 2791 A non-transforming proxy &MUST; preserve the message payload (&payload;), 2792 though it &MAY; change the message -body through application or removal2792 though it &MAY; change the message body through application or removal 2793 2793 of a transfer-coding (<xref target="transfer.codings"/>). 2794 2794 </t> … … 2878 2878 <section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor"> 2879 2879 <t> 2880 An HTTP/1.1 (or later) client sending a message -body &SHOULD; monitor2880 An HTTP/1.1 (or later) client sending a message body &SHOULD; monitor 2881 2881 the network connection for an error status code while it is transmitting 2882 2882 the request. If the client sees an error status code, it &SHOULD; -
draft-ietf-httpbis/latest/p2-semantics.html
r1539 r1544 460 460 } 461 461 @bottom-center { 462 content: "Expires August 2 2, 2012";462 content: "Expires August 23, 2012"; 463 463 } 464 464 @bottom-right { … … 513 513 <meta name="dct.creator" content="Reschke, J. F."> 514 514 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 515 <meta name="dct.issued" scheme="ISO8601" content="2012-02- 19">515 <meta name="dct.issued" scheme="ISO8601" content="2012-02-20"> 516 516 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 517 517 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "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."> … … 544 544 </tr> 545 545 <tr> 546 <td class="left">Expires: August 2 2, 2012</td>546 <td class="left">Expires: August 23, 2012</td> 547 547 <td class="right">HP</td> 548 548 </tr> … … 597 597 <tr> 598 598 <td class="left"></td> 599 <td class="right">February 19, 2012</td>599 <td class="right">February 20, 2012</td> 600 600 </tr> 601 601 </tbody> … … 627 627 in progress”. 628 628 </p> 629 <p>This Internet-Draft will expire on August 2 2, 2012.</p>629 <p>This Internet-Draft will expire on August 23, 2012.</p> 630 630 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 631 631 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 947 947 to a single application, so that this is clear. 948 948 </p> 949 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message -body on either the request or the response message949 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message 950 950 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 951 951 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 1438 1438 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1439 1439 </p> 1440 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message -body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied1440 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied 1441 1441 to ensure safe and proper transfer of the message. 1442 1442 </p> … … 1498 1498 </p> 1499 1499 <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p> 1500 <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message -body (as indicated by the presence of Content-Length or Transfer-Encoding), then1500 <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then 1501 1501 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions 1502 1502 to HTTP might use the OPTIONS body to make more detailed queries on the server. … … 1543 1543 <div id="rfc.iref.h.1"></div> 1544 1544 <div id="rfc.iref.m.3"></div> 1545 <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message -body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1545 <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1546 1546 representation implied by the request without transferring the representation body. This method is often used for testing 1547 1547 hypertext links for validity, accessibility, and recent modification. … … 1663 1663 <div id="rfc.iref.t.1"></div> 1664 1664 <div id="rfc.iref.m.7"></div> 1665 <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message -body of a 200 (OK) response. The final recipient is either1666 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message -body.1665 <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either 1666 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1667 1667 </p> 1668 1668 <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing … … 1671 1671 infinite loop. 1672 1672 </p> 1673 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message -body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1673 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1674 1674 </p> 1675 1675 <div id="rfc.iref.c.1"></div> … … 1768 1768 <dd>a representation of the target resource is sent in the response;</dd> 1769 1769 <dt>HEAD</dt> 1770 <dd>the same representation as GET, except without the message -body;</dd>1770 <dd>the same representation as GET, except without the message body;</dd> 1771 1771 <dt>POST</dt> 1772 1772 <dd>a representation describing or containing the result of the action;</dd> … … 1830 1830 automated data transfers to be prevalent, such as within distributed version control systems. 1831 1831 </p> 1832 <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message -body, and thus is always terminated by the first empty line after the header fields.1832 <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. 1833 1833 </p> 1834 1834 <div id="rfc.iref.29"></div> … … 1839 1839 another input action. 1840 1840 </p> 1841 <p id="rfc.section.7.2.6.p.2">The message -body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1841 <p id="rfc.section.7.2.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1842 1842 </p> 1843 1843 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2064 2064 <div id="rfc.iref.s.26"></div> 2065 2065 <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> 2066 <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message -body in the request2066 <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request 2067 2067 message. 2068 2068 </p> … … 3451 3451 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>>: "untangle ABNFs for header fields" 3452 3452 </li> 3453 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>>: "message -body in CONNECT request"3453 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>>: "message body in CONNECT request" 3454 3454 </li> 3455 3455 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1539 r1544 482 482 <t> 483 483 Due to the parsing rules defined in &message-body;, definitions of HTTP 484 methods cannot prohibit the presence of a message -body on either the request484 methods cannot prohibit the presence of a message body on either the request 485 485 or the response message (with responses to HEAD requests being the single 486 486 exception). Definitions of new methods cannot change this rule, but they can … … 813 813 </t> 814 814 <t> 815 A representation body is only present in a message when a message -body is815 A representation body is only present in a message when a message body is 816 816 present, as described in &message-body;. The representation body is obtained 817 from the message -body by decoding any Transfer-Encoding that might817 from the message body by decoding any Transfer-Encoding that might 818 818 have been applied to ensure safe and proper transfer of the message. 819 819 </t> … … 929 929 </t> 930 930 <t> 931 If the OPTIONS request includes a message -body (as indicated by the931 If the OPTIONS request includes a message body (as indicated by the 932 932 presence of Content-Length or Transfer-Encoding), then the media type 933 933 &MUST; be indicated by a Content-Type field. Although this … … 1026 1026 <t> 1027 1027 The HEAD method is identical to GET except that the server &MUST-NOT; 1028 return a message -body in the response. The metadata contained1028 return a message body in the response. The metadata contained 1029 1029 in the HTTP header fields in response to a HEAD request &SHOULD; be identical 1030 1030 to the information sent in response to a GET request. This method can … … 1271 1271 of the request message. The final recipient of the request 1272 1272 &SHOULD; reflect the message received back to the client as the 1273 message -body of a 200 (OK) response. The final recipient is either the1273 message body of a 200 (OK) response. The final recipient is either the 1274 1274 origin server or the first proxy to receive a Max-Forwards 1275 1275 value of zero (0) in the request (see <xref target="header.max-forwards"/>). 1276 A TRACE request &MUST-NOT; include a message -body.1276 A TRACE request &MUST-NOT; include a message body. 1277 1277 </t> 1278 1278 <t> … … 1287 1287 <t> 1288 1288 If the request is valid, the response &SHOULD; have a Content-Type of 1289 "message/http" (see &media-type-message-http;) and contain a message -body1289 "message/http" (see &media-type-message-http;) and contain a message body 1290 1290 that encloses a copy of the entire request message. 1291 1291 Responses to the TRACE method are not cacheable. … … 1487 1487 </t> 1488 1488 <t hangText="HEAD"> 1489 the same representation as GET, except without the message -body;1489 the same representation as GET, except without the message body; 1490 1490 </t> 1491 1491 <t hangText="POST"> … … 1604 1604 </t> 1605 1605 <t> 1606 The 204 response &MUST-NOT; include a message -body, and thus is always1606 The 204 response &MUST-NOT; include a message body, and thus is always 1607 1607 terminated by the first empty line after the header fields. 1608 1608 </t> … … 1620 1620 </t> 1621 1621 <t> 1622 The message -body included with the response &MUST; be empty. Note that1622 The message body included with the response &MUST; be empty. Note that 1623 1623 receivers still need to parse the response according to the algorithm defined 1624 1624 in &message-body;. … … 2049 2049 The server refuses to accept the request without a defined Content-Length. 2050 2050 The client &MAY; repeat the request if it adds a valid 2051 Content-Length header field containing the length of the message -body2051 Content-Length header field containing the length of the message body 2052 2052 in the request message. 2053 2053 </t> … … 4586 4586 <t> 4587 4587 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/251"/>: 4588 "message -body in CONNECT request"4588 "message body in CONNECT request" 4589 4589 </t> 4590 4590 </list> -
draft-ietf-httpbis/latest/p3-payload.html
r1528 r1544 460 460 } 461 461 @bottom-center { 462 content: "Expires August 10, 2012";462 content: "Expires August 23, 2012"; 463 463 } 464 464 @bottom-right { … … 511 511 <meta name="dct.creator" content="Reschke, J. F."> 512 512 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 513 <meta name="dct.issued" scheme="ISO8601" content="2012-02- 07">513 <meta name="dct.issued" scheme="ISO8601" content="2012-02-20"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 515 515 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 537 537 </tr> 538 538 <tr> 539 <td class="left">Expires: August 10, 2012</td>539 <td class="left">Expires: August 23, 2012</td> 540 540 <td class="right">J. Mogul</td> 541 541 </tr> … … 594 594 <tr> 595 595 <td class="left"></td> 596 <td class="right">February 7, 2012</td>596 <td class="right">February 20, 2012</td> 597 597 </tr> 598 598 </tbody> … … 622 622 in progress”. 623 623 </p> 624 <p>This Internet-Draft will expire on August 10, 2012.</p>624 <p>This Internet-Draft will expire on August 23, 2012.</p> 625 625 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 626 626 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 799 799 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 800 800 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 801 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5. 3</a>>801 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a>> 802 802 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 803 803 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2> … … 831 831 </p> 832 832 <ul class="empty"> 833 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5. 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.833 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 834 834 </li> 835 835 </ul> … … 837 837 </p> 838 838 <ul class="empty"> 839 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5. 1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.839 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 840 840 </li> 841 841 </ul> … … 843 843 </p> 844 844 <ul class="empty"> 845 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5. 1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.845 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 846 846 </li> 847 847 </ul> … … 855 855 <li>Pointer to specification text</li> 856 856 </ul> 857 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5 .1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).857 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 858 858 </p> 859 859 <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section. … … 900 900 </p> 901 901 <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> 902 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message -body.902 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message body. 903 903 All 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. 904 904 </p> 905 <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 does906 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 within907 each body-part of a multipart message -body do not have any significance to HTTP beyond that defined by their MIME semantics.905 <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 906 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 907 each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics. 908 908 </p> 909 909 <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". … … 932 932 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="payload" href="#payload">Payload</a></h1> 933 933 <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata, 934 in the form of header fields, and data, in the form of the sequence of octets in the message -body after any transfer-coding934 in the form of header fields, and data, in the form of the sequence of octets in the message body after any transfer-coding 935 935 has been decoded. 936 936 </p> … … 955 955 <tr> 956 956 <td class="left">Content-Length</td> 957 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>957 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 958 958 </tr> 959 959 <tr> … … 965 965 </div> 966 966 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 967 <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message -body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure967 <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure 968 968 safe and proper transfer of the message. 969 969 </p> … … 984 984 </p> 985 985 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2> 986 <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message -body or, if no message-body987 is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with988 the same effective request URI.986 <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message 987 body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request 988 with the same effective request URI. 989 989 </p> 990 990 <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p> … … 1101 1101 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 1102 1102 </p> 1103 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5. 3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.1103 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. 1104 1104 </p> 1105 1105 <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 1106 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information1106 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 1107 1107 within extension header fields not defined by this specification. 1108 1108 </p> … … 1154 1154 <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 1155 1155 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 1156 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5. 3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.1156 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 1157 1157 </p> 1158 1158 <div class="note" id="rfc.section.6.1.p.5"> … … 1284 1284 </li> 1285 1285 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 1286 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5. 3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)1286 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</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>, a qvalue of 0 means "not acceptable".) 1287 1287 </li> 1288 1288 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> … … 1546 1546 <td class="left">compress</td> 1547 1547 <td class="left">UNIX "compress" program method</td> 1548 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5. 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1548 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.2.1</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> 1549 1549 </td> 1550 1550 </tr> … … 1553 1553 <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>) 1554 1554 </td> 1555 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5. 1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1555 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.2.2</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> 1556 1556 </td> 1557 1557 </tr> … … 1559 1559 <td class="left">gzip</td> 1560 1560 <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> 1561 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5. 1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1561 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1562 1562 </td> 1563 1563 </tr> … … 1777 1777 </div> 1778 1778 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1> 1779 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message -body to be transmitted in an open variety of representations and with extensible mechanisms. However,1779 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message body to be transmitted in an open variety of representations and with extensible mechanisms. However, 1780 1780 RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were 1781 1781 carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, … … 1829 1829 </p> 1830 1830 <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> 1831 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.1831 <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 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 1832 1832 </p> 1833 1833 <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> … … 2247 2247 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a></li> 2248 2248 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">3.2</a></li> 2249 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.25">A.6</a></li> 2250 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.15">3.1</a></li> 2249 2251 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">6.7</a></li> 2250 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2251 <li><em>Section 5.1.2.1</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li> 2252 <li><em>Section 5.1.2</em> <a href="#rfc.xref.Part1.14">2.2.1</a></li> 2253 <li><em>Section 5.1.2.2</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li> 2254 <li><em>Section 5.1.2.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li> 2255 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li> 2256 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.15">3.1</a></li> 2257 <li><em>Section 8.6</em> <a href="#rfc.xref.Part1.25">A.6</a></li> 2252 <li><em>Section 5</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2253 <li><em>Section 5.2.1</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li> 2254 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.14">2.2.1</a></li> 2255 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li> 2256 <li><em>Section 5.2.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li> 2257 <li><em>Section 5.4.1</em> <a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li> 2258 2258 <li><em>Section 11</em> <a href="#rfc.xref.Part1.24">9</a></li> 2259 2259 </ul> … … 2261 2261 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.2">A.3</a><ul> 2262 2262 <li><em>Section 8</em> <a href="#rfc.xref.Part2.2">A.3</a></li> 2263 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.1">5.1</a></li>2263 <li><em>Section 10.10</em> <a href="#rfc.xref.Part2.1">5.1</a></li> 2264 2264 </ul> 2265 2265 </li> -
draft-ietf-httpbis/latest/p3-payload.xml
r1523 r1544 558 558 <t> 559 559 MIME provides for a number of "multipart" types — encapsulations of 560 one or more representations within a single message -body. All multipart560 one or more representations within a single message body. All multipart 561 561 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>, 562 562 and &MUST; include a boundary parameter as part of the media type … … 565 565 </t> 566 566 <t> 567 In general, HTTP treats a multipart message -body no differently than567 In general, HTTP treats a multipart message body no differently than 568 568 any other media type: strictly as payload. HTTP does not use the 569 multipart boundary as an indicator of message -body length.569 multipart boundary as an indicator of message body length. 570 570 <!-- jre: re-insert removed text pointing to caching? --> 571 571 In all other respects, an HTTP user agent &SHOULD; follow the same or similar 572 572 behavior as a MIME user agent would upon receipt of a multipart type. 573 The MIME header fields within each body-part of a multipart message -body573 The MIME header fields within each body-part of a multipart message body 574 574 do not have any significance to HTTP beyond that defined by 575 575 their MIME semantics. … … 627 627 the request method or response status code. The payload consists of 628 628 metadata, in the form of header fields, and data, in the form of the 629 sequence of octets in the message -body after any transfer-coding has629 sequence of octets in the message body after any transfer-coding has 630 630 been decoded. 631 631 </t> … … 657 657 <x:anchor-alias value="payload-body"/> 658 658 <t> 659 A payload body is only present in a message when a message -body is659 A payload body is only present in a message when a message body is 660 660 present, as described in &message-body;. The payload body is obtained 661 from the message -body by decoding any Transfer-Encoding that might661 from the message body by decoding any Transfer-Encoding that might 662 662 have been applied to ensure safe and proper transfer of the message. 663 663 </t> … … 694 694 <t> 695 695 Representation header fields define metadata about the representation data 696 enclosed in the message -body or, if no message-body is present, about696 enclosed in the message body or, if no message body is present, about 697 697 the representation that would have been transferred in a 200 response 698 698 to a simultaneous GET request with the same effective request URI. … … 2363 2363 <t> 2364 2364 HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to 2365 allow a message -body to be transmitted in an open variety of2365 allow a message body to be transmitted in an open variety of 2366 2366 representations and with extensible mechanisms. However, RFC 2045 2367 2367 discusses mail, and HTTP has a few features that are different from -
draft-ietf-httpbis/latest/p5-range.html
r1543 r1544 806 806 <ul> 807 807 <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 808 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.808 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. 809 809 </li> 810 810 <li>Date</li> … … 878 878 header fields in the stored response. 879 879 </p> 880 <p id="rfc.section.4.2.p.5">The combined response message -body consists of the union of partial content ranges in the new response and each of the selected880 <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected 881 881 responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete 200 (OK) response with a Content-Length header field that reflects the complete length. Otherwise, 882 882 the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists … … 988 988 </p> 989 989 <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation body (not necessarily the same as the 990 message -body).990 message body). 991 991 </p> 992 992 <div id="rule.ranges-specifier"> … … 1267 1267 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="internet.media.type.multipart.byteranges" href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></h1> 1268 1268 <p id="rfc.section.A.p.1">When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple 1269 non-overlapping ranges), these are transmitted as a multipart message -body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.1269 non-overlapping ranges), these are transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. 1270 1270 </p> 1271 1271 <div class="note" id="rfc.section.A.p.2"> -
draft-ietf-httpbis/latest/p5-range.xml
r1543 r1544 416 416 Content-Length header field is present in the response, its 417 417 value &MUST; match the actual number of octets transmitted in the 418 message -body.418 message body. 419 419 </t> 420 420 <t> … … 556 556 </t> 557 557 <t> 558 The combined response message -body consists of the union of partial558 The combined response message body consists of the union of partial 559 559 content ranges in the new response and each of the selected responses. 560 560 If the union consists of the entire range of the representation, then the … … 786 786 <t> 787 787 Byte range specifications in HTTP apply to the sequence of bytes in 788 the representation body (not necessarily the same as the message -body).788 the representation body (not necessarily the same as the message body). 789 789 </t> 790 790 <t anchor="rule.ranges-specifier"> … … 1409 1409 content of multiple ranges (a response to a request for multiple 1410 1410 non-overlapping ranges), these are transmitted as a multipart 1411 message -body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called1411 message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called 1412 1412 "multipart/byteranges". The following is to be registered with IANA <xref target="RFC4288"/>. 1413 1413 </t> -
draft-ietf-httpbis/latest/p6-cache.html
r1531 r1544 463 463 } 464 464 @bottom-center { 465 content: "Expires August 10, 2012";465 content: "Expires August 23, 2012"; 466 466 } 467 467 @bottom-right { … … 511 511 <meta name="dct.creator" content="Reschke, J. F."> 512 512 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 513 <meta name="dct.issued" scheme="ISO8601" content="2012-02- 07">513 <meta name="dct.issued" scheme="ISO8601" content="2012-02-20"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 515 515 <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 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."> … … 537 537 </tr> 538 538 <tr> 539 <td class="left">Expires: August 10, 2012</td>539 <td class="left">Expires: August 23, 2012</td> 540 540 <td class="right">J. Mogul</td> 541 541 </tr> … … 602 602 <tr> 603 603 <td class="left"></td> 604 <td class="right">February 7, 2012</td>604 <td class="right">February 20, 2012</td> 605 605 </tr> 606 606 </tbody> … … 632 632 in progress”. 633 633 </p> 634 <p>This Internet-Draft will expire on August 10, 2012.</p>634 <p>This Internet-Draft will expire on August 23, 2012.</p> 635 635 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 636 636 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 879 879 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, 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#http.date" title="Date/Time Formats">Section 8</a>> 880 880 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 881 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8. 8</a>>881 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a>> 882 882 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 883 883 </pre><h2 id="rfc.section.1.5"><a href="#rfc.section.1.5">1.5</a> <a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h2> … … 941 941 </p> 942 942 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire 943 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message -body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content)943 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content) 944 944 response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does 945 945 not understand the range units used in those fields. … … 1059 1059 <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the 1060 1060 response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic 1061 operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.1061 operations. See <a href="p2-semantics.html#header.date" title="Date">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 1062 1062 </li> 1063 1063 </ul> … … 1245 1245 <p id="rfc.section.2.8.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or 1246 1246 more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the 1247 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4 </a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.1247 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1248 1248 </p> 1249 1249 <p id="rfc.section.2.8.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: … … 2451 2451 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a></li> 2452 2452 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li> 2453 <li><em>Section 8. 8</em> <a href="#rfc.xref.Part1.9">1.4.2</a></li>2453 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.9">1.4.2</a></li> 2454 2454 <li><em>Section 11</em> <a href="#rfc.xref.Part1.17">7</a></li> 2455 2455 </ul> … … 2459 2459 <li><em>Section 7</em> <a href="#rfc.xref.Part2.4">2.3.1.1</a></li> 2460 2460 <li><em>Section 8</em> <a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li> 2461 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.5">2.3.2</a></li>2461 <li><em>Section 10.2</em> <a href="#rfc.xref.Part2.5">2.3.2</a></li> 2462 2462 </ul> 2463 2463 </li> … … 2470 2470 </li> 2471 2471 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1</a>, <a href="#rfc.xref.Part5.2">2.8</a>, <a href="#rfc.xref.Part5.3">2.8</a>, <a href="#Part5"><b>8.1</b></a><ul> 2472 <li><em>Section 4 </em> <a href="#rfc.xref.Part5.3">2.8</a></li>2472 <li><em>Section 4.2</em> <a href="#rfc.xref.Part5.3">2.8</a></li> 2473 2473 </ul> 2474 2474 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r1530 r1544 595 595 If the request is GET, the response status is 200 (OK), and the entire 596 596 response header block has been received, a cache &MAY; store an incomplete 597 response message -body if the cache entry is recorded as incomplete.597 response message body if the cache entry is recorded as incomplete. 598 598 Likewise, a 206 (Partial Content) response &MAY; be stored as if it were 599 599 an incomplete 200 (OK) cache entry. However, a cache &MUST-NOT; store
Note: See TracChangeset
for help on using the changeset viewer.