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
     Multiple Choices:
     




 
RFC 2295            Transparent Content Negotiation           March 1998


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

   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







 
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

        < ----------------------------------
        |      GET http://x.org/paper
        |       small Accept- headers
        |
      able to choose on
      behalf of user agent
        |
         ---------------------------------- >    [choice response]
              return of paper.1 and list

   This choosing based on small Accept- headers is done with a `remote
   variant selection algorithm'.  Such an algorithm takes the variant
   list and the Accept- headers as input.  It then computes whether the
   Accept- headers contain sufficient information to choose on behalf of
   the user agent, and if so, which variant is the best variant.  If the
   best variant is a neighboring variant, it may be returned, together