Ignore:
Timestamp:
10/08/13 23:06:56 (7 years ago)
Author:
fielding@…
Message:

(editorial) tweaks on the changes from [2347]; addresses #450

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2351 r2352  
    827827      </p>
    828828      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<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 interface
     829      <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
    830830         that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described
    831831         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>.
     
    10731073      <ul>
    10741074         <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).
    10761076            The information might still be useful for revision history links.
    10771077         </li>
     
    10891089         <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
    10901090            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).
    10921092         </li>
    10931093         <li>Otherwise, the payload is unidentified.</li>
     
    12021202         in applicability and practicality.
    12031203      </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>
    12051209      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
    12061210      <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
     
    12351239      </p>
    12361240      <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;<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.
    12471256      </p>
    12481257      <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
     
    12581267      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="method.overview" href="#method.overview">Overview</a></h2>
    12591268      <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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>).
    12641274      </p>
    12651275      <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.