RFC 2295            Transparent Content Negotiation           March 1998


   A choice response merges a normal HTTP response from the chosen
   variant, a TCN header which specifies the "choice" response-type, and
   a Content-Location header giving the location of the variant.
   Depending on the status code, a choice response is cacheable unless
   indicated otherwise.

   Origin servers and proxy caches MUST construct choice responses with
   the following algorithm (or any other algorithm which gives equal end
   results for the client).

   In this algorithm, `the current Alternates header' refers to the
   Alternates header containing the variant list which was used to
   choose the best variant, and `the current variant list validator'
   refers to the validator of this list.  Section 10.4 specifies how
   these two items can be obtained by a proxy cache.

   The algorithm consists of four steps.

     1. Construct a HTTP request message on the best variant resource
        by rewriting the request-URI and Host header (if appropriate) of
        the received request message on the negotiable resource.

     2. Generate a valid HTTP response message, but not one with the
        304 (Not Modified) code, for the request message constructed in
        step 1.

        In a proxy cache, the response can be obtained from cache
        memory, or by passing the constructed HTTP request towards the
        origin server.  If the request is passed on, the proxy MAY add,
        modify, or delete If-None-Match and If-Range headers to optimize
        the transaction with the upstream server.

           Note: the proxy should be careful not to add entity tags of
           non-neighboring variants to If-* (conditional) headers of the
           request, as there are no global uniqueness requirements for
           these tags.

     3. Only in origin servers: check for an origin server
        configuration error. If the HTTP response message generated in
        step 2 contains a TCN header, then the best variant resource is
        not a proper end point in the transparent negotiation process,
        and a 506 (Variant Also Negotiates) error response message
        SHOULD be generated instead of going to step 4.

     4. Add a number of headers to the HTTP response message generated
        in step 2.






 
RFC 2295            Transparent Content Negotiation           March 1998


        a. Add a TCN header which specifies the "choice"
           response-type.

        b. Add a Content-Location header giving the location of the
           chosen variant.  Delete any Content-Location header which was
           already present.

              Note: According to the HTTP/1.1 specification [1], if the
              Content-Location header contains a relative URI, this URI
              is relative to the URI in the Content-Base header, if
              present, and relative to the request-URI if no Content-
              Base header is present.

        c. If any Vary headers are present in the response message
           from step 2, add, for every Vary header, a Variant-Vary
           header with a copy of the contents of this Vary header.

        d. Delete any Alternates headers which are present in in the
           response.  Now, the current Alternates header MUST be added
           if this is required by the Negotiate request header, or if
           the server returns "re-choose" in the TCN response header.
           Otherwise, the current Alternates header MAY be added.

              Note: It is usually a good strategy to always add the
              current Alternates header, unless it is very large
              compared to the rest of the response.

        e. Add a Vary header to 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.

        f. To ensure compatibility with HTTP/1.0 caching proxies which
           do not recognize the Vary header, an Expires header with a
           date in the past MAY be added. See section 10.7 for more