Changeset 2352 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 10/08/13 23:06:56 (9 years ago)
- File:
-
- 1 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>
Note: See TracChangeset
for help on using the changeset viewer.