12.1 Server-driven Negotiation

   If the selection of the best representation for a response is made by
   an algorithm located at the server, it is called server-driven
   negotiation.  Selection is based on the available representations of
   the response (the dimensions over which it can vary; e.g. language,
   content-coding, etc.) and the contents of particular header fields in
   the request message or on other information pertaining to the request
   (such as the network address of the client).

   Server-driven negotiation is advantageous when the algorithm for
   selecting from among the available representations is difficult to
   describe to the user agent, or when the server desires to send its
   "best guess" to the client along with the first response (hoping to
   avoid the round-trip delay of a subsequent request if the "best
   guess" is good enough for the user). In order to improve the server's
   guess, the user agent MAY include request header fields (Accept,
   Accept-Language, Accept-Encoding, etc.) which describe its
   preferences for such a response.

   Server-driven negotiation has disadvantages:

1. It is impossible for the server to accurately determine what might be
  "best" for any given user, since that would require complete
  knowledge of both the capabilities of the user agent and the intended
  use for the response (e.g., does the user want to view it on screen
  or print it on paper?).

2. Having the user agent describe its capabilities in every request can
  be both very inefficient (given that only a small percentage of
  responses have multiple representations) and a potential violation of



Fielding, et. al.           Standards Track                    [Page 68]

RFC 2068                        HTTP/1.1                    January 1997


  the user's privacy.

3. It complicates the implementation of an origin server and the
  algorithms for generating responses to a request.

4. It may limit a public cache's ability to use the same response for
  multiple user's requests.

   HTTP/1.1 includes the following request-header fields for enabling
   server-driven negotiation through description of user agent
   capabilities and user preferences: Accept (section 14.1), Accept-
   Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
   Language (section 14.4), and User-Agent (section 14.42). However, an
   origin server is not limited to these dimensions and MAY vary the
   response based on any aspect of the request, including information
   outside the request-header fields or within extension header fields
   not defined by this specification.

   HTTP/1.1 origin servers MUST include an appropriate Vary header field
   (section 14.43) in any cachable response based on server-driven
   negotiation. The Vary header field describes the dimensions over
   which the response might vary (i.e. the dimensions over which the
   origin server picks its "best guess" response from multiple
   representations).

   HTTP/1.1 public caches MUST recognize the Vary header field when it
   is included in a response and obey the requirements described in
   section 13.6 that describes the interactions between caching and
   content negotiation.

12.2 Agent-driven Negotiation

   With agent-driven negotiation, selection of the best representation
   for a response is performed by the user agent after receiving an
   initial response from the origin server. Selection is based on a list
   of the available representations of the response included within the
   header fields (this specification reserves the field-name Alternates,
   as described in appendix 19.6.2.1) or entity-body of the initial
   response, with each representation identified by its own URI.
   Selection from among the representations may be performed
   automatically (if the user agent is capable of doing so) or manually
   by the user selecting from a generated (possibly hypertext) menu.

   Agent-driven negotiation is advantageous when the response would vary
   over commonly-used dimensions (such as type, language, or encoding),
   when the origin server is unable to determine a user agent's
   capabilities from examining the request, and generally when public
   caches are used to distribute server load and reduce network usage.



Fielding, et. al.           Standards Track                    [Page 69]

RFC 2068                        HTTP/1.1                    January 1997


   Agent-driven negotiation suffers from the disadvantage of needing a
   second request to obtain the best alternate representation. This
   second request is only efficient when caching is used. In addition,
   this specification does not define any mechanism for supporting
   automatic selection, though it also does not prevent any such
   mechanism from being developed as an extension and used within
   HTTP/1.1.

   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
   status codes for enabling agent-driven negotiation when the server is
   unwilling or unable to provide a varying response using server-driven
   negotiation.