Changeset 2097 for draft-ietf-httpbis/latest

Timestamp:

07/01/13 07:45:18 (10 years ago)

Author:

fielding@…

Message:

(editorial) update description of PUT

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (1 diff)
• p2-semantics.xml (modified) (1 diff)

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

@@ -1475 +1475 @@
          the server.
       </p>
-      <p id="rfc.section.4.3.4.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.
-         The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such
-         as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT
-         request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent
-         and visible to intermediaries, even though the exact effect is only known by the origin server.
-      </p>
-      <p id="rfc.section.4.3.4.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that
-         is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to
+      <p id="rfc.section.4.3.4.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation.
+         The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics,
+         whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the
+         intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
+      </p>
+      <p id="rfc.section.4.3.4.p.8">Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that
+         selects a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to
          the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
          to a different URI, then the origin server <em class="bcp14">MUST</em> send an appropriate <a href="#status.3xx" class="smpl">3xx (Redirection)</a> response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.

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

@@ -1433 +1433 @@
 <t>
    The fundamental difference between the POST and PUT methods is
-   highlighted by the different intent for the target resource.
+   highlighted by the different intent for the enclosed representation.
    The target resource in a POST request is intended to handle the
-   enclosed representation as a data-accepting process, such as for
-   a gateway to some other protocol or a document that accepts annotations.
-   In contrast, the target resource in a PUT request is intended to
-   take the enclosed representation as a new or replacement value.
-   Hence, the intent of PUT is idempotent and visible to intermediaries,
-   even though the exact effect is only known by the origin server.
-</t>
-<t>
-   Proper interpretation of a PUT request presumes that the user agent
-   knows what target resource is desired.  A service that is intended
-   to select a proper URI on behalf of the client, after receiving
-   a state-changing request, &SHOULD; be implemented using the POST
-   method rather than PUT.  If the origin server will not make the
-   requested PUT state change to the target resource and instead
-   wishes to have it applied to a different resource, such as when the
-   resource has been moved to a different URI, then the origin server
-   &MUST; send an appropriate <x:ref>3xx (Redirection)</x:ref> response;
-   the user agent &MAY; then make its own decision regarding whether or not to
+   enclosed representation according to the resource's own semantics,
+   whereas the enclosed representation in a PUT request is defined as
+   replacing the state of the target resource. Hence, the intent of PUT is
+   idempotent and visible to intermediaries, even though the exact effect is
+   only known by the origin server.
+</t>
+<t>
+   Proper interpretation of a PUT request presumes that the user agent knows
+   which target resource is desired. A service that selects a proper URI on
+   behalf of the client, after receiving a state-changing request, &SHOULD; be
+   implemented using the POST method rather than PUT. If the origin server
+   will not make the requested PUT state change to the target resource and
+   instead wishes to have it applied to a different resource, such as when the
+   resource has been moved to a different URI, then the origin server &MUST;
+   send an appropriate <x:ref>3xx (Redirection)</x:ref> response; the
+   user agent &MAY; then make its own decision regarding whether or not to
    redirect the request.
 </t>