Changeset 865 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

Jul 22, 2010, 12:04:55 AM (9 years ago)

Author:

fielding@…

Message:

regenerate html

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (11 diffs)

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

@@ -404 +404 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-07-22">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
@@ -435 +435 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 22, 2011</td>
+               <td class="left">Expires: January 23, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -488 +488 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 21, 2010</td>
+               <td class="right">July 22, 2010</td>
             </tr>
          </tbody>
@@ -516 +516 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in January 22, 2011.</p>
+      <p>This Internet-Draft will expire in January 23, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <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
          types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses),
-         and in the algorithm for determining the length of the message-body (<a href="#message.body.length">Paragraph&nbsp;7</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
+         and in the algorithm for determining the length of the message-body (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
          start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown
          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.
       </p>
-      <div id="message.body.length">
-         <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>
-      </div>
+      <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>
       <p id="rfc.section.3.3.p.8"> </p>
       <ol>
@@ -1570 +1568 @@
       </p>
       <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
-         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
-         (<a href="#message.body.length">Paragraph&nbsp;7</a>).
+         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.
       </p>
       <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
          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
-         of message-bodies is the difficulty in determining the exact body length (<a href="#message.body.length">Paragraph&nbsp;7</a>), or the desire to encrypt data over a shared transport.
+         of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>), or the desire to encrypt data over a shared transport.
       </p>
       <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&nbsp;B.2</a> for more information on backward compatibility with HTTP/1.0 clients.
       </p>
-      <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body.length">Paragraph&nbsp;7</a>.
+      <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&nbsp;3.3</a>.
       </p>
       <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
@@ -2027 +2024 @@
       <div id="rfc.figure.u.62"></div><pre class="text">  Content-Length: 3495
 </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
-         can be determined prior to being transferred.
-      </p>
-      <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.body.length">Paragraph&nbsp;7</a> describes how to determine the length of a message-body if a Content-Length is not given.
-      </p>
-      <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
-         field used within the "message/external-body" content-type.
+         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
+      </p>
+      <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
+      <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
+         an optional field used within the "message/external-body" content-type.
       </p>
       <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
          for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
-         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>)
+         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>)
       </p>
       <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&nbsp;2.5</a>)
       </p>
-      <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>)
+      <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>)
       </p>
       <p id="rfc.section.B.4.p.5">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)