Ignore:
Timestamp:
07/01/13 09:02:41 (8 years ago)
Author:
fielding@…
Message:

(editorial) move notes on 406 to 300 and include a reference to Link; miscellaneous proofreading edits

File:
1 edited

Legend:

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

    r2097 r2098  
    16541654   The response payload, if any, might also describe the communication options
    16551655   in a machine or human-readable representation. A standard format for such a
    1656    payload is not defined by this specification, but might be defined by
     1656   representation is not defined by this specification, but might be defined by
    16571657   future extensions to HTTP.
    16581658   A server &MUST; generate a <x:ref>Content-Length</x:ref> field with a value
     
    25162516   For example, if an unrecognized status code of 471 is received by a client,
    25172517   the client can assume that there was something wrong with its request and
    2518    treat the response as if it had received a 400 status code. If the response
    2519    includes a message body, it will usually include a representation that
    2520    explains the response status.
     2518   treat the response as if it had received a 400 status code. The response
     2519   message will usually contain a representation that explains the status.
    25212520</t>
    25222521<t>
     
    27002699<t>
    27012700   The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has
    2702    succeeded. The payload sent in the response
    2703    is dependent on the method used in the request, for example:
     2701   succeeded. The meaning of a payload sent in the response depends on the
     2702   request method, as follows:
    27042703  <list style="hanging">
    27052704    <t hangText="GET">
     
    27072706    </t>
    27082707    <t hangText="HEAD">
    2709       the same representation as GET, except without the message body;
     2708      the same representation as GET, but without the representation data;
    27102709    </t>
    27112710    <t hangText="POST">
     
    27542753   completed. The request might or might not eventually be acted upon, as it
    27552754   might be disallowed when processing actually takes place. There is no
    2756    facility for re-sending a status code from an asynchronous operation such
    2757    as this.
     2755   facility in HTTP for re-sending a status code from an asynchronous
     2756   operation.
    27582757</t>
    27592758<t>
     
    27632762   requiring that the user agent's connection to the server persist
    27642763   until the process is completed. The representation sent with this
    2765    response ought to describe the request's current status
    2766    and either a pointer to a status monitor or some estimate of when the
    2767    user can expect the request to be fulfilled.
     2764   response ought to describe the request's current status and point to
     2765   (or embed) a status monitor that can provide the user with an estimate of
     2766   when the request will be fulfilled.
    27682767</t>
    27692768</section>
     
    27962795   has successfully fulfilled the request and that there is no additional
    27972796   content to send in the response payload body. Metadata in the response
    2798    header fields refer to the <x:ref>target resource</x:ref> and its current representation
    2799    after the requested action.
     2797   header fields refer to the <x:ref>target resource</x:ref> and its
     2798   selected representation after the requested action was applied.
    28002799</t>
    28012800<t>
     
    28222821</t>
    28232822<t>
    2824    A 204 response does not include a message body, and thus is always
    2825    terminated by the first empty line after the header fields.
     2823   A 204 response is terminated by the first empty line after the header
     2824   fields because it cannot contain a message body.
    28262825</t>
    28272826</section>
     
    29412940<t>
    29422941   The <x:dfn>300 (Multiple Choices)</x:dfn> status code indicates that the
    2943    <x:ref>target resource</x:ref> has more than one representation, each with its own more
    2944    specific identifier, and information about the alternatives is being
    2945    provided so that the user (or user agent) can select a preferred
     2942   <x:ref>target resource</x:ref> has more than one representation, each with
     2943   its own more specific identifier, and information about the alternatives is
     2944   being provided so that the user (or user agent) can select a preferred
    29462945   representation by redirecting its request to one or more of those
    29472946   identifiers. In other words, the server desires that the user agent engage
    29482947   in reactive negotiation to select the most appropriate representation(s)
    29492948   for its needs (&content-negotiation;).
     2949</t>
     2950<t>
     2951   If the server has a preferred choice, the server &SHOULD; generate a
     2952   <x:ref>Location</x:ref> header field containing a preferred choice's URI
     2953   reference. The user agent &MAY; use the Location field value for automatic
     2954   redirection.
    29502955</t>
    29512956<t>
     
    29582963</t>
    29592964<t>
    2960    If the server has a preferred choice, the server &SHOULD; generate a
    2961    <x:ref>Location</x:ref> header field containing a preferred choice's URI
    2962    reference. The user agent &MAY; use the Location field value for automatic
    2963    redirection.
    2964 </t>
    2965 <t>
    29662965   Caches &MAY; use a heuristic (see &p6-heuristic;) to determine
    29672966   freshness for 300 responses.
    29682967</t>
    2969 
     2968<x:note>
     2969  <t>
     2970   &Note; The original proposal for 300 defined the URI header field as
     2971   providing a list of alternative representations, such that it would be
     2972   usable for 200, 300, and 406 responses and be transferred in responses to
     2973   the HEAD method. However, lack of deployment and disagreement over syntax
     2974   led to both URI and Alternates (a subsequent proposal) being dropped from
     2975   this specification. It is possible to communicate the list using a set of
     2976   Link header fields <xref target="RFC5988"/>, each with a relationship of
     2977   "alternate", though deployment is a chicken-and-egg problem.
     2978  </t>
     2979</x:note>
    29702980</section>
    29712981
     
    32213231   A user agent &MAY; automatically select the most appropriate choice from
    32223232   that list. However, this specification does not define any standard for
    3223    such automatic selection. [The original proposal for 406 defined the
    3224    Alternates header field as providing a list of alternative representations,
    3225    such that it would be available for responses to the HEAD method, but lack
    3226    of deployment led to Alternates being dropped from the specification.]
     3233   such automatic selection, as described in <xref target="status.300"/>.
    32273234</t>
    32283235</section>
     
    55165523</reference>
    55175524
     5525<reference anchor='RFC5988'>
     5526  <front>
     5527    <title>Web Linking</title>
     5528    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
     5529    <organization /></author>
     5530    <date year='2010' month='October' />
     5531  </front>
     5532  <seriesInfo name='RFC' value='5988' />
     5533</reference>
     5534
    55185535<reference anchor="RFC6265">
    55195536  <front>
Note: See TracChangeset for help on using the changeset viewer.