Changeset 2352


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

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

Location:
draft-ietf-httpbis/latest
Files:
2 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>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2351 r2352  
    263263  <x:anchor-alias value="target resource"/>
    264264<t>
    265    The target of a HTTP request is called a resource.
     265   The target of an HTTP request is called a resource.
    266266   HTTP does not limit the nature of a resource; it merely
    267267   defines an interface that might be used to interact with resources.
    … …  
    729729         resource identified by the Content-Location field-value. However,
    730730         such an assertion cannot be trusted unless it can be verified by
    731          other means (not defined by this document). The information might still be
    732          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>
    733733      <t>Otherwise, the payload is unidentified.</t>
    734734   </list>
    … …  
    758758         representation of the resource identified by the Content-Location
    759759         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>
    761761      <t>Otherwise, the payload is unidentified.</t>
    762762   </list>
    … …  
    950950</t>
    951951<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.
    954958</t>
    955959
    … …  
    10281032   With <x:dfn>reactive negotiation</x:dfn>
    10291033   (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
    10361041   performed automatically by the user agent or manually by the user selecting
    10371042   from a generated (possibly hypertext) menu.
    10381043</t>
    10391044<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.
    10501062</t>
    10511063<t>
    … …  
    10751087   The request method token is the primary source of request semantics;
    10761088   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.
    10831096   For example, a client can send conditional request header fields
    10841097   (<xref target="request.conditionals"/>) to make the requested
Note: See TracChangeset for help on using the changeset viewer.