Changeset 2097


Ignore:
Timestamp:
Jan 6, 2013, 11:45:18 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) update description of PUT

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

Legend:

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

    r2096 r2097  
    14751475         the server.
    14761476      </p>
    1477       <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.
    1478          The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such
    1479          as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT
    1480          request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent
    1481          and visible to intermediaries, even though the exact effect is only known by the origin server.
    1482       </p>
    1483       <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
    1484          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
     1477      <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         The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics,
     1479         whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the
     1480         intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
     1481      </p>
     1482      <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
     1483         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
    14851484         the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
    14861485         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

    r2096 r2097  
    14331433<t>
    14341434   The fundamental difference between the POST and PUT methods is
    1435    highlighted by the different intent for the target resource.
     1435   highlighted by the different intent for the enclosed representation.
    14361436   The target resource in a POST request is intended to handle the
    1437    enclosed representation as a data-accepting process, such as for
    1438    a gateway to some other protocol or a document that accepts annotations.
    1439    In contrast, the target resource in a PUT request is intended to
    1440    take the enclosed representation as a new or replacement value.
    1441    Hence, the intent of PUT is idempotent and visible to intermediaries,
    1442    even though the exact effect is only known by the origin server.
    1443 </t>
    1444 <t>
    1445    Proper interpretation of a PUT request presumes that the user agent
    1446    knows what target resource is desired.  A service that is intended
    1447    to select a proper URI on behalf of the client, after receiving
    1448    a state-changing request, &SHOULD; be implemented using the POST
    1449    method rather than PUT.  If the origin server will not make the
    1450    requested PUT state change to the target resource and instead
    1451    wishes to have it applied to a different resource, such as when the
    1452    resource has been moved to a different URI, then the origin server
    1453    &MUST; send an appropriate <x:ref>3xx (Redirection)</x:ref> response;
    1454    the user agent &MAY; then make its own decision regarding whether or not to
     1437   enclosed representation according to the resource's own semantics,
     1438   whereas the enclosed representation in a PUT request is defined as
     1439   replacing the state of the target resource. Hence, the intent of PUT is
     1440   idempotent and visible to intermediaries, even though the exact effect is
     1441   only known by the origin server.
     1442</t>
     1443<t>
     1444   Proper interpretation of a PUT request presumes that the user agent knows
     1445   which target resource is desired. A service that selects a proper URI on
     1446   behalf of the client, after receiving a state-changing request, &SHOULD; be
     1447   implemented using the POST method rather than PUT. If the origin server
     1448   will not make the requested PUT state change to the target resource and
     1449   instead wishes to have it applied to a different resource, such as when the
     1450   resource has been moved to a different URI, then the origin server &MUST;
     1451   send an appropriate <x:ref>3xx (Redirection)</x:ref> response; the
     1452   user agent &MAY; then make its own decision regarding whether or not to
    14551453   redirect the request.
    14561454</t>
Note: See TracChangeset for help on using the changeset viewer.