Changeset 2347
- Timestamp:
- 06/08/13 12:49:31 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r2344 r2347 263 263 <x:anchor-alias value="target resource"/> 264 264 <t> 265 The target of eachHTTP request is called a resource.265 The target of a HTTP request is called a resource. 266 266 HTTP does not limit the nature of a resource; it merely 267 267 defines an interface that might be used to interact with resources. … … 333 333 </t> 334 334 <t> 335 The following header fields are defined toconvey representation metadata:335 The following header fields convey representation metadata: 336 336 </t> 337 337 <texttable align="left"> … … 345 345 </texttable> 346 346 347 <section title="Processing theData" anchor="data.type">347 <section title="Processing Representation Data" anchor="data.type"> 348 348 349 349 <section title="Media Type" anchor="media.type"> … … 543 543 transformed without losing the identity of its underlying media type 544 544 and without loss of information. Frequently, the representation is stored 545 in coded form, transmitted directly, and only decoded by the recipient.545 in coded form, transmitted directly, and only decoded by the final recipient. 546 546 </t> 547 547 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/> … … 729 729 resource identified by the Content-Location field-value. However, 730 730 such an assertion cannot be trusted unless it can be verified by 731 other means (not defined by HTTP). The information might still be731 other means (not defined by this document). The information might still be 732 732 useful for revision history links.</t> 733 733 <t>Otherwise, the payload is unidentified.</t> … … 758 758 representation of the resource identified by the Content-Location 759 759 field-value. However, such an assertion cannot be trusted unless 760 it can be verified by other means (not defined by HTTP).</t>760 it can be verified by other means (not defined by this document).</t> 761 761 <t>Otherwise, the payload is unidentified.</t> 762 762 </list> … … 950 950 </t> 951 951 <t> 952 Note that, in all cases, the supplier of representations to the origin 953 server determines which representations might be considered to be the 954 "same information". 952 Note that, in all cases, the resource determines which representations might 953 be considered to be the "same information". 955 954 </t> 956 955 … … 960 959 <t> 961 960 When content negotiation preferences are sent by the user agent in a 962 request in orderto encourage an algorithm located at the server to961 request to encourage an algorithm located at the server to 963 962 select the preferred representation, it is called 964 963 <x:dfn>proactive negotiation</x:dfn> … … 1047 1046 </t> 1048 1047 <t> 1048 Reactive negotiation can also be supported in successful responses (e.g., 1049 <x:ref>200 (OK)</x:ref> responses) if the payload format allows it. 1050 </t> 1051 <t> 1049 1052 Reactive negotiation is advantageous when the response would vary 1050 1053 over commonly-used dimensions (such as type, language, or encoding), … … 1076 1079 fields when present in a request (<xref target="request.header.fields"/>) 1077 1080 if those additional semantics do not conflict with the method. 1081 </t> 1082 <t> 1083 For example, a client can send conditional request header fields 1084 (<xref target="request.conditionals"/>) to make the requested 1085 action conditional on the current state of the target resource 1086 (<xref target="Part4"/>). 1078 1087 </t> 1079 1088 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="method"/> … … 1154 1163 with the <x:ref>405 (Method Not Allowed)</x:ref> status code. 1155 1164 </t> 1156 <t>1157 A client can send conditional request header fields1158 (<xref target="request.conditionals"/>) to make the requested1159 action conditional on the current state of the target resource1160 (<xref target="Part4"/>).1161 </t>1162 1165 </section> 1163 1166 … … 1570 1573 <t> 1571 1574 If a DELETE method is successfully applied, the origin server &SHOULD; send 1572 a <x:ref>202 (Accepted)</x:ref> status code if the action seems okaybut1575 a <x:ref>202 (Accepted)</x:ref> status code if the action will likely succeed but 1573 1576 has not yet been enacted, 1574 1577 a <x:ref>204 (No Content)</x:ref> status code if the action has been … … 1677 1680 <iref primary="true" item="OPTIONS method" x:for-anchor=""/> 1678 1681 <t> 1679 The OPTIONS method requests information about the 1680 communication options available on the request/response chain1681 i dentified by the effective request URI. This method allows a client to1682 determine the options and/or requirements associated with a resource,1683 o r the capabilities of a server, without implying a resource action.1682 The OPTIONS method requests information about the communication options 1683 available for the target resource, either at the origin server or an 1684 intervening intermediary. This method allows a client to determine the 1685 options and/or requirements associated with a resource, or the capabilities 1686 of a server, without implying a resource action. 1684 1687 </t> 1685 1688 <t> … … 3393 3396 <t> 3394 3397 The <x:dfn>409 (Conflict)</x:dfn> status code indicates that the request 3395 could not be completed due to a conflict with the current state of the 3398 could not be completed due to a conflict with the current state of the target 3396 3399 resource. This code is used in situations where the user might be able to 3397 3400 resolve the conflict and resubmit the request. The server &SHOULD; generate
Note: See TracChangeset
for help on using the changeset viewer.