After having constructed a list, choice, or adhoc response, a server
   MAY process any If-No-Match or If-Range headers in the request
   message and shorten the response to a 304 (Not Modified) or 206
   (Partial Content) response, following the rules in the HTTP/1.1
   specification [1].  In this case, the entity tag of the shortened
   response will identify it indirectly as a list, choice, or adhoc
   response.

10.1 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.  If the user agent supports transparent content
   negotiation, the list response will cause it to select a best variant
   and retrieve it.

   A list response MUST contain (besides the normal headers required by
   HTTP) a TCN header which specifies the "list" response-type, the
   Alternates header bound to the negotiable resource, a Vary header and
   (unless it was a HEAD request) an entity body which allows the user
   to manually select the best variant.

   An example of a list response is

     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

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




 
RFC 2295            Transparent Content Negotiation           March 1998


      Note: A list response can have any status code, but the 300
      (Multiple Choices) code is the most appropriate one for HTTP/1.1
      clients.  Some existing versions of HTTP/1.0 clients are known to
      silently ignore 300 responses, instead of handling them according
      to the HTTP/1.0 specification [2].  Servers should therefore be
      careful in sending 300 responses to non-negotiating HTTP/1.0 user
      agents, and in making these responses cacheable.  The 200 (OK)
      status code can be used instead.

   The Vary header in the response SHOULD ensure correct handling by
   plain HTTP/1.1 caching proxies.  This header can either be

      Vary: *

   or a more elaborate header; see section 10.6.1.

   Only the origin server may construct list responses.  Depending on
   the status code, a list response is cacheable unless indicated
   otherwise.

   According to the HTTP/1.1 specification [1], a user agent which does
   not support transparent content negotiation will, when receiving a
   list response with the 300 status code, display the entity body
   included in the response.  If the response contains a Location
   header, however, the user agent MAY automatically redirect to this
   location.

   The handling of list responses by clients supporting transparent
   content negotiation is described in sections 11.1 and 13.

10.2 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.  For request from user agents which do not
   support transparent content negotiation, a server may always generate
   a choice response, provided that the variant returned is a
   neighboring variant.  The variant returned in a choice response need
   not necessarily be listed in the variant list bound to the negotiable
   resource.