Ignore:
Timestamp:
10/01/13 08:40:38 (10 years ago)
Author:
fielding@…
Message:

(editorial) further refine definition of DELETE to specify the universal definition first (independent of whether the resource allows GET), before specifying its potential effects

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

Legend:

Unmodified
Added
Removed

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

    r2102 r2103  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 12, 2013";
     451       content: "Expires July 14, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2013-01-08">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-01-10">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">January 8, 2013</td>
     524               <td class="right">January 10, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: July 12, 2013</td>
     527               <td class="left">Expires: July 14, 2013</td>
    528528               <td class="right"></td>
    529529            </tr>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on July 12, 2013.</p>
     555      <p>This Internet-Draft will expire on July 14, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    15011501      <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>
    15021502      <div id="rfc.iref.d.2"></div>
    1503       <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the <a href="#resources" class="smpl">target resource</a> and its current representations or implementation. In effect, this method is similar to the rm command in UNIX: it expresses
    1504          a deletion operation on the URI mapping of the origin server, rather than an expectation that the information be deleted.
    1505          The representations might or might not be destroyed by the origin server, and the associated storage might or might not be
    1506          reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond
    1507          the scope of this specification).
    1508       </p>
    1509       <p id="rfc.section.4.3.5.p.2">Relatively few resources allow the DELETE method — its primary use is for remote authoring environments, where the user has
     1503      <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the <a href="#resources" class="smpl">target resource</a> and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation
     1504         on the URI mapping of the origin server, rather than an expectation that the previously associated information be deleted.
     1505      </p>
     1506      <p id="rfc.section.4.3.5.p.2">If the target resource has one or more current representations, they might or might not be destroyed by the origin server,
     1507         and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation
     1508         by the origin server (which are beyond the scope of this specification). Likewise, other implementation aspects of a resource
     1509         might need to be deactivated or archived as a result of a DELETE, such as database or gateway connections. In general, it
     1510         is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing
     1511         the deletion.
     1512      </p>
     1513      <p id="rfc.section.4.3.5.p.3">Relatively few resources allow the DELETE method — its primary use is for remote authoring environments, where the user has
    15101514         some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified
    15111515         via the Location header field after a <a href="#status.201" class="smpl">201 (Created)</a> response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent
    … …  
    15131517         use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository.
    15141518      </p>
    1515       <p id="rfc.section.4.3.5.p.3">If a DELETE method is successfully applied, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.202" class="smpl">202 (Accepted)</a> status code if the action seems okay but has not yet been enacted, a <a href="#status.204" class="smpl">204 (No Content)</a> status code if the action has been enacted and no further information is to be supplied, or a <a href="#status.200" class="smpl">200 (OK)</a> status code if the action has been enacted and the response message includes a representation describing the status.
    1516       </p>
    1517       <p id="rfc.section.4.3.5.p.4">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause
     1519      <p id="rfc.section.4.3.5.p.4">If a DELETE method is successfully applied, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.202" class="smpl">202 (Accepted)</a> status code if the action seems okay but has not yet been enacted, a <a href="#status.204" class="smpl">204 (No Content)</a> status code if the action has been enacted and no further information is to be supplied, or a <a href="#status.200" class="smpl">200 (OK)</a> status code if the action has been enacted and the response message includes a representation describing the status.
     1520      </p>
     1521      <p id="rfc.section.4.3.5.p.5">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause
    15181522         some existing implementations to reject the request.
    15191523      </p>
    1520       <p id="rfc.section.4.3.5.p.5">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
     1524      <p id="rfc.section.4.3.5.p.6">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
    15211525         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.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    15221526      </p>

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

    r2102 r2103  
    14901490<t>
    14911491   The DELETE method requests that the origin server remove the association
    1492    between the <x:ref>target resource</x:ref> and its current representations or
    1493    implementation. In effect, this method is similar to the rm command in
    1494    UNIX: it expresses a deletion operation on the URI mapping of the
    1495    origin server, rather than an expectation that the information be deleted.
    1496    The representations might or might not be destroyed by the origin server,
    1497    and the associated storage might or might not be reclaimed, depending
    1498    entirely on the nature of the resource and its implementation by the
    1499    origin server (which are beyond the scope of this specification).
     1492   between the <x:ref>target resource</x:ref> and its current functionality.
     1493   In effect, this method is similar to the rm command in UNIX: it expresses a
     1494   deletion operation on the URI mapping of the origin server, rather than an
     1495   expectation that the previously associated information be deleted.
     1496</t>
     1497<t>
     1498   If the target resource has one or more current representations, they might
     1499   or might not be destroyed by the origin server, and the associated storage
     1500   might or might not be reclaimed, depending entirely on the nature of the
     1501   resource and its implementation by the origin server (which are beyond the
     1502   scope of this specification). Likewise, other implementation aspects of a
     1503   resource might need to be deactivated or archived as a result of a DELETE,
     1504   such as database or gateway connections. In general, it is assumed that the
     1505   origin server will only allow DELETE on resources for which it has a
     1506   prescribed mechanism for accomplishing the deletion.
    15001507</t>
    15011508<t>
Note: See TracChangeset for help on using the changeset viewer.