Changeset 865
- Timestamp:
- 22/07/10 07:04:55 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 5 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>) -
draft-ietf-httpbis/latest/p2-semantics.html
r861 r865 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 1">405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-22"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: January 2 2, 2011</td>436 <td class="left">Expires: January 23, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">July 2 1, 2010</td>489 <td class="right">July 22, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in January 2 2, 2011.</p>516 <p>This Internet-Draft will expire in January 23, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p3-payload.html
r859 r865 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 1">403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-22"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: January 2 2, 2011</td>429 <td class="left">Expires: January 23, 2011</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">July 2 1, 2010</td>486 <td class="right">July 22, 2010</td> 487 487 </tr> 488 488 </tbody> … … 510 510 in progress”. 511 511 </p> 512 <p>This Internet-Draft will expire in January 2 2, 2011.</p>512 <p>This Internet-Draft will expire in January 23, 2011.</p> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p6-cache.html
r861 r865 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 1">404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-22"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: January 2 2, 2011</td>430 <td class="left">Expires: January 23, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">July 2 1, 2010</td>491 <td class="right">July 22, 2010</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire in January 2 2, 2011.</p>517 <p>This Internet-Draft will expire in January 23, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r861 r865 394 394 <meta name="dct.creator" content="Reschke, J. F."> 395 395 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 396 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 1">396 <meta name="dct.issued" scheme="ISO8601" content="2010-07-22"> 397 397 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 398 398 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 425 425 </tr> 426 426 <tr> 427 <td class="left">Expires: January 2 2, 2011</td>427 <td class="left">Expires: January 23, 2011</td> 428 428 <td class="right">HP</td> 429 429 </tr> … … 478 478 <tr> 479 479 <td class="left"></td> 480 <td class="right">July 2 1, 2010</td>480 <td class="right">July 22, 2010</td> 481 481 </tr> 482 482 </tbody> … … 504 504 in progress”. 505 505 </p> 506 <p>This Internet-Draft will expire in January 2 2, 2011.</p>506 <p>This Internet-Draft will expire in January 23, 2011.</p> 507 507 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 508 508 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.