Ignore:
Timestamp:
14/09/13 19:57:05 (7 years ago)
Author:
fielding@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2393 r2395  
    14601460      </p>
    14611461      <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
    1462          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.
     1462         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.
    14631463      </p>
    14641464      <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).
     
    15051505         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.
    15061506      </p>
    1507       <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)
    1508          that is separate from the URIs identifying each particular version (different resources that at one point shared the same
    1509          state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
    1510          version resource in addition to changing the state of the target resource, and might also cause links to be added between
    1511          the related resources.
    1512       </p>
    1513       <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
    1514          representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
    1515          a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
    1516          example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
    1517       </p>
    1518       <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
    1519          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>).
     1507      <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
     1508         a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version
     1509         (different resources that at one point shared the same state as the current version resource). A successful PUT request on
     1510         "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource,
     1511         and might also cause links to be added between the related resources.
     1512      </p>
     1513      <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
     1514         updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource,
     1515         or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined
     1516         in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
     1517      </p>
     1518      <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
     1519         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>).
    15201520      </p>
    15211521      <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>
Note: See TracChangeset for help on using the changeset viewer.