Changeset 2352
- Timestamp:
- 10/08/13 23:06:56 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2351 r2352 827 827 </p> 828 828 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="resources" href="#resources">Resources</a></h1> 829 <p id="rfc.section.2.p.1">The target of a HTTP request is called a resource. HTTP does not limit the nature of a resource; it merely defines an interface829 <p id="rfc.section.2.p.1">The target of an HTTP request is called a resource. HTTP does not limit the nature of a resource; it merely defines an interface 830 830 that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described 831 831 in <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. … … 1073 1073 <ul> 1074 1074 <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location 1075 field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this document).1075 field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this specification). 1076 1076 The information might still be useful for revision history links. 1077 1077 </li> … … 1089 1089 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts 1090 1090 that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion 1091 cannot be trusted unless it can be verified by other means (not defined by this document).1091 cannot be trusted unless it can be verified by other means (not defined by this specification). 1092 1092 </li> 1093 1093 <li>Otherwise, the payload is unidentified.</li> … … 1202 1202 in applicability and practicality. 1203 1203 </p> 1204 <p id="rfc.section.3.4.p.3">Note that, in all cases, the resource determines which representations might be considered to be the "same information".</p> 1204 <p id="rfc.section.3.4.p.3">Note that, in all cases, HTTP is not aware of the resource semantics. The consistency with which an origin server responds 1205 to requests, over time and over the varying dimensions of content negotiation, and thus the "sameness" of a resource's observed 1206 representations over time, is determined entirely by whatever entity or algorithm selects or generates those responses. HTTP 1207 pays no attention to the man behind the curtain. 1208 </p> 1205 1209 <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a> <a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3> 1206 1210 <p id="rfc.section.3.4.1.p.1">When content negotiation preferences are sent by the user agent in a request to encourage an algorithm located at the server … … 1235 1239 </p> 1236 1240 <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a> <a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3> 1237 <p id="rfc.section.3.4.2.p.1">With <dfn>reactive negotiation</dfn> (a.k.a., <dfn>agent-driven negotiation</dfn>), selection of the best representation for a response is performed by the user agent after receiving an initial response 1238 from the origin server with a list of alternative resources. If the user agent is not satisfied by the initial response, it 1239 can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to 1240 obtain a different form of representation. Selection of alternatives might be performed automatically by the user agent or 1241 manually by the user selecting from a generated (possibly hypertext) menu. 1242 </p> 1243 <p id="rfc.section.3.4.2.p.2">A server can send a <a href="#status.300" class="smpl">300 (Multiple Choices)</a> response to indicate that reactive negotiation by the user agent is desired, or a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status code to indicate that proactive negotiation has failed. In both cases, the response ought to include information about 1244 the available representations so that the user or user agent can react by making a selection. 1245 </p> 1246 <p id="rfc.section.3.4.2.p.3">Reactive negotiation can also be supported in successful responses (e.g., <a href="#status.200" class="smpl">200 (OK)</a> responses) if the payload format allows it. 1241 <p id="rfc.section.3.4.2.p.1">With <dfn>reactive negotiation</dfn> (a.k.a., <dfn>agent-driven negotiation</dfn>), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving 1242 an initial response from the origin server that contains a list of resources for alternative representations. If the user 1243 agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative 1244 resources, selected based on metadata included in the list, to obtain a different form of representation for that response. 1245 Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated 1246 (possibly hypertext) menu. 1247 </p> 1248 <p id="rfc.section.3.4.2.p.2">Note that the above refers to representations of the response, in general, not representations of the resource. The alternative 1249 representations are only considered representations of the target resource if the response in which those alternatives are 1250 provided has the semantics of being a representation of the target resource (e.g., a <a href="#status.200" class="smpl">200 (OK)</a> response to a GET request) or has the semantics of providing links to alternative representations for the target resource 1251 (e.g., a <a href="#status.300" class="smpl">300 (Multiple Choices)</a> response to a GET request). 1252 </p> 1253 <p id="rfc.section.3.4.2.p.3">A server might choose not to send an initial representation, other than than the list of alternatives, and thereby indicate 1254 that reactive negotiation by the user agent is preferred. For example, the alternatives listed in responses with the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes include information about the available representations so that the user or user agent can react by making a 1255 selection. 1247 1256 </p> 1248 1257 <p id="rfc.section.3.4.2.p.4">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or … … 1258 1267 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="method.overview" href="#method.overview">Overview</a></h2> 1259 1268 <p id="rfc.section.4.1.p.1">The request method token is the primary source of request semantics; it indicates the purpose for which the client has made 1260 this request and what is expected by the client as a successful result. The request semantics might be further specialized 1261 by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section 5</a>) if those additional semantics do not conflict with the method. 1262 </p> 1263 <p id="rfc.section.4.1.p.2">For example, a client can send conditional request header fields (<a href="#request.conditionals" title="Conditionals">Section 5.2</a>) to make the requested action conditional on the current state of the target resource (<a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). 1269 this request and what is expected by the client as a successful result. 1270 </p> 1271 <p id="rfc.section.4.1.p.2">The request method's semantics might be further specialized by the semantics of some header fields when present in a request 1272 (<a href="#request.header.fields" title="Request Header Fields">Section 5</a>) if those additional semantics do not conflict with the method. For example, a client can send conditional request header 1273 fields (<a href="#request.conditionals" title="Conditionals">Section 5.2</a>) to make the requested action conditional on the current state of the target resource (<a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). 1264 1274 </p> 1265 1275 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#method.overview" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2351 r2352 263 263 <x:anchor-alias value="target resource"/> 264 264 <t> 265 The target of a HTTP request is called a resource.265 The target of an 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. … … 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 this document). The information might still be732 useful for revision history links.</t>731 other means (not defined by this specification). The information 732 might still be useful for revision history links.</t> 733 733 <t>Otherwise, the payload is unidentified.</t> 734 734 </list> … … 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 this document).</t>760 it can be verified by other means (not defined by this specification).</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 resource determines which representations might 953 be considered to be the "same information". 952 Note that, in all cases, HTTP is not aware of the resource semantics. 953 The consistency with which an origin server responds to requests, over time 954 and over the varying dimensions of content negotiation, and thus the 955 "sameness" of a resource's observed representations over time, is 956 determined entirely by whatever entity or algorithm selects or generates 957 those responses. HTTP pays no attention to the man behind the curtain. 954 958 </t> 955 959 … … 1028 1032 With <x:dfn>reactive negotiation</x:dfn> 1029 1033 (a.k.a., <x:dfn>agent-driven negotiation</x:dfn>), selection of the best 1030 representation for a response is performed by the user agent after 1031 receiving an initial response from the origin server with a list of 1032 alternative resources. If the user agent is not satisfied by the initial 1033 response, it can perform a GET request on one or more of the alternative 1034 resources, selected based on metadata included in the list, to obtain a 1035 different form of representation. Selection of alternatives might be 1034 response representation (regardless of the status code) is performed by the 1035 user agent after receiving an initial response from the origin server that 1036 contains a list of resources for alternative representations. 1037 If the user agent is not satisfied by the initial response representation, 1038 it can perform a GET request on one or more of the alternative resources, 1039 selected based on metadata included in the list, to obtain a different form 1040 of representation for that response. Selection of alternatives might be 1036 1041 performed automatically by the user agent or manually by the user selecting 1037 1042 from a generated (possibly hypertext) menu. 1038 1043 </t> 1039 1044 <t> 1040 A server can send a <x:ref>300 (Multiple Choices)</x:ref> response to 1041 indicate that reactive negotiation by the user agent is desired, or a 1042 <x:ref>406 (Not Acceptable)</x:ref> status code to indicate that proactive 1043 negotiation has failed. In both cases, the response ought to include 1044 information about the available representations so that the user or 1045 user agent can react by making a selection. 1046 </t> 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. 1045 Note that the above refers to representations of the response, in general, 1046 not representations of the resource. The alternative representations are 1047 only considered representations of the target resource if the response in 1048 which those alternatives are provided has the semantics of being a 1049 representation of the target resource (e.g., a <x:ref>200 (OK)</x:ref> 1050 response to a GET request) or has the semantics of providing links to 1051 alternative representations for the target resource 1052 (e.g., a <x:ref>300 (Multiple Choices)</x:ref> response to a GET request). 1053 </t> 1054 <t> 1055 A server might choose not to send an initial representation, other than 1056 than the list of alternatives, and thereby indicate that reactive 1057 negotiation by the user agent is preferred. For example, the alternatives 1058 listed in responses with the <x:ref>300 (Multiple Choices)</x:ref> and 1059 <x:ref>406 (Not Acceptable)</x:ref> status codes include information about 1060 the available representations so that the user or user agent can react by 1061 making a selection. 1050 1062 </t> 1051 1063 <t> … … 1075 1087 The request method token is the primary source of request semantics; 1076 1088 it indicates the purpose for which the client has made this request 1077 and what is expected by the client as a successful result. The request 1078 semantics might be further specialized by the semantics of some header 1079 fields when present in a request (<xref target="request.header.fields"/>) 1080 if those additional semantics do not conflict with the method. 1081 </t> 1082 <t> 1089 and what is expected by the client as a successful result. 1090 </t> 1091 <t> 1092 The request method's semantics might be further specialized by the 1093 semantics of some header fields when present in a request 1094 (<xref target="request.header.fields"/>) if those additional semantics do 1095 not conflict with the method. 1083 1096 For example, a client can send conditional request header fields 1084 1097 (<xref target="request.conditionals"/>) to make the requested
Note: See TracChangeset
for help on using the changeset viewer.