You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
153 lines
7.9 KiB
153 lines
7.9 KiB
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns='http://www.w3.org/1999/xhtml'>
|
|
<head><title>HTTP/1.1: Content Negotiation</title></head>
|
|
<body><address>part of <a rev='Section' href='rfc2616.html'>Hypertext Transfer Protocol -- HTTP/1.1</a><br />
|
|
RFC 2616 Fielding, et al.</address>
|
|
<h2><a id='sec12'>12</a> Content Negotiation</h2>
|
|
<p>
|
|
Most HTTP responses include an entity which contains information for
|
|
interpretation by a human user. Naturally, it is desirable to supply
|
|
the user with the "best available" entity corresponding to the
|
|
request. Unfortunately for servers and caches, not all users have the
|
|
same preferences for what is "best," and not all user agents are
|
|
equally capable of rendering all entity types. For that reason, HTTP
|
|
has provisions for several mechanisms for "content negotiation" --
|
|
the process of selecting the best representation for a given response
|
|
when there are multiple representations available.
|
|
</p>
|
|
<pre> Note: This is not called "format negotiation" because the
|
|
alternate representations may be of the same media type, but use
|
|
different capabilities of that type, be in different languages,
|
|
etc.
|
|
</pre>
|
|
<p>
|
|
Any response containing an entity-body MAY be subject to negotiation,
|
|
including error responses.
|
|
</p>
|
|
<p>
|
|
There are two kinds of content negotiation which are possible in
|
|
HTTP: server-driven and agent-driven negotiation. These two kinds of
|
|
negotiation are orthogonal and thus may be used separately or in
|
|
combination. One method of combination, referred to as transparent
|
|
negotiation, occurs when a cache uses the agent-driven negotiation
|
|
information provided by the origin server in order to provide
|
|
server-driven negotiation for subsequent requests.
|
|
</p>
|
|
<h3><a id='sec12.1'>12.1</a> Server-driven Negotiation</h3>
|
|
<p>
|
|
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).
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
Server-driven negotiation has disadvantages:
|
|
</p>
|
|
<pre> 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?).
|
|
</pre>
|
|
<pre> 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 the user's privacy.
|
|
</pre>
|
|
<pre> 3. It complicates the implementation of an origin server and the
|
|
algorithms for generating responses to a request.
|
|
</pre>
|
|
<pre> 4. It may limit a public cache's ability to use the same response
|
|
for multiple user's requests.
|
|
</pre>
|
|
<p>
|
|
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 <a rel='xref' href='rfc2616-sec14.html#sec14.1'>14.1</a>), Accept-
|
|
Charset (section <a rel='xref' href='rfc2616-sec14.html#sec14.2'>14.2</a>), Accept-Encoding (section <a rel='xref' href='rfc2616-sec14.html#sec14.3'>14.3</a>), Accept-
|
|
Language (section <a rel='xref' href='rfc2616-sec14.html#sec14.4'>14.4</a>), and User-Agent (section <a rel='xref' href='rfc2616-sec14.html#sec14.43'>14.43</a>). 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.
|
|
</p>
|
|
<p>
|
|
The Vary header field can be used to express the parameters the
|
|
server uses to select a representation that is subject to server-
|
|
driven negotiation. See section <a rel='xref' href='rfc2616-sec13.html#sec13.6'>13.6</a> for use of the Vary header field
|
|
by caches and section <a rel='xref' href='rfc2616-sec14.html#sec14.44'>14.44</a> for use of the Vary header field by
|
|
servers.
|
|
</p>
|
|
<h3><a id='sec12.2'>12.2</a> Agent-driven Negotiation</h3>
|
|
<p>
|
|
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 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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<h3><a id='sec12.3'>12.3</a> Transparent Negotiation</h3>
|
|
<p>
|
|
Transparent negotiation is a combination of both server-driven and
|
|
agent-driven negotiation. When a cache is supplied with a form of the
|
|
list of available representations of the response (as in agent-driven
|
|
negotiation) and the dimensions of variance are completely understood
|
|
by the cache, then the cache becomes capable of performing server-
|
|
driven negotiation on behalf of the origin server for subsequent
|
|
requests on that resource.
|
|
</p>
|
|
<p>
|
|
Transparent negotiation has the advantage of distributing the
|
|
negotiation work that would otherwise be required of the origin
|
|
server and also removing the second request delay of agent-driven
|
|
negotiation when the cache is able to correctly guess the right
|
|
response.
|
|
</p>
|
|
<p>
|
|
This specification does not define any mechanism for transparent
|
|
negotiation, though it also does not prevent any such mechanism from
|
|
being developed as an extension that could be used within HTTP/1.1.
|
|
</p>
|
|
</body></html>
|