Changeset 2091 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

Jan 5, 2013, 11:26:25 PM (7 years ago)

Author:

fielding@…

Message:

(editorial) more consistency regarding representation; explain what HEAD does instead of what it doesn't do

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (3 diffs)

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

@@ -1144 +1144 @@
 </pre><div id="rfc.iref.p.1"></div>
       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="payload" href="#payload">Payload Semantics</a></h2>
-      <p id="rfc.section.3.3.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or
+      <p id="rfc.section.3.3.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might contain only the associated representation's header fields (e.g., responses to HEAD) or
          only some part(s) of the representation data (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
       </p>
-      <p id="rfc.section.3.3.p.2">The purpose of a payload in a request is defined by the method semantics. In a response, the payload's purpose is defined
-         by both the request method and the response status code.
-      </p>
-      <p id="rfc.section.3.3.p.3">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
+      <p id="rfc.section.3.3.p.2">The purpose of a payload in a request is defined by the method semantics. For example, a representation in the payload of
+         a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
          an HTML form.
       </p>
-      <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) ought to contain a representation of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
-         current representation of the target resource after applying the processing. Response messages with an error status code usually
-         contain a representation of the error condition, such that it describes the error state and what next steps are suggested
-         for resolving it.
-      </p>
-      <p id="rfc.section.3.3.p.5">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
+      <p id="rfc.section.3.3.p.3">In a response, the payload's purpose is defined by both the request method and the response status code. For example, the
+         payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
+         state of the target resource after applying the processing. Response messages with an error status code usually contain a
+         payload that represents the error condition, such that it describes the error state and what next steps are suggested for
+         resolving it.
+      </p>
+      <p id="rfc.section.3.3.p.4">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
          header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
       </p>
@@ -1288 +1287 @@
                <tr>
                   <td class="left">HEAD</td>
-                  <td class="left">Same as GET, but do not include a message body in the response.</td>
+                  <td class="left">Same as GET, but only transfer the status line and header block.</td>
                   <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3.2</a></td>
                </tr>
@@ -1407 +1406 @@
       <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
       <div id="rfc.iref.h.1"></div>
-      <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send 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
+      <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response (i.e., the response terminates at the end of the header block). 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
          selected representation without transferring the representation data. This method is often used for testing hypertext links
          for validity, accessibility, and recent modification.