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 ]






 
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
        |
         ---------------------------------- >