rfc2616-sec12.html
7.87 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
<!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>