Servers SHOULD always be able to provide unencoded versions of every
   transparently negotiated response.  This means in particular that
   every variant in the variant list SHOULD at least be available in an
   unencoded form.

   Like HTTP/1.1, this specification allows proxies to encode or decode
   relayed or cached responses on the fly, unless explicitly forbidden
   by a Cache-Control directive.  The encoded or decoded response still
   contains the same variant as far as transparent content negotiation
   is concerned.  Note that HTTP/1.1 requires proxies to add a Warning
   header if the encoding of a response is changed.

11 User agent support for transparent negotiation

   This section specifies the requirements a user agent needs to satisfy
   in order to support transparent negotiation.  If the user agent
   contains an internal cache, this cache MUST conform to the rules for
   proxy caches in section 13.

11.1 Handling of responses

   If a list response is received when a resource is accessed, the user
   agent MUST be able to automatically choose, retrieve, and display the
   best variant, or display an error message if none of the variants are
   acceptable.

   If a choice response is received when a resource is accessed, the
   usual action is to automatically display the enclosed entity.
   However, if a remote variant selection algorithm which was enabled
   could have made a choice different from the choice the local
   algorithm would make, the user agent MAY apply its local algorithm to
   any variant list in the response, and automatically retrieve and
   display another variant if the local algorithm makes an other choice.

   When receiving a choice response, a user agent SHOULD check if
   variant resource is a neighboring variant resource of the negotiable
   resource.  If this is not the case, the user agent SHOULD reject the
   choice response as a probable spoofing attempt and display an error
   message, for example by internally replacing the choice response with
   a 502 (bad gateway) response.

11.2 Presentation of a transparently negotiated resource

   If the user agent is displaying a variant which is not an embedded or
   inlined object and which is the result of transparent content
   negotiation, the following requirements apply.






 
RFC 2295            Transparent Content Negotiation           March 1998


    1. The user agent SHOULD allow the user to review a list of all
       variants bound to the negotiable resource, and to manually
       retrieve another variant if desired.  There are two general ways
       of providing such a list.  First, the information in the
       Alternates header of the negotiable resource could be used to
       make an annotated menu of variants.  Second, the entity included
       in a list response of the negotiable resource could be displayed.
       Note that a list response can be obtained by doing a GET request
       which only has the "trans" directive in the Negotiate header.

    2. The user agent SHOULD make available though its user interface
       some indication that the resource being displayed is a negotiated
       resource instead of a plain resource.  It SHOULD also allow the
       user to examine the variant list included in the Alternates
       header.  Such a notification and review mechanism is needed
       because of privacy considerations, see section 14.1.

    3. If the user agent shows the URI of the displayed information to
       the user, it SHOULD be the negotiable resource URI, not the
       variant URI that is shown.  This encourages third parties, who
       want to refer to the displayed information in their own
       documents, to make a hyperlink to the negotiable resource as a
       whole, rather than to the variant resource which happens to be
       shown.  Such correct linking is vital for the interoperability of
       content across sites.  The user agent SHOULD however also provide
       a means for reviewing the URI of the particular variant which is
       currently being displayed.

    4. Similarly, if the user agent stores a reference to the
       displayed information for future use, for example in a hotlist,
       it SHOULD store the negotiable resource URI, not the variant URI.

   It is encouraged, but not required, that some of the above
   functionality is also made available for inlined or embedded objects,
   and when a variant which was selected manually is being displayed.

12 Origin server support for transparent negotiation

12.1 Requirements

   To implement transparent negotiation on a resource, the origin server
   MUST be able to send a list response when getting a GET request on
   the resource.  It SHOULD also be able to send appropriate list
   responses for HEAD requests.  When getting a request on a