rfc2295.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,711 行 · 第 1/5 页

     A machine-readable description of a variant resource, usually found
     in a variant list.  A variant description contains the variant
     resource URI and various attributes which describe properties of
     the variant.  Variant descriptions are defined in section 5.

   variant resource
     A resource from which a variant of a negotiable resource can be
     retrieved with a normal HTTP/1.x GET request, i.e. a GET request
     which does not use transparent content negotiation.

   neighboring variant
     A variant resource is called a neighboring variant resource of some
     transparently negotiable HTTP resource if the variant resource has
     a HTTP URL, and if the absolute URL of the variant resource up to
     its last slash equals the absolute URL of the negotiable resource
     up to its last slash, where equality is determined with the URI
     comparison rules in section 3.2.3 of [1].  The property of being a
     neighboring variant is important because of security considerations
     (section 14.2).  Not all variants of a negotiable resource need to
     be neighboring variants.  However, access to neighboring variants
     can be more highly optimized by the use of remote variant selection
     algorithms (section 7) and choice responses (section 10.2).

   remote variant selection algorithm
     A standardized algorithm by which a server can sometimes choose a
     best variant on behalf of a negotiating user agent.  The algorithm
     typically computes whether the Accept- headers in the request
     contain sufficient information to allow a choice, and if so, which
     variant is the best variant.  The use of a remote algorithm can
     speed up the negotiation process.

   list response
     A list response returns the variant list of the negotiable
     resource, but no variant data.  It can be generated when the server
     does not want to, or is not allowed to, return a particular best
     variant for the request.  List responses are defined in section
     10.1.

   choice response
     A choice response returns a representation of the best variant for
     the request, and may also return the variant list of the negotiable
     resource.  It can be generated when the server has sufficient
     information to be able to choose the best variant on behalf the
     user agent, but may only be generated if this best variant is a
     neighboring variant.  Choice responses are defined in section 10.2.





Holtman & Mutz                Experimental                      [Page 7]

RFC 2295            Transparent Content Negotiation           March 1998


   adhoc response
     An adhoc response can be sent by an origin server as an extreme
     measure, to achieve compatibility with a non-negotiating or buggy
     client if this compatibility cannot be achieved by sending a list
     or choice response.  There are very little requirements on the
     contents of an adhoc response.  Adhoc responses are defined in
     section 10.3.

   Accept- headers
     The request headers: Accept, Accept-Charset, Accept-Language, and
     Accept-Features.

   supports transparent content negotiation
     From the viewpoint of an origin server or proxy, a user agent
     supports transparent content negotiation if and only if it sends a
     Negotiate header (section 8.4) which indicates such support.

   server-side override
     If a request on a transparently negotiated resource is made by a
     client which supports transparent content negotiation, an origin
     server is said to perform a server-side override if the server
     ignores the directives in the Negotiate request header, and instead
     uses a custom algorithm to choose an appropriate response.  A
     server-side override can sometimes be used to work around known
     client bugs.  It could also be used by protocol extensions on top
     of transparent content negotiation.

3  Notation

   The version of BNF used in this document is taken from [1], and many
   of the nonterminals used are defined in [1].  Note that the
   underlying charset is US-ASCII.

   One new BNF construct is added:

      1%rule

   stands for one or more instances of "rule", separated by whitespace:

      1%rule =  rule *( 1*LWS rule )

   This specification also introduces

      number = 1*DIGIT

      short-float = 1*3DIGIT [ "." 0*3DIGIT ]





Holtman & Mutz                Experimental                      [Page 8]

RFC 2295            Transparent Content Negotiation           March 1998


   This specification uses the same conventions as in [1] (see section
   1.2 of [1]) for defining the significance of each particular
   requirement.

4  Overview

   This section gives an overview of transparent content negotiation.
   It starts with a more general discussion of negotiation as provided
   by HTTP.

