Ignore:
Timestamp:
21/02/12 02:12:49 (10 years ago)
Author:
fielding@…
Message:

For consistency and readability, do not hyphenate "message body"
unless we are referring to the message-body ABNF rule.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1539 r1544  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 22, 2012";
     462       content: "Expires August 23, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    513513      <meta name="dct.creator" content="Reschke, J. F.">
    514514      <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">
    516516      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    517517      <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 &#34;HTTP/1.1&#34; 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.">
    … …  
    544544            </tr>
    545545            <tr>
    546                <td class="left">Expires: August 22, 2012</td>
     546               <td class="left">Expires: August 23, 2012</td>
    547547               <td class="right">HP</td>
    548548            </tr>
    … …  
    597597            <tr>
    598598               <td class="left"></td>
    599                <td class="right">February 19, 2012</td>
     599               <td class="right">February 20, 2012</td>
    600600            </tr>
    601601         </tbody>
    … …  
    627627         in progress”.
    628628      </p>
    629       <p>This Internet-Draft will expire on August 22, 2012.</p>
     629      <p>This Internet-Draft will expire on August 23, 2012.</p>
    630630      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    631631      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    947947         to a single application, so that this is clear.
    948948      </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 message
     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 message
    950950         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
    951951         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    … …  
    14381438         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>.
    14391439      </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 applied
     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 applied
    14411441         to ensure safe and proper transfer of the message.
    14421442      </p>
    … …  
    14981498      </p>
    14991499      <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), then
     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), then
    15011501         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
    15021502         to HTTP might use the OPTIONS body to make more detailed queries on the server.
    … …  
    15431543      <div id="rfc.iref.h.1"></div>
    15441544      <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 the
     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 the
    15461546         representation implied by the request without transferring the representation body. This method is often used for testing
    15471547         hypertext links for validity, accessibility, and recent modification.
    … …  
    16631663      <div id="rfc.iref.t.1"></div>
    16641664      <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 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&nbsp;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&nbsp;10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    16671667      </p>
    16681668      <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
    … …  
    16711671         infinite loop.
    16721672      </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.
    16741674      </p>
    16751675      <div id="rfc.iref.c.1"></div>
    … …  
    17681768         <dd>a representation of the target resource is sent in the response;</dd>
    17691769         <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>
    17711771         <dt>POST</dt>
    17721772         <dd>a representation describing or containing the result of the action;</dd>
    … …  
    18301830         automated data transfers to be prevalent, such as within distributed version control systems.
    18311831      </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.
    18331833      </p>
    18341834      <div id="rfc.iref.29"></div>
    … …  
    18391839         another input action.
    18401840      </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>.
    18421842      </p>
    18431843      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    20642064      <div id="rfc.iref.s.26"></div>
    20652065      <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a>&nbsp;<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 request
     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 request
    20672067         message.
    20682068      </p>
    … …  
    34513451         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
    34523452         </li>
    3453          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>&gt;: "message-body in CONNECT request"
     3453         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>&gt;: "message body in CONNECT request"
    34543454         </li>
    34553455      </ul>
Note: See TracChangeset for help on using the changeset viewer.