Best variant




 
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:



















 
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