Changeset 2395

Timestamp:

14/09/13 19:57:05 (8 years ago)

Author:

fielding@…

Message:

strengthen response requirements on PUT when allowed for the target resource; addresses #475

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (2 diffs)
• p2-semantics.xml (modified) (3 diffs)

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

@@ -1460 +1460 @@
       </p>
       <p id="rfc.section.4.3.4.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance
-         with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
+         with the state of the enclosed representation, then the origin server <em class="bcp14">MUST</em> send either a <a href="#status.200" class="smpl">200 (OK)</a> or a <a href="#status.204" class="smpl">204 (No Content)</a> response to indicate successful completion of the request.
       </p>
       <p id="rfc.section.4.3.4.p.3">An origin server <em class="bcp14">SHOULD</em> ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state).
@@ -1505 +1505 @@
          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.
       </p>
-      <p id="rfc.section.4.3.4.p.10">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource)
-         that is separate from the URIs identifying each particular version (different resources that at one point shared the same
-         state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
-         version resource in addition to changing the state of the target resource, and might also cause links to be added between
-         the related resources.
-      </p>
-      <p id="rfc.section.4.3.4.p.11">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
-         representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
-         a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
-         example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
-      </p>
-      <p id="rfc.section.4.3.4.p.12">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses
-         for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation" title="Invalidation">Section 4.4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
+      <p id="rfc.section.4.3.4.p.10">A PUT request applied to the target resource can have side-effects on other resources. For example, an article might have
+         a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version
+         (different resources that at one point shared the same state as the current version resource). A successful PUT request on
+         "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource,
+         and might also cause links to be added between the related resources.
+      </p>
+      <p id="rfc.section.4.3.4.p.11">An origin server that allows PUT on a given target resource <em class="bcp14">MUST</em> send a <a href="#status.400" class="smpl">400 (Bad Request)</a> response to a PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since the payload is likely to be partial content that has been mistakenly PUT as a full representation. Partial content
+         updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource,
+         or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined
+         in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
+      </p>
+      <p id="rfc.section.4.3.4.p.12">Responses to the PUT method are not cacheable. If a successful PUT request passes through a cache that has one or more stored
+         responses for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation" title="Invalidation">Section 4.4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
       </p>
       <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>

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

@@ -1433 +1433 @@
    target resource does have a current representation and that representation is
    successfully modified in accordance with the state of the enclosed
-   representation, then either a <x:ref>200 (OK)</x:ref> or <x:ref>204 (No Content)</x:ref>
-   response &SHOULD; be sent to indicate successful completion of the request.
+   representation, then the origin server &MUST; send either a
+   <x:ref>200 (OK)</x:ref> or a <x:ref>204 (No Content)</x:ref> response to
+   indicate successful completion of the request.
 </t>
 <t>
@@ -1519 +1520 @@
 </t>
 <t>
-   A PUT request applied to the target resource &MAY; have side-effects
+   A PUT request applied to the target resource can have side-effects
    on other resources.  For example, an article might have a URI for
    identifying "the current version" (a resource) that is separate
@@ -1530 +1531 @@
 </t>
 <t>
-   An origin server &SHOULD; reject any PUT request that contains a
+   An origin server that allows PUT on a given target resource &MUST; send a
+   <x:ref>400 (Bad Request)</x:ref> response to a PUT request that contains a
    <x:ref>Content-Range</x:ref> header field (&header-content-range;), since
-   it might be misinterpreted as partial content (or might be partial content
-   that is being mistakenly PUT as a full representation).  Partial content
-   updates are possible by targeting a separately identified resource with
-   state that overlaps a portion of the larger resource, or by using a
-   different method that has been specifically defined for partial
+   the payload is likely to be partial content that has been mistakenly PUT as
+   a full representation.
+   Partial content updates are possible by targeting a separately identified
+   resource with state that overlaps a portion of the larger resource, or by
+   using a different method that has been specifically defined for partial
    updates (for example, the PATCH method defined in
    <xref target="RFC5789"/>).
 </t>
 <t>
-   Responses to the PUT method are not cacheable. If a PUT request passes 
-   through a cache that has one or more stored responses for the effective 
-   request URI, those stored responses will be invalidated (see
-   &p6-invalid;).
+   Responses to the PUT method are not cacheable. If a successful PUT request
+   passes through a cache that has one or more stored responses for the
+   effective request URI, those stored responses will be invalidated
+   (see &p6-invalid;).
 </t>
 </section>