Ignore:
Timestamp:
19/01/14 03:22:35 (6 years ago)
Author:
fielding@…
Message:

(editorial) explain why 300 does not have a defined format and describe how it is typically implemented in practice; addresses #548

File:
1 edited

Legend:

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

    r2561 r2562  
    27312731               </p>
    27322732               <p id="rfc.section.6.4.1.p.3">For request methods other than HEAD, the server <em class="bcp14">SHOULD</em> generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user
    2733                   or user agent can choose the one most preferred. The user agent <em class="bcp14">MAY</em> make a selection from that list automatically, depending upon the list format, but this specification does not define a standard
    2734                   for such automatic selection.
     2733                  or user agent can choose the one most preferred. The user agent <em class="bcp14">MAY</em> make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection
     2734                  is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice,
     2735                  the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by
     2736                  shared design or content negotiation, or in some commonly accepted hypertext format.
    27352737               </p>
    27362738               <p id="rfc.section.6.4.1.p.4">A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls
Note: See TracChangeset for help on using the changeset viewer.