Changeset 2395
- Timestamp:
- 14/09/13 19:57:05 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2393 r2395 1460 1460 </p> 1461 1461 <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 sentto 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. 1463 1463 </p> 1464 1464 <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. 1506 1506 </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 same1509 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new1510 version resource in addition to changing the state of the target resource, and might also cause links to be added between1511 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 full1514 representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps1515 a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for1516 example, the PATCH method definedin <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 responses1519 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>). 1520 1520 </p> 1521 1521 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2393 r2395 1433 1433 target resource does have a current representation and that representation is 1434 1434 successfully modified in accordance with the state of the enclosed 1435 representation, then either a <x:ref>200 (OK)</x:ref> or <x:ref>204 (No Content)</x:ref> 1436 response &SHOULD; be sent to indicate successful completion of the request. 1435 representation, then the origin server &MUST; send either a 1436 <x:ref>200 (OK)</x:ref> or a <x:ref>204 (No Content)</x:ref> response to 1437 indicate successful completion of the request. 1437 1438 </t> 1438 1439 <t> … … 1519 1520 </t> 1520 1521 <t> 1521 A PUT request applied to the target resource &MAY;have side-effects1522 A PUT request applied to the target resource can have side-effects 1522 1523 on other resources. For example, an article might have a URI for 1523 1524 identifying "the current version" (a resource) that is separate … … 1530 1531 </t> 1531 1532 <t> 1532 An origin server &SHOULD; reject any PUT request that contains a 1533 An origin server that allows PUT on a given target resource &MUST; send a 1534 <x:ref>400 (Bad Request)</x:ref> response to a PUT request that contains a 1533 1535 <x:ref>Content-Range</x:ref> header field (&header-content-range;), since 1534 it might be misinterpreted as partial content (or might be partial content1535 that is being mistakenly PUT as a full representation). Partial content1536 updates are possible by targeting a separately identified resource with1537 state that overlaps a portion of the larger resource, or by using a1538 different method that has been specifically defined for partial1536 the payload is likely to be partial content that has been mistakenly PUT as 1537 a full representation. 1538 Partial content updates are possible by targeting a separately identified 1539 resource with state that overlaps a portion of the larger resource, or by 1540 using a different method that has been specifically defined for partial 1539 1541 updates (for example, the PATCH method defined in 1540 1542 <xref target="RFC5789"/>). 1541 1543 </t> 1542 1544 <t> 1543 Responses to the PUT method are not cacheable. If a PUT request passes1544 through a cache that has one or more stored responses for the effective1545 request URI, those stored responses will be invalidated (see1546 &p6-invalid;).1545 Responses to the PUT method are not cacheable. If a successful PUT request 1546 passes through a cache that has one or more stored responses for the 1547 effective request URI, those stored responses will be invalidated 1548 (see &p6-invalid;). 1547 1549 </t> 1548 1550 </section>
Note: See TracChangeset
for help on using the changeset viewer.