4.1 Content negotiation

   HTTP/1.1 allows web site authors to put multiple versions of the same
   information under a single resource URI.  Each of these versions is
   called a `variant'. For example, a resource http://x.org/paper could
   bind to three different variants of a paper:

         1. HTML, English
         2. HTML, French
         3. Postscript, English

   Content negotiation is the process by which the best variant is
   selected if the resource is accessed.  The selection is done by
   matching the properties of the available variants to the capabilities
   of the user agent and the preferences of the user.

   It has always been possible under HTTP to have multiple
   representations available for one resource, and to return the most
   appropriate representation for each subsequent request.  However,
   HTTP/1.1 is the first version of HTTP which has provisions for doing
   this in a cache-friendly way.  These provisions include the Vary
   response header, entity tags, and the If-None-Match request header.

4.2 HTTP/1.0 style negotiation scheme

   The HTTP/1.0 protocol elements allow for a negotiation scheme as
   follows:

      Server _____ proxy _____ proxy _____ user
      x.org        cache       cache       agent

        < ----------------------------------
        |      GET http://x.org/paper
        |          Accept- headers
      choose
        |
         ---------------------------------- >
                    Best variant



Holtman & Mutz                Experimental                      [Page 9]

RFC 2295            Transparent Content Negotiation           March 1998


   When the resource is accessed, the user agent sends (along with its
   request) various Accept- headers which express the user agent
   capabilities and the user preferences.  Then the origin server uses
   these Accept- headers to choose the best variant, which is returned
   in the response.

   The biggest problem with this scheme is that it does not scale well.
   For all but the most minimal user agents, Accept- headers expressing
   all capabilities and preferences would be very large, and sending
   them in every request would be hugely inefficient, in particular
   because only a small fraction of the resources on the web have
   multiple variants.

4.3 Transparent content negotiation scheme

   The transparent content negotiation scheme eliminates the need to
   send huge Accept- headers, and nevertheless allows for a selection
   process that always yields either the best variant, or an error
   message indicating that user agent is not capable of displaying any
   of the available variants.

   Under the transparent content negotiation scheme, the server sends a
   list with the available variants and their properties to the user
   agent.  An example of a list with three variants is

      {"paper.1" 0.9 {type text/html} {language en}},
      {"paper.2" 0.7 {type text/html} {language fr}},
      {"paper.3" 1.0 {type application/postscript} {language en}}

   The syntax and semantics of the variant descriptions in this list are
   covered in section 5.  When the list is received, the user agent can
   choose the best variant and retrieve it.  Graphically, the
   communication can be represented as follows:


















Holtman & Mutz                Experimental                     [Page 10]

RFC 2295            Transparent Content Negotiation           March 1998


      Server _____ proxy _____ proxy _____ user
      x.org        cache       cache       agent

        < ----------------------------------
        |      GET http://x.org/paper
        |
        ----------------------------------- >         [list response]
                  return of list            |
                                         choose
                                            |
        < ----------------------------------
        |  GET http://x.org/paper.1
        |
         ---------------------------------- >         [normal response]
                return of paper.1

   The first response returning the list of variants is called a `list
   response'.  The second response is a normal HTTP response: it does
   not contain special content negotiation related information.  Only
   the user agent needs to know that the second request actually
   retrieves a variant.  For the other parties in the communication, the
   second transaction is indistinguishable from a normal HTTP
   transaction.

   With this scheme, information about capabilities and preferences is
   only used by the user agent itself.  Therefore, sending such
   information in large Accept- headers is unnecessary.  Accept- headers
   do have a limited use in transparent content negotiation however; the
   sending of small Accept- headers can often speed up the negotiation
   process. This is covered in section 4.4.

   List responses are covered in section 10.1.  As an example, the list
   response in the above picture could be:

     HTTP/1.1 300 Multiple Choices
     Date: Tue, 11 Jun 1996 20:02:21 GMT
     TCN: list
     Alternates: {"paper.1" 0.9 {type text/html} {language en}},
                 {"paper.2" 0.7 {type text/html} {language fr}},
                 {"paper.3" 1.0 {type application/postscript}
                     {language en}}
     Vary: negotiate, accept, accept-language
     ETag: "blah;1234"
     Cache-control: max-age=86400
     Content-Type: text/html
     Content-Length: 227
     <h2>Multiple Choices:</h2>
     <ul>



Holtman & Mutz                Experimental                     [Page 11]

RFC 2295            Transparent Content Negotiation           March 1998


     <li><a href=paper.1>HTML, English version</a>
     <li><a href=paper.2>HTML, French version</a>
     <li><a href=paper.3>Postscript, English version</a>
     </ul>

   The Alternates header in the response contains the variant list.  The
   Vary header is included to ensure correct caching by plain HTTP/1.1
   caches (see section 10.6).  The ETag header allows the response to be
   revalidated by caches, the Cache-Control header controls this
   revalidation.  The HTML entity included in the response allows the
   user to select the best variant by hand if desired.

4.4 Optimizing the negotiation process

   The basic transparent negotiation scheme involves two HTTP
   transactions: one to retrieve the list, and a second one to retrieve
   the chosen variant.  There are however several ways to `cut corners'
   in the data flow path of the basic scheme.

   First, caching proxies can cache both variant lists and variants.
   Such caching can reduce the communication overhead, as shown in the
   following example:

      Server _____ proxy _____ proxy __________ user
      x.org        cache       cache            agent

                                 < --------------
                                 |  GET ../paper
                                 |
                               has the list
                               in cache
                                 |
                                  -------------  >  [list response]
                                           list  |
                                                 |
                                              choose
                                                 |
                     < --------------------------
                     |   GET ../paper.1
                     |
                  has the variant
                  in cache
                     |
                      -------------------------- >  [normal response]
                         return of paper.1






Holtman & Mutz                Experimental                     [Page 12]

RFC 2295            Transparent Content Negotiation           March 1998


   Second, the user agent can send small Accept- headers, which may
   contain enough information to allow the server to choose the best
   variant and return it directly.

      Server _____ proxy _____ proxy _____ user
      x.org        cache       cache       agent

        < ----------------------------------