Changeset 865 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 22/07/10 07:04:55 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r859 r865 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 1">406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-22"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: January 2 2, 2011</td>437 <td class="left">Expires: January 23, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">July 2 1, 2010</td>490 <td class="right">July 22, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire in January 2 2, 2011.</p>518 <p>This Internet-Draft will expire in January 23, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1119 1119 <p id="rfc.section.3.p.2">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two 1120 1120 types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses), 1121 and in the algorithm for determining the length of the message-body (<a href="#message.body .length">Paragraph 7</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different1121 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 1122 1122 start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown 1123 1123 or invalid request method) and clients are implemented to only expect a response. … … 1220 1220 (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length. 1221 1221 </p> 1222 <div id="message.body.length"> 1223 <p id="rfc.section.3.3.p.7">The length of the message-body is determined by one of the following (in order of precedence):</p> 1224 </div> 1222 <p id="rfc.section.3.3.p.7">The length of the message-body is determined by one of the following (in order of precedence):</p> 1225 1223 <p id="rfc.section.3.3.p.8"> </p> 1226 1224 <ol> … … 1570 1568 </p> 1571 1569 <p id="rfc.section.6.2.p.6">Whenever a transfer-coding is applied to a payload body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding 1572 is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. These rules allow the recipient to determine the message-body length of the message 1573 (<a href="#message.body.length">Paragraph 7</a>). 1570 is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. 1574 1571 </p> 1575 1572 <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport 1576 1573 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic 1577 of message-bodies is the difficulty in determining the exact body length (<a href="#message.body.length">Paragraph 7</a>), or the desire to encrypt data over a shared transport.1574 of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section 3.3</a>), or the desire to encrypt data over a shared transport. 1578 1575 </p> 1579 1576 <p id="rfc.section.6.2.p.8">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. … … 1763 1760 <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix B.2</a> for more information on backward compatibility with HTTP/1.0 clients. 1764 1761 </p> 1765 <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body .length">Paragraph 7</a>.1762 <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 1766 1763 </p> 1767 1764 <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> … … 2027 2024 <div id="rfc.figure.u.62"></div><pre class="text"> Content-Length: 3495 2028 2025 </pre><p id="rfc.section.9.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length 2029 can be determined prior to being transferred. 2030 </p> 2031 <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.body.length">Paragraph 7</a> describes how to determine the length of a message-body if a Content-Length is not given. 2032 </p> 2033 <p id="rfc.section.9.2.p.7">Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional 2034 field used within the "message/external-body" content-type. 2026 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. 2027 </p> 2028 <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p> 2029 <p id="rfc.section.9.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is 2030 an optional field used within the "message/external-body" content-type. 2035 2031 </p> 2036 2032 <div id="rfc.iref.d.3"></div> … … 2956 2952 <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2957 2953 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2958 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body .length">3.3.p.7</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)2954 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body" title="Message Body">3.3</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) 2959 2955 </p> 2960 2956 <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 … … 2981 2977 <p id="rfc.section.B.4.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section 2.5</a>) 2982 2978 </p> 2983 <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.body .length">3.3.p.7</a>)2979 <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.body" title="Message Body">3.3</a>) 2984 2980 </p> 2985 2981 <p id="rfc.section.B.4.p.5">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>)
Note: See TracChangeset
for help on using the changeset viewer.