Ignore:
Timestamp:
10/08/13 23:06:56 (8 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.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.