Ticket #81: i81.diff

File i81.diff, 6.7 KB (added by julian.reschke@…, 11 years ago)

proposed path for part 3

  • p3-payload.xml

     
    806806
    807807<section title="Content Negotiation" anchor="content.negotiation">
    808808<t>
    809    Most HTTP responses include an entity which contains information for
    810    interpretation by a human user. Naturally, it is desirable to supply
    811    the user with the "best available" entity corresponding to the
    812    request. Unfortunately for servers and caches, not all users have the
    813    same preferences for what is "best," and not all user agents are
    814    equally capable of rendering all entity types. For that reason, HTTP
    815    has provisions for several mechanisms for "content negotiation" --
    816    the process of selecting the best representation for a given response
    817    when there are multiple representations available.
     809   HTTP responses include a representation which contains information for
     810   interpretation, whether by a human user or for further processing.
     811   Often, the server has different ways of representing the
     812   same information; for example, in different formats, languages,
     813   or using different character encodings.
    818814</t>
    819 <x:note>
    820   <t>
    821     <x:h>Note:</x:h> This is not called "format negotiation" because the
    822     alternate representations may be of the same media type, but use
    823     different capabilities of that type, be in different languages,
    824     etc.
    825   </t>
    826 </x:note>
    827815<t>
    828    Any response containing an entity-body &MAY; be subject to negotiation,
    829    including error responses.
     816   HTTP clients and their users might have different or variable
     817   capabilities, characteristics or preferences which would influence
     818   which representation, among those available from the server,
     819   would be best for the server to deliver. For this reason, HTTP
     820   provides mechanisms for "content negotiation" -- a process of
     821   allowing selection of a representation of a given resource,
     822   when more than one is available.
    830823</t>
    831824<t>
    832    There are two kinds of content negotiation which are possible in
    833    HTTP: server-driven and agent-driven negotiation. These two kinds of
    834    negotiation are orthogonal and thus may be used separately or in
    835    combination. One method of combination, referred to as transparent
    836    negotiation, occurs when a cache uses the agent-driven negotiation
    837    information provided by the origin server in order to provide
    838    server-driven negotiation for subsequent requests.
     825   This specification defines two patterns of content negotiation;
     826   "server-driven", where the server selects the representation based
     827   upon the client's stated preferences, and "agent-driven" negotiation,
     828   where the server provides a list of representations for the client to
     829   choose from, based upon their metadata. In addition,  there are
     830   other patterns: some applications use an "active content" pattern,
     831   where the server returns active content which runs on the client
     832   and, based on client available parameters, selects additional
     833   resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>)
     834   has also been proposed.
    839835</t>
     836<t>
     837   These patterns are all widely used, and have trade-offs in applicability
     838   and practicality. In particular, when the number of preferences or
     839   capabilities to be expressed by a client are large (such as when many
     840   different formats are supported by a user-agent), server-driven
     841   negotiation becomes unwieldy, and may not be appropriate. Conversely,
     842   when the number of representations to choose from is very large,
     843   agent-driven negotiation may not be appropriate.
     844</t>
     845<t>
     846   Note that caches can be instructed on how to manage server-negotiated
     847   responses using the Vary header (&header-vary;), although this mechanism is not
     848   richly descriptive.
     849</t>
     850<t>
     851   The headers "Accept:", "Accept-Language:" and "Accept-charset:"
     852   are defined explicitly for content negotiation. In addition,
     853   many systems employ "User-Agent" based negotiation, where different
     854   content is delivered depending on the version of software employed.
     855   In practice, User-Agent based negotiation is fragile, because new
     856   clients are not recognized by the deployed servers or active content.
     857</t>
     858<t>
     859   Note that in all cases, the supplier of representations has the
     860   responsibility for determining which representations might be
     861   considered to be the "same information".
     862</t>
    840863
    841864<section title="Server-driven Negotiation" anchor="server-driven.negotiation">
    842865<t>
     
    938961   negotiation.
    939962</t>
    940963</section>
    941 
    942 <section title="Transparent Negotiation" anchor="transparent.negotiation">
    943 <t>
    944    Transparent negotiation is a combination of both server-driven and
    945    agent-driven negotiation. When a cache is supplied with a form of the
    946    list of available representations of the response (as in agent-driven
    947    negotiation) and the dimensions of variance are completely understood
    948    by the cache, then the cache becomes capable of performing server-driven
    949    negotiation on behalf of the origin server for subsequent
    950    requests on that resource.
    951 </t>
    952 <t>
    953    Transparent negotiation has the advantage of distributing the
    954    negotiation work that would otherwise be required of the origin
    955    server and also removing the second request delay of agent-driven
    956    negotiation when the cache is able to correctly guess the right
    957    response.
    958 </t>
    959 <t>
    960    This specification does not define any mechanism for transparent
    961    negotiation, though it also does not prevent any such mechanism from
    962    being developed as an extension that could be used within HTTP/1.1.
    963 </t>
    964964</section>
    965 </section>
    966965
    967966<section title="Header Field Definitions" anchor="header.fields">
    968967<t>
     
    22822281  <seriesInfo name="RFC" value="2277"/>
    22832282</reference>
    22842283
     2284<reference anchor='RFC2295'>
     2285  <front>
     2286    <title abbrev='HTTP Content Negotiation'>Transparent Content Negotiation in HTTP</title>
     2287    <author initials='K.' surname='Holtman' fullname='Koen Holtman'>
     2288      <organization>Technische Universiteit Eindhoven</organization>
     2289      <address>
     2290        <email>koen@win.tue.nl</email>
     2291      </address>
     2292    </author>
     2293    <author initials='A.H.' surname='Mutz' fullname='Andrew H. Mutz'>
     2294      <organization>Hewlett-Packard Company</organization>
     2295      <address>
     2296        <email>mutz@hpl.hp.com</email>
     2297      </address>
     2298    </author>
     2299    <date year='1998' month='March'/>
     2300  </front>
     2301  <seriesInfo name='RFC' value='2295'/>
     2302</reference>
     2303
    22852304<reference anchor="RFC2388">
    22862305  <front>
    22872306    <title abbrev="multipart/form-data">Returning Values from Forms:  multipart/form-data</title>