information.

        g. If an ETag header is present in the response message from
           step 2, then extend the entity tag in that header with the
           current variant list validator, as specified in section 9.2.

              Note: Step g. is required even if the variant list itself
              is not added in step d.

        h. Only in proxy caches: set the Age header of the response to

              max( variant_age , alternates_age )




 
RFC 2295            Transparent Content Negotiation           March 1998


           where variant_age is the age of the variant response obtained
           in step 2, calculated according to the rules in the HTTP/1.1
           specification [1], and alternates_age is the age of the
           Alternates header added in step d, calculated according to
           the rules in section 10.4.

   Note that a server can shorten the response produced by the above
   algorithm to a 304 (Not Modified) response if an If-None-Match header
   in the original request allows it.  If this is the case, an
   implementation of the above algorithm can avoid the unnecessary
   internal construction of full response message in step 2, it need
   only construct the parts which end up in the final 304 response.  A
   proxy cache which implements this optimization can sometimes generate
   a legal 304 response even if it has not cached the variant data
   itself.

   An example of a choice response is:

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     TCN: choice
     Content-Type: text/html
     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
     Content-Length: 5327
     Cache-control: max-age=604800
     Content-Location: paper.1
     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}}
     Etag: "gonkyyyy;1234"
     Vary: negotiate, accept, accept-language
     Expires: Thu, 01 Jan 1980 00:00:00 GMT

     A paper about ....

10.3 Adhoc response

   An adhoc response can be sent by an origin server as an extreme
   measure, to achieve compatibility with a non-negotiating or buggy
   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.  An adhoc response MUST have a TCN header which
   specifies the "adhoc" response-type, and a Vary header if the
   response is cacheable.  It MAY contain the Alternates header bound to
   the negotiable resource.






 
RFC 2295            Transparent Content Negotiation           March 1998


   Any 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.  Depending on the
   status code, an adhoc response is cacheable unless indicated
   otherwise.

   As an example of the use of an adhoc response, suppose that the
   variant resource "redirect-to-blah" yields redirection (302)
   responses.  A choice response with this variant could look as
   follows:

     HTTP/1.1 302 Moved Temporarily
     Date: Tue, 11 Jun 1996 20:02:28 GMT
     TCN: choice
     Content-location: redirect-to-blah
     Location: http://blah.org/
     Content-Type: text/html
     Content-Length: 62

     This document is available <a href=http://blah.org/>here.