Changeset 2111


Ignore:
Timestamp:
Jan 11, 2013, 12:39:05 AM (7 years ago)
Author:
fielding@…
Message:

ensure that a validator field sent in response to a successful PUT means something useful; addresses #22 (along with [2110])

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

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

    r2110 r2111  
    14761476         the server.
    14771477      </p>
    1478       <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.
     1478      <p id="rfc.section.4.3.4.p.7">An origin server <em class="bcp14">MUST NOT</em> send a validator header field (<a href="#response.validator" title="Validator Header Fields">Section&nbsp;7.2</a>), such as an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field, in a successful response to PUT unless the request's representation data was saved without any transformation applied
     1479         to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request)
     1480         and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation
     1481         body it has in memory remains current as a result of the PUT, thus not in need of retrieving again from the origin server,
     1482         and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental
     1483         overwrites.
     1484      </p>
     1485      <p id="rfc.section.4.3.4.p.8">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation.
    14791486         The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics,
    14801487         whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the
    14811488         intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
    14821489      </p>
    1483       <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
     1490      <p id="rfc.section.4.3.4.p.9">Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that
    14841491         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
    14851492         the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
    14861493         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.
    14871494      </p>
    1488       <p id="rfc.section.4.3.4.p.9">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)
     1495      <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)
    14891496         that is separate from the URIs identifying each particular version (different resources that at one point shared the same
    14901497         state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
     
    14921499         the related resources.
    14931500      </p>
    1494       <p id="rfc.section.4.3.4.p.10">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 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><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
     1501      <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 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><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
    14951502         representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
    14961503         a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
    14971504         example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
    14981505      </p>
    1499       <p id="rfc.section.4.3.4.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses
     1506      <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
    15001507         for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    15011508      </p>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2110 r2111  
    14431443</t>
    14441444<t>
     1445   An origin server &MUST-NOT; send a validator header field
     1446   (<xref target="response.validator"/>), such as an <x:ref>ETag</x:ref> or
     1447   <x:ref>Last-Modified</x:ref> field, in a successful response to PUT unless
     1448   the request's representation data was saved without any transformation
     1449   applied to the body (i.e., the resource's new representation data is
     1450   identical to the representation data received in the PUT request) and the
     1451   validator field value reflects the new representation.
     1452   This requirement allows a user agent to know when the representation body
     1453   it has in memory remains current as a result of the PUT, thus not in need
     1454   of retrieving again from the origin server, and that the new validator(s)
     1455   received in the response can be used for future conditional requests in
     1456   order to prevent accidental overwrites.
     1457</t>
     1458<t>
    14451459   The fundamental difference between the POST and PUT methods is
    14461460   highlighted by the different intent for the enclosed representation.
Note: See TracChangeset for help on using the changeset viewer.