1 |
|
2 |
HTTP Working Group Koen Holtman, TUE |
3 |
Internet-Draft Andrew Mutz, Hewlett-Packard |
4 |
Expires: September 9, 1997 March 9, 1997 |
5 |
|
6 |
|
7 |
Transparent Content Negotiation in HTTP |
8 |
|
9 |
draft-ietf-http-negotiation-01.txt |
10 |
|
11 |
|
12 |
STATUS OF THIS MEMO |
13 |
|
14 |
This document is an Internet-Draft. Internet-Drafts are |
15 |
working documents of the Internet Engineering Task Force |
16 |
(IETF), its areas, and its working groups. Note that other |
17 |
groups may also distribute working documents as |
18 |
Internet-Drafts. |
19 |
|
20 |
Internet-Drafts are draft documents valid for a maximum of |
21 |
six months and may be updated, replaced, or obsoleted by |
22 |
other documents at any time. It is inappropriate to use |
23 |
Internet-Drafts as reference material or to cite them other |
24 |
than as "work in progress". |
25 |
|
26 |
To learn the current status of any Internet-Draft, please |
27 |
check the "1id-abstracts.txt" listing contained in the |
28 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
29 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
30 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
31 |
West Coast). |
32 |
|
33 |
Distribution of this document is unlimited. Please send |
34 |
comments to the HTTP working group at |
35 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
36 |
group are archived at |
37 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
38 |
discussions about HTTP and the applications which use HTTP |
39 |
should take place on the <www-talk@w3.org> mailing list. |
40 |
|
41 |
HTML and change bar versions of this document, are available |
42 |
at <URL:http://gewis.win.tue.nl/~koen/conneg/>. |
43 |
|
44 |
|
45 |
ABSTRACT |
46 |
|
47 |
HTTP allows web site authors to put multiple versions of the |
48 |
same information under a single URL. Transparent content |
49 |
negotiation is a mechanism, layered on top of HTTP, for |
50 |
automatically selecting the best version when the URL is |
51 |
accessed. This enables the smooth deployment of new web data |
52 |
formats and markup tags. |
53 |
|
54 |
|
55 |
|
56 |
OVERVIEW OF THE TRANSPARENT CONTENT NEGOTIATION DOCUMENT SET |
57 |
|
58 |
An up-to-date overview of documents related to transparent content |
59 |
negotiation is maintained on the web page |
60 |
<URL:http://gewis.win.tue.nl/~koen/conneg/>. |
61 |
|
62 |
The transparent content negotiation document set currently consists |
63 |
of three series of internet drafts. |
64 |
|
65 |
1. draft-ietf-http-negotiation-XX.txt (this document) |
66 |
|
67 |
`Transparent Content Negotiation in HTTP' |
68 |
|
69 |
Defines the core mechanism. Standards track. |
70 |
|
71 |
2. draft-ietf-http-rvsa-v10-XX.txt |
72 |
|
73 |
`HTTP Remote Variant Selection Algorithm -- RVSA/1.0' |
74 |
|
75 |
Defines the remote variant selection algorithm version 1.0. |
76 |
Standards track. |
77 |
|
78 |
3. draft-ietf-http-feature-reg-XX.txt |
79 |
|
80 |
`Feature Tag Registration Procedures' |
81 |
|
82 |
Defines feature tag registration. Best Current Practice track. |
83 |
|
84 |
An additional document about `the core feature set', which may |
85 |
later become an informational RFC, may also appear. Currently, |
86 |
there are two internet drafts which discuss parts of what could be |
87 |
a core feature set: draft-mutz-http-attributes-XX.txt and |
88 |
draft-goland-http-headers-XX.txt |
89 |
|
90 |
Older versions of the text in documents 1 and 2 may be found in the |
91 |
draft-holtman-http-negotiation-XX.txt series of internet drafts. |
92 |
|
93 |
|
94 |
TABLE OF CONTENTS |
95 |
|
96 |
1 Introduction |
97 |
1.1 Background |
98 |
1.2 Revision history |
99 |
|
100 |
2 Terminology |
101 |
2.1 Terms from HTTP/1.1 |
102 |
2.2 New terms |
103 |
|
104 |
3 Notation |
105 |
|
106 |
4 Overview |
107 |
4.1 Content negotiation |
108 |
4.2 HTTP/1.0 style negotiation scheme |
109 |
4.3 Transparent content negotiation scheme |
110 |
4.4 Optimizing the negotiation process |
111 |
4.5 Downwards compatibility with non-negotiating user agents |
112 |
4.6 Retrieving a variant by hand |
113 |
4.7 Dimensions of negotiation |
114 |
4.8 Feature negotiation |
115 |
|
116 |
5 Variant descriptions |
117 |
5.1 Syntax |
118 |
5.2 URI |
119 |
5.3 Source-quality |
120 |
5.4 Type, charset, language, and length |
121 |
5.5 Features |
122 |
5.6 Description |
123 |
5.7 Extension-attribute |
124 |
|
125 |
6 Feature negotiation |
126 |
6.1 Feature tags |
127 |
6.2 Accept-Features header |
128 |
6.3 Feature predicates |
129 |
6.4 Features attribute |
130 |
|
131 |
7 Remote variant selection algorithms |
132 |
7.1 Version numbers |
133 |
|
134 |
8 Content negotiation status codes and headers |
135 |
8.1 506 Variant Also Negotiates |
136 |
8.2 Accept-Charset |
137 |
8.3 Accept-Features |
138 |
8.4 Alternates |
139 |
8.5 Content-Features |
140 |
8.6 Negotiate |
141 |
8.7 TCN |
142 |
8.8 Variant-Vary |
143 |
|
144 |
9 Cache validators |
145 |
9.1 Variant list validators |
146 |
9.2 Structured entity tags |
147 |
9.3 Assigning entity tags to variants |
148 |
|
149 |
10 Content negotiation responses |
150 |
10.1 List response |
151 |
10.2 Choice response |
152 |
10.3 Ad hoc response |
153 |
10.4 Reusing the Alternates header |
154 |
10.5 Extracting a normal response from a choice response |
155 |
10.6 Elaborate Vary headers |
156 |
10.6.1 Construction of an elaborate Vary header |
157 |
10.6.2 Caching of an elaborate Vary header |
158 |
10.7 Adding an Expires header to ensure HTTP/1.0 compatibility |
159 |
10.8 Negotiation on content encoding |
160 |
|
161 |
11 User agent support for transparent negotiation |
162 |
11.1 Handling of responses |
163 |
11.2 Presentation of a transparently negotiated resource |
164 |
|
165 |
12 Origin server support for transparent negotiation |
166 |
12.1 Requirements |
167 |
12.2 Negotiation on transactions other than GET and HEAD |
168 |
|
169 |
13 Proxy support for transparent negotiation |
170 |
|
171 |
14 Security and privacy considerations |
172 |
14.1 Accept- headers revealing information of a private nature |
173 |
14.2 Spoofing of responses from variant resources |
174 |
|
175 |
15 Acknowledgments |
176 |
|
177 |
16 References |
178 |
|
179 |
17 Authors' addresses |
180 |
|
181 |
18 Appendix: feature negotiation examples |
182 |
18.1 Use of feature tags |
183 |
18.2 Use of numeric feature tags |
184 |
18.3 Feature tag design |
185 |
|
186 |
19 Appendix: origin server implementation considerations |
187 |
19.1 Implementation with a CGI script |
188 |
19.2 Direct support by HTTP servers |
189 |
19.3 Web publishing tools |
190 |
|
191 |
20 Appendix: Example of choice response construction |
192 |
|
193 |
|
194 |
1 Introduction |
195 |
|
196 |
HTTP allows web site authors to put multiple versions of the same |
197 |
information under a single URI. Each of these versions is called a |
198 |
`variant'. Transparent content negotiation is a mechanism for |
199 |
automatically and efficiently retrieving the best variant when a |
200 |
GET or HEAD request is made. This enables the smooth deployment of |
201 |
new web data formats and markup tags. |
202 |
|
203 |
This specification defines transparent content negotiation as an |
204 |
extension on top of the HTTP/1.1 protocol [1]. However, use of |
205 |
this extension does not require use of HTTP/1.1: transparent |
206 |
content negotiation can also be done if some or all of the parties |
207 |
are HTTP/1.0 [3] systems. |
208 |
|
209 |
Transparent content negotiation is called `transparent' because it |
210 |
makes all variants which exist inside the origin server visible to |
211 |
outside parties. |
212 |
|
213 |
Note: Though this specification is limited to negotiation on |
214 |
HTTP transactions, elements of this specification could also be |
215 |
used in other contexts. For example, feature predicates could |
216 |
be used in conditional HTML, and variant descriptions could be |
217 |
used in multipart mail messages. Such use in other contexts is |
218 |
encouraged. |
219 |
|
220 |
|
221 |
1.1 Background |
222 |
|
223 |
The addition of content negotiation to the web infrastructure has |
224 |
been considered important since the early days of the web. Among |
225 |
the expected benefits of a sufficiently powerful system for content |
226 |
negotiation are |
227 |
|
228 |
* smooth deployment of new data formats and markup tags will |
229 |
allow graceful evolution of the web |
230 |
|
231 |
* eliminating the need to choose between a `state of the art |
232 |
multimedia homepage' and one which can be viewed by all web |
233 |
users |
234 |
|
235 |
* enabling good service to a wider range of browsing |
236 |
platforms (from low-end PDA's to high-end VR setups) |
237 |
|
238 |
* eliminating error-prone and cache-unfriendly |
239 |
User-Agent based negotiation |
240 |
|
241 |
* enabling construction of sites without `click here for the X |
242 |
version' links |
243 |
|
244 |
* internationalization, and the ability to offer multi-lingual |
245 |
content without a bias towards one language. |
246 |
|
247 |
|
248 |
1.2 Revision history |
249 |
|
250 |
Major semantical changes are: |
251 |
|
252 |
- The TCN header has been introduced to reduce the requirements |
253 |
in section 10 on the use of existing HTTP/1.1 headers and the |
254 |
Alternates header. This reduction in requirements should make |
255 |
it easier to use these headers in other negotiation schemes. |
256 |
|
257 |
- The requirement that proxies filter out illegal choice |
258 |
responses has been removed. |
259 |
|
260 |
Many small errors have been corrected, and some existing text has |
261 |
been improved. |
262 |
|
263 |
|
264 |
2 Terminology |
265 |
|
266 |
2.1 Terms from HTTP/1.1 |
267 |
|
268 |
This specification mostly uses the terminology of the HTTP/1.1 |
269 |
specification [1]. The definitions below were reproduced from [1]. |
270 |
|
271 |
request |
272 |
An HTTP request message. |
273 |
|
274 |
response |
275 |
An HTTP response message. |
276 |
|
277 |
resource |
278 |
A network data object or service that can be identified by a URI. |
279 |
Resources may be available in multiple representations |
280 |
(e.g. multiple languages, data formats, size, resolutions) or |
281 |
vary in other ways. |
282 |
|
283 |
content negotiation |
284 |
The mechanism for selecting the appropriate representation when |
285 |
servicing a request. |
286 |
|
287 |
variant |
288 |
A resource may have one, or more than one, representation(s) |
289 |
associated with it at any given instant. Each of these |
290 |
representations is termed a `variant.' Use of the term `variant' |
291 |
does not necessarily imply that the resource is subject to |
292 |
content negotiation. |
293 |
|
294 |
client |
295 |
A program that establishes connections for the purpose of sending |
296 |
requests. |
297 |
|
298 |
user agent |
299 |
The client which initiates a request. These are often browsers, |
300 |
editors, spiders (web-traversing robots), or other end user |
301 |
tools. |
302 |
|
303 |
server |
304 |
An application program that accepts connections in order to |
305 |
service requests by sending back responses. Any given program may |
306 |
be capable of being both a client and a server; our use of these |
307 |
terms refers only to the role being performed by the program for |
308 |
a particular connection, rather than to the program's |
309 |
capabilities in general. Likewise, any server may act as an |
310 |
origin server, proxy, gateway, or tunnel, switching behavior |
311 |
based on the nature of each request. |
312 |
|
313 |
origin server |
314 |
The server on which a given resource resides or is to be created. |
315 |
|
316 |
proxy |
317 |
An intermediary program which acts as both a server and a client |
318 |
for the purpose of making requests on behalf of other |
319 |
clients. Requests are serviced internally or by passing them on, |
320 |
with possible translation, to other servers. A proxy must |
321 |
implement both the client and server requirements of this |
322 |
specification. |
323 |
|
324 |
age |
325 |
The age of a response is the time since it was sent by, or |
326 |
successfully validated with, the origin server. |
327 |
|
328 |
fresh |
329 |
A response is fresh if its age has not yet exceeded its freshness |
330 |
lifetime. |
331 |
|
332 |
|
333 |
2.2 New terms |
334 |
|
335 |
transparently negotiable resource |
336 |
A resource, identified by a single URI, which has multiple |
337 |
representations (variants) associated with it. When servicing a |
338 |
request on its URI, it allows selection of the best |
339 |
representation using the transparent content negotiation |
340 |
mechanism. A transparently negotiable resource always has a |
341 |
variant list bound to it, which can be represented as an |
342 |
Alternates header. |
343 |
|
344 |
variant list |
345 |
A list containing variant descriptions, which can be bound to a |
346 |
transparently negotiable resource. |
347 |
|
348 |
variant description |
349 |
A machine-readable description of a variant resource, usually |
350 |
found in a variant list. A variant description contains the |
351 |
variant resource URI and various attributes which describe |
352 |
properties of the variant. Variant descriptions are defined in |
353 |
section 5. |
354 |
|
355 |
variant resource |
356 |
A resource from which a variant of a negotiable resource can be |
357 |
retrieved with a simple GET request. |
358 |
|
359 |
neighboring variant |
360 |
A variant resource is called a neighboring variant resource of |
361 |
some transparently negotiable HTTP resource if the variant |
362 |
resource has a HTTP URL, and if the absolute URL of the variant |
363 |
resource up to its last slash equals the absolute URL of the |
364 |
negotiable resource up to its last slash, where equality is |
365 |
determined with the URI comparison rules in section 3.2.3 of [1]. |
366 |
The property of being a neighboring variant is important because |
367 |
of security considerations (section 14.2). Not all variants of a |
368 |
negotiable resource need to be neighboring variants. However, |
369 |
access to neighboring variants can be more highly optimized by |
370 |
the use of remote variant selection algorithms (section 7) and |
371 |
choice responses (section 10.2). |
372 |
|
373 |
remote variant selection algorithm |
374 |
A standardized algorithm by which a server can sometimes choose a |
375 |
best variant on behalf of a negotiating user agent. The |
376 |
algorithm typically computes whether the Accept- headers in the |
377 |
request contain sufficient information to allow a choice, and if |
378 |
so, which variant is the best variant. The use of a remote |
379 |
algorithm can speed up the negotiation process. |
380 |
|
381 |
list response |
382 |
A list response contains the variant list of the negotiable |
383 |
resource, but no variant data. It is generated when the server |
384 |
does not (perhaps cannot) choose a particular best variant for the |
385 |
request. List responses are defined in section 10.1. |
386 |
|
387 |
choice response |
388 |
A choice response contains both the variant list of the |
389 |
negotiable resource and a representation of the best variant for |
390 |
the request. It can be generated when the server has sufficient |
391 |
information to be able to choose the best variant on behalf the |
392 |
user agent, but may only be generated if this best variant is a |
393 |
neighboring variant. Choice responses are defined in section |
394 |
10.2. |
395 |
|
396 |
ad hoc response |
397 |
An ad hoc response contains the variant list of the negotiable |
398 |
resource, and any other data the origin server wants to send. It |
399 |
can be generated as a response to a non-negotiating user agent if |
400 |
the server does not (perhaps cannot) choose any particular |
401 |
variant. Ad hoc responses are defined in section 10.3. |
402 |
|
403 |
Accept- headers |
404 |
The request headers: Accept, Accept-Charset, Accept-Language, and |
405 |
Accept-Features. |
406 |
|
407 |
supports transparent content negotiation |
408 |
From the viewpoint of an origin server or proxy, a user agent |
409 |
supports transparent content negotiation if and only if it sends |
410 |
a Negotiate header (section 8.6) which indicates such support. |
411 |
|
412 |
|
413 |
3 Notation |
414 |
|
415 |
The version of BNF used in this document is taken from [1], and |
416 |
many of the nonterminals used are defined in [1]. |
417 |
|
418 |
One new BNF construct is added: |
419 |
|
420 |
1%rule |
421 |
|
422 |
stands for one or more instances of "rule", separated by |
423 |
whitespace: |
424 |
|
425 |
1%rule = rule *( 1*LWS rule ) |
426 |
|
427 |
This specification also introduces |
428 |
|
429 |
number = 1*DIGIT |
430 |
|
431 |
short-float = 1*3DIGIT [ "." 0*3DIGIT ] |
432 |
|
433 |
This specification uses the same conventions as in [1] (see section |
434 |
1.2 of [1]) for defining the significance of each particular |
435 |
requirement. |
436 |
|
437 |
|
438 |
4 Overview |
439 |
|
440 |
This section gives an overview of transparent content negotiation. |
441 |
It starts with a more general discussion of negotiation as provided |
442 |
by HTTP. |
443 |
|
444 |
|
445 |
4.1 Content negotiation |
446 |
|
447 |
HTTP/1.1 allows web site authors to put multiple versions of the |
448 |
same information under a single resource URI. Each of these |
449 |
versions is called a `variant'. For example, a resource |
450 |
http://x.org/paper could bind to three different variants of a |
451 |
paper: |
452 |
|
453 |
1. HTML, English |
454 |
2. HTML, French |
455 |
3. Postscript, English |
456 |
|
457 |
Content negotiation is the process by which the best variant is |
458 |
selected if the resource is accessed. The selection is done by |
459 |
matching the properties of the available variants to the |
460 |
capabilities of the user agent and the preferences of the user. |
461 |
|
462 |
It has always been possible under HTTP to have multiple |
463 |
representations available for one resource, and to return the most |
464 |
appropriate representation for each subsequent request. However, |
465 |
HTTP/1.1 is the first version of HTTP which has provisions for |
466 |
doing this in a cache-friendly way. These provisions include the |
467 |
Vary response header, entity tags, and the If-None-Match request |
468 |
header. |
469 |
|
470 |
|
471 |
4.2 HTTP/1.0 style negotiation scheme |
472 |
|
473 |
The HTTP/1.0 protocol elements allow for a negotiation scheme as |
474 |
follows: |
475 |
|
476 |
Server _____ proxy _____ proxy _____ user |
477 |
x.org cache cache agent |
478 |
|
479 |
< ---------------------------------- |
480 |
| GET http://x.org/paper |
481 |
| Accept- headers |
482 |
choose |
483 |
| |
484 |
---------------------------------- > |
485 |
Best variant |
486 |
|
487 |
When the resource is accessed, the user agent sends (along with its |
488 |
request) various Accept- headers which express the user agent |
489 |
capabilities and the user preferences. Then the origin server uses |
490 |
these Accept- headers to choose the best variant, which is returned |
491 |
in the response. |
492 |
|
493 |
The biggest problem with this scheme is that it does not scale |
494 |
well. For all but the most minimal user agents, Accept- headers |
495 |
expressing all capabilities and preferences would be very large, |
496 |
and sending them in every request would be hugely inefficient, in |
497 |
particular because only a small fraction of the resources on the |
498 |
web have multiple variants. |
499 |
|
500 |
|
501 |
4.3 Transparent content negotiation scheme |
502 |
|
503 |
The transparent content negotiation scheme eliminates the need to |
504 |
send huge Accept- headers, and nevertheless allows for a selection |
505 |
process that always yields either the best variant, or an error |
506 |
message indicating that user agent is not capable of displaying any |
507 |
of the available variants. |
508 |
|
509 |
Under the transparent content negotiation scheme, the server sends |
510 |
a list with the available variants and their properties to the user |
511 |
agent. An example of a list with three variants is |
512 |
|
513 |
{"paper.html.en" 0.9 {type text/html} {language en}}, |
514 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
515 |
{"paper.ps.en" 1.0 {type application/postscript} {language en}} |
516 |
|
517 |
The syntax and semantics of the variant descriptions in this list |
518 |
are covered in section 5. When the list is received, the user |
519 |
agent can choose the best variant and retrieve it. Graphically, |
520 |
the communication can be represented as follows: |
521 |
|
522 |
Server _____ proxy _____ proxy _____ user |
523 |
x.org cache cache agent |
524 |
|
525 |
< ---------------------------------- |
526 |
| GET http://x.org/paper |
527 |
| |
528 |
----------------------------------- > [list response] |
529 |
return of list | |
530 |
choose |
531 |
| |
532 |
< ---------------------------------- |
533 |
| GET http://x.org/paper.html.en |
534 |
| |
535 |
---------------------------------- > [normal response] |
536 |
return of html.en |
537 |
|
538 |
The first response returning the list of variants is called a `list |
539 |
response'. The second response is a normal HTTP response: it does |
540 |
not contain special content negotiation related information. Only |
541 |
the user agent needs to know that the second request actually |
542 |
retrieves a variant. For the other parties in the communication, |
543 |
the second transaction is indistinguishable from a normal HTTP |
544 |
transaction. |
545 |
|
546 |
With this scheme, information about capabilities and preferences is |
547 |
only used by the user agent itself. Therefore, sending such |
548 |
information in large Accept- headers is unnecessary. Accept- |
549 |
headers do have a limited use in transparent content negotiation |
550 |
however; the sending of small Accept- headers can often speed up the |
551 |
negotiation process. This is covered in section 4.4. |
552 |
|
553 |
List responses are covered in section 10.1. As an example, the |
554 |
list response in the above picture could be: |
555 |
|
556 |
HTTP/1.1 300 Multiple Choices |
557 |
Date: Tue, 11 Jun 1996 20:02:21 GMT |
558 |
TCN: list |
559 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
560 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
561 |
{"paper.ps.en" 1.0 {type application/postscript} |
562 |
{language en}} |
563 |
Vary: negotiate, accept, accept-language |
564 |
ETag: "blah;1234" |
565 |
Cache-control: max-age=86400 |
566 |
Content-Type: text/html |
567 |
Content-Length: 227 |
568 |
|
569 |
<h2>Multiple Choices:</h2> |
570 |
<ul> |
571 |
<li><a href=paper.html.en>HTML, English version</a> |
572 |
<li><a href=paper.html.fr>HTML, French version</a> |
573 |
<li><a href=paper.ps.en>Postscript, English version</a> |
574 |
</ul> |
575 |
|
576 |
The Alternates header in the response contains the variant list. |
577 |
The Vary header is included to ensure correct caching by plain |
578 |
HTTP/1.1 caches (see section 10.6). The ETag header allows the |
579 |
response to be revalidated by caches, the Cache-Control header |
580 |
controls this revalidation. The HTML entity included in the |
581 |
response allows the user to select the best variant by hand if |
582 |
desired. |
583 |
|
584 |
|
585 |
4.4 Optimizing the negotiation process |
586 |
|
587 |
The basic transparent negotiation scheme involves two HTTP |
588 |
transactions: one to retrieve the list, and a second one to retrieve |
589 |
the chosen variant. There are however several ways to `cut corners' |
590 |
in the data flow path of the basic scheme. |
591 |
|
592 |
First, caching proxies can cache both variant lists and variants. |
593 |
Such caching can reduce the communication overhead, as shown in the |
594 |
following example: |
595 |
|
596 |
Server _____ proxy _____ proxy __________ user |
597 |
x.org cache cache agent |
598 |
|
599 |
< -------------- |
600 |
| GET ../paper |
601 |
| |
602 |
has the list |
603 |
in cache |
604 |
| |
605 |
------------- > [list response] |
606 |
list | |
607 |
| |
608 |
choose |
609 |
| |
610 |
< -------------------------- |
611 |
| GET ../paper.html.en |
612 |
| |
613 |
has the variant |
614 |
in cache |
615 |
| |
616 |
-------------------------- > [normal response] |
617 |
return of html.en |
618 |
|
619 |
Second, the user agent can send small Accept- headers, which may |
620 |
contain enough information to allow the server to choose the best |
621 |
variant and return it directly. |
622 |
|
623 |
Server _____ proxy _____ proxy _____ user |
624 |
x.org cache cache agent |
625 |
|
626 |
< ---------------------------------- |
627 |
| GET http://x.org/paper |
628 |
| small Accept- headers |
629 |
| |
630 |
able to choose on |
631 |
behalf of user agent |
632 |
| |
633 |
---------------------------------- > [choice response] |
634 |
return of html.en and list |
635 |
|
636 |
This choosing based on small Accept- headers is done with a `remote |
637 |
variant selection algorithm'. Such an algorithm takes the variant |
638 |
list and the Accept- headers as input. It then computes whether the |
639 |
Accept- headers contain sufficient information to choose on behalf |
640 |
of the user agent, and if so, which variant is the best variant. |
641 |
If the best variant is a neighboring variant, it may be returned, |
642 |
together with the variant list, in a choice response. |
643 |
|
644 |
A server may only choose on behalf of a user agent supporting |
645 |
transparent content negotiation if the user agent explicitly allows |
646 |
the use of a particular remote variant selection algorithm in the |
647 |
Negotiate request header. User agents with sophisticated internal |
648 |
variant selection algorithms may want to disallow a remote choice, |
649 |
or may want to allow it only when retrieving inline images. If the |
650 |
local algorithm of the user agent is superior in only some |
651 |
difficult areas of negotiation, it is possible to enable the remote |
652 |
algorithm for the easy areas only. More information about the use |
653 |
of a remote variant selection algorithm can be found in [5]. |
654 |
|
655 |
Choice responses are covered in section 10.2. For example, the |
656 |
choice response in the above picture could be: |
657 |
|
658 |
HTTP/1.1 200 OK |
659 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
660 |
TCN: choice |
661 |
Content-Type: text/html |
662 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
663 |
Content-Length: 5327 |
664 |
Cache-control: max-age=604800 |
665 |
Content-Location: paper.html.en |
666 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
667 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
668 |
{"paper.ps.en" 1.0 {type application/postscript} |
669 |
{language en}} |
670 |
Etag: "gonkyyyy;1234" |
671 |
Vary: negotiate, accept, accept-language |
672 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
673 |
|
674 |
<title>A paper about .... |
675 |
|
676 |
Finally, the above two kinds of optimization can be combined; a |
677 |
caching proxy which has the list will sometimes be able to choose on |
678 |
behalf of the user agent. This could lead to the following |
679 |
communication pattern: |
680 |
|
681 |
Server _____ proxy _____ proxy __________ user |
682 |
x.org cache cache agent |
683 |
|
684 |
< --------------- |
685 |
| GET ../paper |
686 |
| small Accept |
687 |
| |
688 |
able to choose |
689 |
on behalf |
690 |
| |
691 |
< ---------- |
692 |
| GET ../paper.html.en |
693 |
| |
694 |
---------- > [normal response] |
695 |
html.en | |
696 |
---------------- > [choice response] |
697 |
html.en and list |
698 |
|
699 |
Note that this cutting of corners not only saves bandwidth, it also |
700 |
eliminates delays due to packet round trip times, and reduces the |
701 |
load on the origin server. |
702 |
|
703 |
|
704 |
4.5 Downwards compatibility with non-negotiating user agents |
705 |
|
706 |
To handle requests from user agents which do not support |
707 |
transparent content negotiation, this specification allows the |
708 |
origin server to revert to a HTTP/1.0 style negotiation scheme. |
709 |
The specification of heuristics for such schemes is beyond the |
710 |
scope of this document. |
711 |
|
712 |
|
713 |
4.6 Retrieving a variant by hand |
714 |
|
715 |
If a transparently negotiated resource is accessed, the user agent |
716 |
will always at some point receive the list of available variants. |
717 |
The user agent can use this list to make available a menu of all |
718 |
variants and their characteristics to the user. Such a menu allows |
719 |
the user to randomly browse other variants, and makes it possible |
720 |
to manually correct any sub-optimal choice made by the automatic |
721 |
negotiation process. |
722 |
|
723 |
|
724 |
4.7 Dimensions of negotiation |
725 |
|
726 |
Transparent content negotiation defines four dimensions of |
727 |
negotiation: |
728 |
|
729 |
1. Media type (MIME type) |
730 |
2. Charset |
731 |
3. Language |
732 |
4. Features |
733 |
|
734 |
The first three dimensions have traditionally been present in HTTP. |
735 |
The fourth dimension is added by this specification. Additional |
736 |
dimensions, beyond the four mentioned above, could be added by |
737 |
future specifications. |
738 |
|
739 |
Negotiation on the content encoding of a response (gzipped, |
740 |
compressed, etc.) is left outside of the realm of transparent |
741 |
negotiation. See section 10.8 for more information. |
742 |
|
743 |
|
744 |
4.8 Feature negotiation |
745 |
|
746 |
Feature negotiation intends to provide for all areas of negotiation |
747 |
not covered by the type, charset, and language dimensions. |
748 |
Examples are negotiation on |
749 |
|
750 |
* HTML extensions |
751 |
* Extensions of other media types |
752 |
* Color capabilities of the user agent |
753 |
* Screen size |
754 |
* Output medium (screen, paper, ...) |
755 |
* Preference for speed vs. preference for graphical detail |
756 |
|
757 |
The feature negotiation framework (section 6) is the principal |
758 |
means by which transparent negotiation offers extensibility; a new |
759 |
dimension of negotiation (really a sub-dimension of the feature |
760 |
dimension) can be added without the need for a new standards effort |
761 |
by the simple registration of a `feature tag'. Feature tag |
762 |
registration is discussed in [4]. |
763 |
|
764 |
|
765 |
5 Variant descriptions |
766 |
|
767 |
5.1 Syntax |
768 |
|
769 |
A variant can be described in a machine-readable way with a variant |
770 |
description. |
771 |
|
772 |
variant-description = |
773 |
"{" <"> URI <"> source-quality *variant-attribute"}" |
774 |
|
775 |
source-quality = qvalue |
776 |
|
777 |
variant-attribute = "{" "type" media-type "}" |
778 |
| "{" "charset" charset "}" |
779 |
| "{" "language" 1#language-tag "}" |
780 |
| "{" "length" 1*DIGIT "}" |
781 |
| "{" "features" feature-list "}" |
782 |
| "{" "description" quoted-string "}" |
783 |
| extension-attribute |
784 |
|
785 |
extension-attribute = "{" extension-name extension-value "}" |
786 |
extension-name = token |
787 |
extension-value = *( token | quoted-string | LWS |
788 |
| extension-specials ) |
789 |
|
790 |
extension-specials = |
791 |
<any element of tspecials except <"> and "}"> |
792 |
|
793 |
Examples are |
794 |
|
795 |
{"paper.html.fr" 0.7 {type text/html} {language fr}} |
796 |
|
797 |
{"paper.html.tables" 0.9 {type text/html} {features tables}} |
798 |
|
799 |
{"paper.html.en"} |
800 |
|
801 |
The various attributes which can be present in a variant |
802 |
description are covered in the subsections below. Each attribute |
803 |
may appear only once in a variant description. |
804 |
|
805 |
|
806 |
5.2 URI |
807 |
|
808 |
The URI attribute gives the URI of the resource from which the |
809 |
variant can be retrieved with a GET request. It can be absolute or |
810 |
relative to the Request-URI. The variant resource may vary (on the |
811 |
Cookie request header, for example), but MUST NOT engage in |
812 |
transparent content negotiation itself. |
813 |
|
814 |
|
815 |
5.3 Source-quality |
816 |
|
817 |
The source-quality attribute gives the quality of the variant, as a |
818 |
representation of the negotiable resource, when this variant is |
819 |
rendered with a perfect rendering engine on the best possible |
820 |
output medium. |
821 |
|
822 |
If the source-quality is less than 1, it often expresses a quality |
823 |
degradation caused by a lossy conversion to a particular data |
824 |
format. For example, a picture originally in JPEG form would have |
825 |
a lower source quality when translated to the XBM format, and a |
826 |
much lower source quality when translated to an ASCII-art variant. |
827 |
Note however, that degradation is a function of the source; an |
828 |
original piece of ASCII-art may degrade in quality if it is |
829 |
captured in JPEG form. |
830 |
|
831 |
The source-quality could also represent a level of quality caused |
832 |
by skill of language translation, or ability of the used media type |
833 |
to capture the intended artistic expression. |
834 |
|
835 |
It is important that content providers do not assign very low |
836 |
source quality values without good reason, as this would limit the |
837 |
ability of users to influence the negotiation process with their |
838 |
own preference settings. The following table SHOULD be used as a |
839 |
guide when assigning source quality values: |
840 |
|
841 |
1.000 perfect representation |
842 |
0.900 threshold of noticeable loss of quality |
843 |
0.800 noticeable, but acceptable quality reduction |
844 |
0.500 barely acceptable quality |
845 |
0.300 severely degraded quality |
846 |
0.000 completely degraded quality |
847 |
|
848 |
Note that most meaningful values in this table are close to 1. |
849 |
This is due to the fact that quality factors are generally combined |
850 |
by multiplying them, not by adding them. |
851 |
|
852 |
When assigning source-quality values, content providers MUST NOT |
853 |
account for the size of the variant and its impact on transmission |
854 |
and rendering delays. Any constant rendering delay for a |
855 |
particular media type (for example due to the startup time of a |
856 |
helper application) SHOULD be accounted for by the user agent, when |
857 |
assigning a quality factor to that media type. |
858 |
|
859 |
|
860 |
5.4 Type, charset, language, and length |
861 |
|
862 |
The type attribute of a variant description carries the same |
863 |
information as its Content-Type response header counterpart defined |
864 |
in [1], except for any charset information, which MUST be carried |
865 |
in the charset attribute. For, example, the header |
866 |
|
867 |
Content-Type: text/html; charset=ISO-8859-4 |
868 |
|
869 |
has the counterpart attributes |
870 |
|
871 |
{type text/html} {charset ISO-8859-4} |
872 |
|
873 |
The language and length attributes carry the same information as |
874 |
their Content-* response header counterparts in [1]. The length |
875 |
attribute, if present, MUST thus reflect the length of the variant |
876 |
alone, and not the total size of the variant and any objects |
877 |
inlined or embedded by the variant. |
878 |
|
879 |
Though all of these attributes are optional, it is often desirable |
880 |
to include as many attributes as possible, as this will increase |
881 |
the quality of the negotiation process. |
882 |
|
883 |
Note: A server is not required to maintain a one-to-one |
884 |
correspondence between the attributes in the variant description |
885 |
and the Content-* headers in the variant response. For example, |
886 |
if the variant description contains a language attribute, the |
887 |
response does not necessarily have to contain a Content-Language |
888 |
header. If a Content-Language header is present, it does not |
889 |
have to contain an exact copy of the information in the language |
890 |
attribute. |
891 |
|
892 |
|
893 |
5.5 Features |
894 |
|
895 |
The features attribute specifies how the presence or absence of |
896 |
particular feature tags in the user agent affects the overall |
897 |
quality of the variant. This attribute is covered in section 6.4. |
898 |
|
899 |
|
900 |
5.6 Description |
901 |
|
902 |
The description attribute gives a textual description of the |
903 |
variant. It can be included if the URI and normal attributes of a |
904 |
variant are considered too opaque to allow interpretation by the |
905 |
user. If a user agent is showing a menu of available variants |
906 |
compiled from a variant list, and if a variant has a description |
907 |
attribute, the user agent SHOULD show the description attribute of |
908 |
the variant instead of showing the normal attributes of the |
909 |
variant. |
910 |
|
911 |
|
912 |
5.7 Extension-attribute |
913 |
|
914 |
The extension-attribute allows future specifications to |
915 |
incrementally define new dimensions of negotiation, and eases |
916 |
content negotiation experiments. In experimental situations, |
917 |
servers MUST ONLY generate extension-attributes whose names start |
918 |
with "x-". User agents SHOULD ignore all extension attributes they |
919 |
do not recognize. Proxies MUST NOT run a remote variant selection |
920 |
algorithm if an unknown extension attribute is present in the |
921 |
variant list. |
922 |
|
923 |
|
924 |
6 Feature negotiation |
925 |
|
926 |
This section defines the feature negotiation mechanism. Feature |
927 |
negotiation has been introduced in section 4.8. Appendix 18 |
928 |
contains examples of feature negotiation. |
929 |
|
930 |
|
931 |
6.1 Feature tags |
932 |
|
933 |
A feature tag (ftag) identifies a capability of a user agent or a |
934 |
preference of a user. A feature is said to be `present' in a user |
935 |
agent if the corresponding capability is implemented, or if the |
936 |
user has expressed corresponding preference. |
937 |
|
938 |
ftag = 1*<any CHAR except CTLs or tspecials or "!"> |
939 |
|
940 |
tspecials = "(" | ")" | "<" | ">" | "@" |
941 |
| "," | ";" | ":" | "\" | <"> |
942 |
| "/" | "[" | "]" | "?" | "=" |
943 |
| "{" | "}" | SP | HT |
944 |
|
945 |
(tspecials definition reproduced from [1]) |
946 |
|
947 |
Examples are |
948 |
|
949 |
tables, fonts, blebber, wolx, screenwidth, colordepth |
950 |
|
951 |
An example of the use of feature tags in a variant description is: |
952 |
|
953 |
{"index.html" 1.0 {type text/html} {features tables frames}} |
954 |
|
955 |
Feature tags are case-insensitive. The definition of a feature tag |
956 |
may state that a feature tag, if present, can have associated with |
957 |
it one or more values which reflect a particular capability or |
958 |
preference. For example, a feature tag `paper' could be present |
959 |
with the values `A4' and `A5'. |
960 |
|
961 |
Note that context may determine whether a feature tag expresses a |
962 |
capability or a preference. The `textonly' tag is naturally |
963 |
present for a text-only user agent, but the user of a graphical |
964 |
user agent could set the tag to be present if text-only content is |
965 |
preferred to graphical content. |
966 |
|
967 |
As feature registration [4] will be an ongoing process, it is |
968 |
generally not possible for a user agent to know the meaning of all |
969 |
feature tags it can possibly encounter in a variant description. A |
970 |
user agent SHOULD treat all features with tags unknown to it as |
971 |
absent. |
972 |
|
973 |
|
974 |
6.2 Accept-Features header |
975 |
|
976 |
The Accept-Features request header can be used by a client to give |
977 |
information about the presence or absence of certain features. |
978 |
|
979 |
Accept-Features = "Accept-Features" ":" |
980 |
#( feature-expr *( ";" feature-extension ) ) |
981 |
|
982 |
feature-expr = [ "!" ] ftag |
983 |
| ftag [ "!" ] "=" tag-value |
984 |
| ftag "=" "{" tag-value "}" |
985 |
| ftag "<=" number |
986 |
| ftag "=" "<" numeric-range ">" |
987 |
| "*" |
988 |
|
989 |
tag-value = token | quoted-string |
990 |
|
991 |
numeric-range = [ number ] "-" [ number ] |
992 |
|
993 |
feature-extension = token [ "=" ( token | quoted-string ) ] |
994 |
|
995 |
Tag values MUST be compared case-insensitively, and a token value |
996 |
XYZ is equal to a quoted-string value "XYZ". No feature extensions |
997 |
are defined in this specification. An example is: |
998 |
|
999 |
Accept-Features: blex, !blebber, colordepth<=5, !screenwidth, |
1000 |
UA-media={stationary}, paper = a4, paper!="a0", |
1001 |
x_version=<100-205>, * |
1002 |
|
1003 |
The different feature expressions have the following meaning: |
1004 |
|
1005 |
ftag ftag is present |
1006 |
|
1007 |
!ftag ftag is absent |
1008 |
|
1009 |
ftag=V ftag is present with the value V (it may also be |
1010 |
present with other values) |
1011 |
|
1012 |
ftag!=V ftag is present, but not with the value V |
1013 |
|
1014 |
ftag={V} ftag is present with the value V, and not with any |
1015 |
other values |
1016 |
|
1017 |
ftag<=N ftag is present with the numeric values from 0 up to |
1018 |
and including N, and not with any other values |
1019 |
|
1020 |
ftag=<N-M> ftag is present with the numeric values from N up to |
1021 |
and including M, and not with any other values. If N |
1022 |
is missing, the lower bound is 0. If M is missing, |
1023 |
the upper bound is infinity. |
1024 |
|
1025 |
* makes true all feature predicates (section 6.3) which |
1026 |
were not assigned truth values by other elements of |
1027 |
the header |
1028 |
|
1029 |
Absence of the Accept-Features header in a request is equivalent to |
1030 |
the inclusion of |
1031 |
|
1032 |
Accept-Features: * |
1033 |
|
1034 |
|
1035 |
6.3 Feature predicates |
1036 |
|
1037 |
Feature predicates are used in the features attribute of a variant |
1038 |
description. |
1039 |
|
1040 |
fpred = [ "!" ] ftag |
1041 |
| ftag [ "!" ] "=" tag-value |
1042 |
| ftag "=" "<" numeric-range ">" |
1043 |
|
1044 |
Examples of feature predicates are |
1045 |
|
1046 |
blebber, !blebber, paper=a4, colordepth=5, blex!=54, |
1047 |
dpi=<300-599>, colordepth=<24-> |
1048 |
|
1049 |
A server can compute the truth value of a feature predicate by |
1050 |
using the knowledge gained from the Accept-Features header in the |
1051 |
current request. The truth value MUST be assigned as follows, |
1052 |
depending on the form of the predicate: |
1053 |
|
1054 |
ftag true if the feature is known to be present |
1055 |
|
1056 |
false if the feature is known to be absent |
1057 |
|
1058 |
!ftag true if the feature is known to be absent |
1059 |
|
1060 |
false if the feature is known to be present |
1061 |
|
1062 |
ftag=V true if the feature is known to be present with |
1063 |
the value V, |
1064 |
|
1065 |
false if the feature is known not to be present with |
1066 |
the value V |
1067 |
|
1068 |
ftag!=V true if the feature is known to be present, but known |
1069 |
not to be present with the value V, |
1070 |
|
1071 |
false if the feature is known to be absent or present |
1072 |
with the value V |
1073 |
|
1074 |
ftag=<N-M> true if the feature is known to be present with some |
1075 |
numeric values, while the highest value with which it |
1076 |
is present is known and in the range N-M, |
1077 |
|
1078 |
false if the feature is known to be absent, or if it |
1079 |
is known to be present with some numeric values, |
1080 |
while the highest value with which it is present is |
1081 |
known and not in the range N-M. |
1082 |
|
1083 |
If N is missing, the lower bound is 0. If M is |
1084 |
missing, the upper bound is infinity. |
1085 |
|
1086 |
If the information in the Accept-Features header does not provide |
1087 |
sufficient knowledge to assign a value to a predicate using the |
1088 |
above rules, then the value is true if there is a "*" in the |
1089 |
Accept-Features header, false otherwise. |
1090 |
|
1091 |
As an example, the header |
1092 |
|
1093 |
Accept-Features: blex, !blebber, colordepth<=5, !screenwidth, |
1094 |
UA-media={stationary}, paper = a4, paper!="a0", |
1095 |
x_version=<100-205>, * |
1096 |
|
1097 |
makes the following predicates true: |
1098 |
|
1099 |
blex, colordepth=4, colordepth!=6, colordepth, !screenwidth, |
1100 |
UA-media=stationary, !UA-media=screen, paper=a4, paper =!a0, |
1101 |
colordepth=< 4 - 6 >, x_version="101" |
1102 |
|
1103 |
The * in the header makes all of the following predicates true: |
1104 |
|
1105 |
blex=wox, blex!=wox, paper=a5, |
1106 |
frtnbf, !frtnbf, frtnbf=4, frtnbf!=4, frtnbf=<1-42> |
1107 |
|
1108 |
The header makes the following predicates false: |
1109 |
|
1110 |
!blex, blebber, colordepth=6, colordepth=foo, !colordepth, |
1111 |
screenwidth, screenwidth=640, screenwidth!=640, x_version=99, |
1112 |
UA-media=screen, paper=a0 |
1113 |
|
1114 |
|
1115 |
6.4 Features attribute |
1116 |
|
1117 |
The features attribute |
1118 |
|
1119 |
"{" "features" feature-list "}" |
1120 |
|
1121 |
is used in a variant description to specify how the presence or |
1122 |
absence of particular feature tags in the user agent affects the |
1123 |
overall quality of the variant. |
1124 |
|
1125 |
feature-list = 1%feature-list-element |
1126 |
|
1127 |
feature-list-element = ( fpred | fpred-bag ) |
1128 |
[ ":" true-improvement ] |
1129 |
[ "/" false-degradation ] |
1130 |
|
1131 |
fpred-bag = "[" 1%fpred "]" |
1132 |
|
1133 |
true-improvement = short-float |
1134 |
false-degradation = short-float |
1135 |
|
1136 |
Examples are: |
1137 |
|
1138 |
{features !textonly [blebber !wolx] colordepth=3:0.7} |
1139 |
|
1140 |
{features !blink/0.5 background:1.5 [blebber !wolx]:1.4/0.8} |
1141 |
|
1142 |
The default value for the true-improvement is 1. The default value |
1143 |
for the false-degradation is 0, or 1 if a true-improvement value is |
1144 |
given. |
1145 |
|
1146 |
A remote variant selection algorithm MUST compute the quality |
1147 |
degradation factor associated with the features attribute by |
1148 |
multiplying all quality degradation factors of the elements of the |
1149 |
feature-list. Note that the result can be a factor greater than 1. |
1150 |
|
1151 |
A feature list element yields its true-improvement factor if the |
1152 |
corresponding feature predicate is true, or if at least one element |
1153 |
of the corresponding fpred-bag is true. The element yields its |
1154 |
false-degradation factor otherwise. |
1155 |
|
1156 |
|
1157 |
7 Remote variant selection algorithms |
1158 |
|
1159 |
A remote variant selection algorithms is a standardized algorithm |
1160 |
by which a server can choose a best variant on behalf of a |
1161 |
negotiating user agent. The use of a remote algorithm can speed up |
1162 |
the negotiation process by eliminating a request-response round |
1163 |
trip. |
1164 |
|
1165 |
A remote algorithm typically computes whether the Accept- headers in |
1166 |
the request contain sufficient information to allow a choice, and |
1167 |
if so, which variant is the best variant. This specification does |
1168 |
not define any remote algorithms, but does define a mechanism to |
1169 |
negotiate on the use of such algorithms. |
1170 |
|
1171 |
|
1172 |
7.1 Version numbers |
1173 |
|
1174 |
A version numbering scheme is used to distinguish between different |
1175 |
remote variant selection algorithms. |
1176 |
|
1177 |
rvsa-version = major "." minor |
1178 |
|
1179 |
major = 1*4DIGIT |
1180 |
minor = 1*4DIGIT |
1181 |
|
1182 |
An algorithm with the version number X.Y, with Y>0, MUST be |
1183 |
downwards compatible with all algorithms from X.0 up to X.Y. |
1184 |
Downwards compatibility means that, if supplied with the same |
1185 |
information, the newer algorithm MUST make the same choice, or a |
1186 |
better choice, as the old algorithm. There are no compatibility |
1187 |
requirements between algorithms with different major version |
1188 |
numbers. |
1189 |
|
1190 |
|
1191 |
8 Content negotiation status codes and headers |
1192 |
|
1193 |
This specification adds one new HTTP status code, and introduces |
1194 |
six new HTTP headers. It also extends the semantics of an existing |
1195 |
HTTP/1.1 header. |
1196 |
|
1197 |
|
1198 |
8.1 506 Variant Also Negotiates |
1199 |
|
1200 |
The 506 status code indicates that the server has an internal |
1201 |
configuration error: the chosen variant resource is configured to |
1202 |
engage in transparent content negotiation itself, and is therefore |
1203 |
not a proper end point in the negotiation process. |
1204 |
|
1205 |
|
1206 |
8.2 Accept-Charset |
1207 |
|
1208 |
The Accept-Charset header is defined in the HTTP/1.1 specification |
1209 |
[1]. HTTP/1.1 allows the following Accept-Charset header to be |
1210 |
sent: |
1211 |
|
1212 |
Accept-Charset: iso-8859-5;q=0.8, *;q=0.9 |
1213 |
|
1214 |
but HTTP/1.1 does not assign any special meaning to the charset |
1215 |
"*". |
1216 |
|
1217 |
This specification does assign a special meaning: servers and |
1218 |
clients which support transparent content negotiation MUST take "*" |
1219 |
as a wildcard matching every character set not explicitly mentioned |
1220 |
elsewhere in the Accept-Charset header. As an example, the above |
1221 |
header assigns a quality value of 0.9 to the iso-8859-2 charset. |
1222 |
|
1223 |
If no "*" is present in an Accept-Charset header, then all |
1224 |
character sets not explicitly mentioned get a quality factor of 0, |
1225 |
except for ISO-8859-1, which gets a quality factor of 1 if not |
1226 |
explicitly mentioned. |
1227 |
|
1228 |
Note: The omission of a wildcard from the Accept-Charset |
1229 |
header in [1] is believed to be due to an oversight during the |
1230 |
design of HTTP/1.1. A future revision of [1] may correct this |
1231 |
oversight, and make this section redundant. |
1232 |
|
1233 |
|
1234 |
8.3 Accept-Features |
1235 |
|
1236 |
This request header was defined in section 6.2. |
1237 |
|
1238 |
|
1239 |
8.4 Alternates |
1240 |
|
1241 |
The Alternates response header is used to convey the list of |
1242 |
variants bound to a negotiable resource. This list can also |
1243 |
include directives for any content negotiation process. |
1244 |
|
1245 |
Alternates = "Alternates" ":" variant-list |
1246 |
|
1247 |
variant-list = 1#( variant-description |
1248 |
| fallback-variant |
1249 |
| list-directive ) |
1250 |
|
1251 |
fallback-variant = "{" <"> URI <"> "}" |
1252 |
|
1253 |
list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> ) |
1254 |
| extension-list-directive |
1255 |
|
1256 |
extension-list-directive = token [ "=" ( token | quoted-string ) ] |
1257 |
|
1258 |
An example is |
1259 |
|
1260 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1261 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1262 |
{"paper.ps.en" 1.0 {type application/postscript} |
1263 |
{language en}}, |
1264 |
proxy-rvsa="1.0, 2.5" |
1265 |
|
1266 |
Any relative URI specified in a variant-description or |
1267 |
fallback-variant field is relative to the request-URI. Only one |
1268 |
fallback-variant field may be present. If the variant selection |
1269 |
algorithm of the user agent finds that all described variants are |
1270 |
unacceptable, then it SHOULD choose the fallback variant, if |
1271 |
present, as the best variant. If the user agent computes the |
1272 |
overall quality values of the described variants, and finds that |
1273 |
several variants share the highest value, then the first variant |
1274 |
with this value in the list SHOULD be chosen as the best variant. |
1275 |
|
1276 |
The proxy-rvsa directive restricts the use of remote variant |
1277 |
selection algorithms by proxies. If present, a proxy MUST ONLY use |
1278 |
algorithms which have one of the version numbers listed, or have |
1279 |
the same major version number and a higher minor version number as |
1280 |
one of the versions listed. Any restrictions set by proxy-rvsa |
1281 |
come on top of the restrictions set by the user agent in the |
1282 |
Negotiate request header. The directive proxy-rvsa="" will disable |
1283 |
variant selection by proxies entirely. Clients SHOULD ignore all |
1284 |
extension-list-directives they do not understand. |
1285 |
|
1286 |
A variant list may contain multiple differing descriptions of the |
1287 |
same variant. This can be convenient if the variant uses |
1288 |
conditional rendering constructs, or if the variant resource |
1289 |
returns multiple representations using a multipart media type. |
1290 |
|
1291 |
|
1292 |
8.5 Content-Features |
1293 |
|
1294 |
The Content-Features response header can be used by a server to |
1295 |
indicate how the presence or absence of particular feature tags in |
1296 |
the user agent affects the overall quality of the response. |
1297 |
|
1298 |
Content-Features = "Content-Features" ":" feature-list |
1299 |
|
1300 |
Note: This header mainly exists because of symmetry |
1301 |
considerations. It is the counterpart of the features attribute |
1302 |
which can be present in variant descriptions. If present in a |
1303 |
response, the header will therefore not in general specify all |
1304 |
user agent capabilities used by the response. |
1305 |
|
1306 |
|
1307 |
8.6 Negotiate |
1308 |
|
1309 |
The Negotiate request header can contain directives for any content |
1310 |
negotiation process initiated by the request. |
1311 |
|
1312 |
Negotiate = "Negotiate" ":" 1#negotiate-directive |
1313 |
|
1314 |
negotiate-directive = "trans" | rvsa-version | "*" |
1315 |
| negotiate-extension |
1316 |
|
1317 |
negotiate-extension = token [ "=" token ] |
1318 |
|
1319 |
Examples are |
1320 |
|
1321 |
Negotiate: 1.0, 2.5 |
1322 |
Negotiate: * |
1323 |
|
1324 |
The negotiate directives have the following meaning |
1325 |
|
1326 |
"trans" |
1327 |
The user agent supports transparent content negotiation for |
1328 |
the current request. |
1329 |
|
1330 |
rvsa-version |
1331 |
The user agent allows origin servers and proxies to run the |
1332 |
remote variant selection algorithm with the indicated version |
1333 |
number, or with the same major version number and a higher |
1334 |
minor version number. If the algorithm has sufficient |
1335 |
information to choose a best, neighboring variant, the origin |
1336 |
server or proxy MAY return a choice response with this |
1337 |
variant. Implies "trans". |
1338 |
|
1339 |
"*" |
1340 |
The user agent allows origin servers and proxies to run any |
1341 |
remote variant selection algorithm. The origin server may |
1342 |
even run algorithms which have not been standardized. If the |
1343 |
algorithm has sufficient information to choose a best, |
1344 |
neighboring variant, the origin server or proxy MAY return a |
1345 |
choice response with this variant. Implies "trans". |
1346 |
|
1347 |
Servers SHOULD ignore all negotiate-directives they do not |
1348 |
understand. If the Negotiate header allows a choice between |
1349 |
multiple remote variant selection algorithms which are all |
1350 |
supported by the server, the server SHOULD use some internal |
1351 |
precedence heuristics to select the best algorithm. |
1352 |
|
1353 |
|
1354 |
8.7 TCN |
1355 |
|
1356 |
The TCN response header is used by a server to signal that the |
1357 |
resource is transparently negotiated. |
1358 |
|
1359 |
TCN = "TCN" ":" #( response-type | tcn-extension ) |
1360 |
|
1361 |
response-type = "list" | "choice" | "adhoc" |
1362 |
|
1363 |
tcn-extension = token [ "=" ( token | quoted-string ) ] |
1364 |
|
1365 |
If the resource is not transparently negotiated, a TCN header MUST |
1366 |
NEVER be included in any response. If the resource is |
1367 |
transparently negotiated, a TCN header, which includes the |
1368 |
response-type value of the response, MUST be included in every |
1369 |
response with a 2xx status code or any 3xx status code, except 304, |
1370 |
in which it MAY be included. A TCN header MAY also be included, |
1371 |
without a response-type value, in other responses from |
1372 |
transparently negotiated resources. |
1373 |
|
1374 |
Clients SHOULD ignore all tcn-extensions they do not understand. |
1375 |
|
1376 |
|
1377 |
8.8 Variant-Vary |
1378 |
|
1379 |
The Variant-Vary response header can be used in a choice response |
1380 |
to record any vary information which applies to the variant data |
1381 |
(the entity body combined with some of the entity headers) |
1382 |
contained in the response, rather than to the response as a whole. |
1383 |
|
1384 |
Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name ) |
1385 |
|
1386 |
Use of the Variant-Vary header is discussed in section 10.2. |
1387 |
|
1388 |
|
1389 |
9 Cache validators |
1390 |
|
1391 |
To allow for correct and efficient caching and revalidation of |
1392 |
negotiated responses, this specification extends the caching model |
1393 |
of HTTP/1.1 [1] in various ways. |
1394 |
|
1395 |
This specification does not introduce a `variant-list-max-age' |
1396 |
directive which explicitly bounds the freshness lifetime of a |
1397 |
cached variant list, like the `max-age' Cache-Control directive |
1398 |
bounds the freshness lifetime of a cached response. However, this |
1399 |
specification does ensure that a variant list which is sent at a |
1400 |
time T by the origin server will never be re-used without |
1401 |
revalidation by semantically transparent caches after the time T+M. |
1402 |
This M is the maximum of all freshness lifetimes assigned (using |
1403 |
max-age directives or Expires headers) by the origin server to |
1404 |
|
1405 |
a. the responses from the negotiable resource itself, and |
1406 |
|
1407 |
b. the responses from its neighboring variant resources |
1408 |
|
1409 |
If no freshness lifetimes are assigned by the origin server, M is |
1410 |
the maximum of the freshness lifetimes which were heuristically |
1411 |
assigned by all caches which can re-use the variant list. |
1412 |
|
1413 |
|
1414 |
9.1 Variant list validators |
1415 |
|
1416 |
A variant list validator is an opaque value which acts as the cache |
1417 |
validator of a variant list bound to a negotiable resource. |
1418 |
|
1419 |
variant-list-validator = <quoted-string not containing any ";"> |
1420 |
|
1421 |
If two responses contain the same variant list validator, a cache |
1422 |
can treat the Alternates headers in these responses as equivalent |
1423 |
(though the headers themselves need not be identical). |
1424 |
|
1425 |
|
1426 |
9.2 Structured entity tags |
1427 |
|
1428 |
A structured entity tag consists of a normal entity tag of which |
1429 |
the opaque string is extended with a semicolon followed by the text |
1430 |
(without the surrounding quotes) of a variant list validator: |
1431 |
|
1432 |
normal | variant list | structured |
1433 |
entity tag | validator | entity tag |
1434 |
-------------+----------------+----------------- |
1435 |
"etag" | "vlv" | "etag;vlv" |
1436 |
W/"etag" | "vlv" | W/"etag;vlv" |
1437 |
|
1438 |
Note that a structured entity tag is itself also an entity tag. |
1439 |
The structured nature of the tag allows caching proxies capable of |
1440 |
transparent content negotiation to perform some optimizations |
1441 |
defined in section 10. When not performing such optimizations, a |
1442 |
structured tag SHOULD be treated as a single opaque value, |
1443 |
according to the general rules in HTTP/1.1. Examples of structured |
1444 |
entity tags are: |
1445 |
|
1446 |
"xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234" |
1447 |
|
1448 |
In the last example, the normal entity tag is "a;b;c;" and the |
1449 |
variant list validator is "1234". |
1450 |
|
1451 |
If a transparently negotiated response includes an entity tag, it |
1452 |
MUST be a structured entity tag. The variant list validator in the |
1453 |
structured tag MUST act as a validator for the variant list |
1454 |
contained in the Alternates header. The normal entity tag in the |
1455 |
structured tag MUST act as a validator of the entity body in the |
1456 |
response and of all entity headers except Alternates. |
1457 |
|
1458 |
|
1459 |
9.3 Assigning entity tags to variants |
1460 |
|
1461 |
To allow for correct revalidation of transparently negotiated |
1462 |
responses by clients, origin servers SHOULD generate all normal |
1463 |
entity tags for the neighboring variant resources of the negotiable |
1464 |
resource in such a way that |
1465 |
|
1466 |
1. the same tag is never used by two different variants, |
1467 |
unless this tag labels exactly the same entity on all |
1468 |
occasions, |
1469 |
|
1470 |
2. if one normal tag "X" is a prefix of another normal tag "XY", |
1471 |
then "Y" must never be a semicolon followed by a variant list |
1472 |
validator. |
1473 |
|
1474 |
|
1475 |
10 Content negotiation responses |
1476 |
|
1477 |
If a request on a transparently negotiated resource yields a |
1478 |
response with a 2xx status code or any 3xx status code except 304, |
1479 |
this response MUST always be either a list response, a choice |
1480 |
response, or an ad hoc response. These responses always include |
1481 |
the Alternates header bound to the negotiable resource, and a TCN |
1482 |
header which specifies their type. Transparently negotiated |
1483 |
responses with other status codes MAY also include an Alternates |
1484 |
header. |
1485 |
|
1486 |
After having constructed a list, choice, or ad hoc response, a |
1487 |
server MAY process any If-No-Match or If-Range headers in the |
1488 |
request message and shorten the response to a 304 (Not Modified) or |
1489 |
206 (Partial Content) response, following the rules in the HTTP/1.1 |
1490 |
specification [1]. In this case, the entity tag of the shortened |
1491 |
response will identify it indirectly as a list, choice, or ad-hoc |
1492 |
response. |
1493 |
|
1494 |
|
1495 |
10.1 List response |
1496 |
|
1497 |
A list response MUST contain (besides the normal headers required |
1498 |
by HTTP) a TCN header which specifies the "list" response-type, the |
1499 |
Alternates header bound to the negotiable resource, a Vary header |
1500 |
and (unless it was a HEAD request) an entity body which allows the |
1501 |
user to manually select the best variant. It is generated as a |
1502 |
response to a user agent which supports transparent content |
1503 |
negotiation if the server does not, cannot, or is not allowed to |
1504 |
choose a particular best variant for the request. |
1505 |
|
1506 |
An example of a list response is |
1507 |
|
1508 |
HTTP/1.1 300 Multiple Choices |
1509 |
Date: Tue, 11 Jun 1996 20:02:21 GMT |
1510 |
TCN: list |
1511 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1512 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1513 |
{"paper.ps.en" 1.0 {type application/postscript} |
1514 |
{language en}} |
1515 |
Vary: negotiate, accept, accept-language |
1516 |
ETag: "blah;1234" |
1517 |
Cache-control: max-age=86400 |
1518 |
Content-Type: text/html |
1519 |
Content-Length: 227 |
1520 |
|
1521 |
<h2>Multiple Choices:</h2> |
1522 |
<ul> |
1523 |
<li><a href=paper.html.en>HTML, English version</a> |
1524 |
<li><a href=paper.html.fr>HTML, French version</a> |
1525 |
<li><a href=paper.ps.en>Postscript, English version</a> |
1526 |
</ul> |
1527 |
|
1528 |
Note: A list response can have any status code, but the 300 |
1529 |
(Multiple Choices) code is the most appropriate one for HTTP/1.1 |
1530 |
clients. Some existing versions of HTTP/1.0 clients are known |
1531 |
to silently ignore 300 responses, instead of handling them |
1532 |
according to the HTTP/1.0 specification [3]. Servers should |
1533 |
therefore be careful in sending 300 responses to non-negotiating |
1534 |
HTTP/1.0 user agents, and in making these responses cacheable. |
1535 |
The 200 (OK) status code can be used instead. |
1536 |
|
1537 |
The Vary header in the response SHOULD ensure correct handling by |
1538 |
plain HTTP/1.1 caching proxies. This header can either be |
1539 |
|
1540 |
Vary: * |
1541 |
|
1542 |
or a more elaborate header; see section 10.6.1. |
1543 |
|
1544 |
Only the origin server may construct list responses. Depending on |
1545 |
the status code, a list response is cacheable unless indicated |
1546 |
otherwise. |
1547 |
|
1548 |
According to the HTTP/1.1 specification [1], a user agent which |
1549 |
does not support transparent content negotiation will, when |
1550 |
receiving a list response, display the entity body included in the |
1551 |
response. If the response contains a Location header, however, the |
1552 |
user agent MAY automatically redirect to this location. |
1553 |
|
1554 |
The handling of list responses by clients supporting transparent |
1555 |
content negotiation is described in sections 11.1 and 13. |
1556 |
|
1557 |
|
1558 |
10.2 Choice response |
1559 |
|
1560 |
A choice response merges a normal HTTP response from the chosen |
1561 |
variant, a TCN header which specifies the "choice" response-type, a |
1562 |
Content-Location header giving the location of the variant, and the |
1563 |
Alternates headers bound to the negotiable resource. It can be |
1564 |
generated when the server has sufficient information to be able to |
1565 |
choose the best variant on behalf the user agent, but may only be |
1566 |
generated if this best variant is a neighboring variant. Depending |
1567 |
on the status code, a choice response is cacheable unless indicated |
1568 |
otherwise. |
1569 |
|
1570 |
Origin servers and proxy caches MUST construct choice responses |
1571 |
with the following algorithm (or any other algorithm which gives |
1572 |
equal end results for the client). |
1573 |
|
1574 |
In this algorithm, `the current Alternates header' refers to the |
1575 |
Alternates header containing the variant list which was used to |
1576 |
choose the best variant, and `the current variant list validator' |
1577 |
refers to the validator of this list. Section 10.4 specifies how |
1578 |
these two items can be obtained by a proxy cache. |
1579 |
|
1580 |
The algorithm consists of four steps. |
1581 |
|
1582 |
1. Construct a HTTP request message on the best variant resource |
1583 |
by rewriting the request-URI and Host header (if appropriate) |
1584 |
of the received request message on the negotiable resource. |
1585 |
|
1586 |
2. Generate a valid HTTP response message, but not one with the |
1587 |
304 (Not Modified) code, for the request message constructed |
1588 |
in step 1. |
1589 |
|
1590 |
In a proxy cache, the response can be obtained from cache |
1591 |
memory, or by passing the constructed HTTP request towards the |
1592 |
origin server. If the request is passed on, the proxy MAY |
1593 |
add, modify, or delete If-None-Match and If-Range headers to |
1594 |
optimize the transaction with the upstream server. |
1595 |
|
1596 |
Note: the proxy should be careful not to add entity tags of |
1597 |
non-neighboring variants to If-* (conditional) headers of |
1598 |
the request, as there are no global uniqueness requirements |
1599 |
for these tags. |
1600 |
|
1601 |
3. Only in origin servers: check for an origin server |
1602 |
configuration error. If the HTTP response message generated in |
1603 |
step 2 contains a TCN header, then the best variant resource |
1604 |
is not a proper end point in the transparent negotiation |
1605 |
process, and a 506 (Variant Also Negotiates) error response |
1606 |
message SHOULD be generated instead of going to step 4. |
1607 |
|
1608 |
4. Add a number of headers to the HTTP response message generated |
1609 |
in step 2. |
1610 |
|
1611 |
a. Add a TCN header which specifies the "choice" |
1612 |
response-type. |
1613 |
|
1614 |
b. Add a Content-Location header giving the location of the |
1615 |
chosen variant. Delete any Content-Location header which |
1616 |
was already present. |
1617 |
|
1618 |
Note: According to the HTTP/1.1 specification [1], if |
1619 |
the Content-Location header contains a relative URI, |
1620 |
this URI is relative to the URI in the Content-Base |
1621 |
header, if present, and relative to the request-URI if |
1622 |
no Content-Base header is present. |
1623 |
|
1624 |
c. If any Vary headers are present in the response message |
1625 |
from step 2, add, for every Vary header, a Variant-Vary |
1626 |
header with a copy of the contents of this Vary header. |
1627 |
|
1628 |
d. Add the current Alternates header. Delete any |
1629 |
Alternates header which was already present. |
1630 |
|
1631 |
e. Add a Vary header to ensure correct handling by plain |
1632 |
HTTP/1.1 caching proxies. This header can either be |
1633 |
|
1634 |
Vary: * |
1635 |
|
1636 |
or a more elaborate header, see section 10.6. |
1637 |
|
1638 |
f. To ensure compatibility with HTTP/1.0 caching proxies which |
1639 |
do not recognize the Vary header, an Expires header with a |
1640 |
date in the past MAY be added. See section 10.7 for more |
1641 |
information. |
1642 |
|
1643 |
g. If an ETag header is present in the response message from |
1644 |
step 2, then extend the entity tag in that header with the |
1645 |
current variant list validator, as specified in section |
1646 |
9.2. |
1647 |
|
1648 |
f. Only in proxy caches: set the Age header of the response to |
1649 |
|
1650 |
max( variant_age , alternates_age ) |
1651 |
|
1652 |
where variant_age is the age of the variant response |
1653 |
obtained in step 2, calculated according to the rules in |
1654 |
the HTTP/1.1 specification [1], and alternates_age is the |
1655 |
age of the Alternates header added in step d, calculated |
1656 |
according to the rules in section 10.4. |
1657 |
|
1658 |
Note that a server can shorten the response produced by the above |
1659 |
algorithm to a 304 (Not Modified) response if an If-None-Match |
1660 |
header in the original request allows it. If this is the case, an |
1661 |
implementation of the above algorithm can avoid the unnecessary |
1662 |
internal construction of full response message in step 2, it need |
1663 |
only construct the parts which end up in the final 304 response. A |
1664 |
proxy cache which implements this optimization can sometimes |
1665 |
generate a legal 304 response even if it has not cached the variant |
1666 |
data itself. |
1667 |
|
1668 |
An example of a choice response is: |
1669 |
|
1670 |
HTTP/1.1 200 OK |
1671 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
1672 |
TCN: choice |
1673 |
Content-Type: text/html |
1674 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
1675 |
Content-Length: 5327 |
1676 |
Cache-control: max-age=604800 |
1677 |
Content-Location: paper.html.en |
1678 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1679 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1680 |
{"paper.ps.en" 1.0 {type application/postscript} |
1681 |
{language en}} |
1682 |
Etag: "gonkyyyy;1234" |
1683 |
Vary: negotiate, accept, accept-language |
1684 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
1685 |
|
1686 |
<title>A paper about .... |
1687 |
|
1688 |
|
1689 |
10.3 Ad hoc response |
1690 |
|
1691 |
An ad hoc response has a TCN header which specifies the "adhoc" |
1692 |
response-type. It MUST contain the Alternates header bound to the |
1693 |
negotiable resource, and a Vary header if the response is |
1694 |
cacheable. It MAY be generated by an origin server as a response |
1695 |
to a non-negotiating user agent, if the server cannot or does not |
1696 |
want to send a list or choice response. |
1697 |
|
1698 |
The Vary header in the response SHOULD ensure correct handling by |
1699 |
plain HTTP/1.1 caching proxies. This header can either be |
1700 |
|
1701 |
Vary: * |
1702 |
|
1703 |
or a more elaborate header, see section 10.6.1. Depending on the |
1704 |
status code, an ad hoc response is cacheable unless indicated |
1705 |
otherwise. |
1706 |
|
1707 |
An example of an ad hoc response is: |
1708 |
|
1709 |
HTTP/1.1 302 Moved Temporarily |
1710 |
Date: Tue, 11 Jun 1996 20:02:28 GMT |
1711 |
TCN: adhoc |
1712 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1713 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1714 |
{"paper.ps.en" 1.0 {type application/postscript} |
1715 |
{language en}} |
1716 |
Location: paper.html.en |
1717 |
Content-Type: text/html |
1718 |
Content-Length: 59 |
1719 |
|
1720 |
This document is available <a href=paper.html.en>here</a>. |
1721 |
|
1722 |
|
1723 |
10.4 Reusing the Alternates header |
1724 |
|
1725 |
If a proxy cache has available a negotiated response which is |
1726 |
cacheable, fresh, and has an ETag header, then it MAY extract the |
1727 |
Alternates header and associated variant list validator from the |
1728 |
response, and reuse them (without unnecessary delay) to negotiate |
1729 |
on behalf of the user agent (section 13) or to construct a choice |
1730 |
response (section 10.2). The age of the extracted Alternates |
1731 |
header is the age of the response from which it is extracted, |
1732 |
calculated according to the rules in the HTTP/1.1 specification |
1733 |
[1]. |
1734 |
|
1735 |
|
1736 |
10.5 Extracting a normal response from a choice response |
1737 |
|
1738 |
If a proxy receives a choice response, it MAY extract and cache the |
1739 |
normal HTTP response contained therein. The normal response can be |
1740 |
extracted by taking a copy of the choice response and then deleting |
1741 |
the Content-Location, Alternates, and Vary headers, renaming any |
1742 |
Variant-Vary headers to Vary headers, and shortening the structured |
1743 |
entity tag in any ETag header to a normal entity tag. |
1744 |
|
1745 |
This normal response MAY be cached (as a HTTP response to the |
1746 |
variant request as constructed in step 1. of section 10.2) and |
1747 |
reused to answer future direct requests on the variant resource, |
1748 |
according to the rules in the HTTP/1.1 specification [1]. |
1749 |
|
1750 |
Note: The caching of extracted responses can decrease the |
1751 |
upstream bandwidth usage with up to a factor 2, because two |
1752 |
independent HTTP/1.1 cache entries, one associated with the |
1753 |
negotiable resource URI and one with the variant URI, are |
1754 |
created in the same transaction. Without this optimization, |
1755 |
both HTTP/1.1 cache entries can only be created by transmitting |
1756 |
the variant data twice. |
1757 |
|
1758 |
For security reasons (see section 14.2), an extracted normal |
1759 |
response MUST NEVER be cached if belongs to a non-neighboring |
1760 |
variant resource. If the choice response claims to contain data |
1761 |
for a non-neighboring variant resource, the proxy SHOULD reject the |
1762 |
choice response as a probable spoofing attempt. |
1763 |
|
1764 |
|
1765 |
10.6 Elaborate Vary headers |
1766 |
|
1767 |
If a HTTP/1.1 [1] server can generate varying responses for a |
1768 |
request on some resource, then the server MUST include a Vary |
1769 |
header in these responses if they are cacheable. This Vary header |
1770 |
is a signal to HTTP/1.1 caches that something special is going on. |
1771 |
It prevents the caches from returning the currently chosen response |
1772 |
for every future request on the resource. |
1773 |
|
1774 |
Servers engaging in transparent content negotiation will generate |
1775 |
varying responses. Therefore, cacheable list, choice, and ad hoc |
1776 |
responses MUST always include a Vary header. |
1777 |
|
1778 |
The most simple Vary header which can be included is |
1779 |
|
1780 |
Vary: * |
1781 |
|
1782 |
This header leaves the way in which the response is selected by the |
1783 |
server completely unspecified. |
1784 |
|
1785 |
A more elaborate Vary header MAY be used to allow for certain |
1786 |
optimizations in HTTP/1.1 caches which do not have specific |
1787 |
optimizations for transparent content negotiation, but which do |
1788 |
cache multiple variant responses for one resource. Such a more |
1789 |
elaborate Vary header lists all request headers which can be used |
1790 |
by the server when selecting a response for a request on the |
1791 |
resource. |
1792 |
|
1793 |
10.6.1 Construction of an elaborate Vary header |
1794 |
|
1795 |
Origin servers can construct a more elaborate Vary header in the |
1796 |
following way. First, start with the header |
1797 |
|
1798 |
Vary: negotiate |
1799 |
|
1800 |
`negotiate' is always included because servers use the information |
1801 |
in the Negotiate header when choosing between a list, choice, or |
1802 |
ad-hoc response. |
1803 |
|
1804 |
Then, if any of the following attributes is present in any variant |
1805 |
description in the Alternates header, add the corresponding header |
1806 |
name to the Vary header |
1807 |
|
1808 |
attribute | header name to add |
1809 |
-----------+--------------------- |
1810 |
type | accept |
1811 |
charset | accept-charset |
1812 |
language | accept-language |
1813 |
features | accept-features |
1814 |
|
1815 |
The Vary header constructed in this way specifies the response |
1816 |
variation which can be caused by the use of a variant selection |
1817 |
algorithm in proxies. If the origin server will in some cases, for |
1818 |
example if contacted by a non-negotiating user agent, use a custom |
1819 |
negotiation algorithm which takes additional headers into account, |
1820 |
these names of these headers SHOULD also be added to the Vary |
1821 |
header. |
1822 |
|
1823 |
10.6.2 Caching of an elaborate Vary header |
1824 |
|
1825 |
A proxy cache cannot construct an elaborate vary header using the |
1826 |
method above, because this method requires exact knowledge of any |
1827 |
custom algorithms present in the origin server. However, when |
1828 |
extracting an Alternates header from a response (section 10.4) |
1829 |
caches MAY also extract the Vary header in the response, and reuse |
1830 |
it along with the Alternates header. A clean Vary header can |
1831 |
however only be extracted if the variant does not vary itself, |
1832 |
i.e. if a Variant-Vary header is absent. |
1833 |
|
1834 |
|
1835 |
10.7 Adding an Expires header to ensure HTTP/1.0 compatibility |
1836 |
|
1837 |
To ensure compatibility with HTTP/1.0 caching proxies which do not |
1838 |
recognize the Vary header, an Expires header with a date in the |
1839 |
past can be added to the response, for example |
1840 |
|
1841 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
1842 |
|
1843 |
If this is done by an origin server, the server SHOULD usually also |
1844 |
include a Cache-Control header for the benefit of HTTP/1.1 caches, |
1845 |
for example |
1846 |
|
1847 |
Cache-Control: max-age=604800 |
1848 |
|
1849 |
which overrides the freshness lifetime of zero seconds specified by |
1850 |
the included Expires header. |
1851 |
|
1852 |
Note: This specification only claims downwards compatibility |
1853 |
with the HTTP/1.0 proxy caches which implement the HTTP/1.0 |
1854 |
specification [3]. Some legacy proxy caches which return the |
1855 |
HTTP/1.0 protocol version number do not honor the HTTP/1.0 |
1856 |
Expires header as specified in [3]. Methods for achieving |
1857 |
compatibility with such proxy caches are beyond the scope of |
1858 |
this specification. |
1859 |
|
1860 |
|
1861 |
10.8 Negotiation on content encoding |
1862 |
|
1863 |
Negotiation on the content encoding of a response is orthogonal to |
1864 |
transparent content negotiation. The rules for when a content |
1865 |
encoding may be applied are the same as in HTTP/1.1: servers MAY |
1866 |
content-encode responses that are the result of transparent content |
1867 |
negotiation whenever an Accept-Encoding header in the request |
1868 |
allows it. When negotiating on the content encoding of a cacheable |
1869 |
response, servers MUST add the accept-encoding header name to the |
1870 |
Vary header of the response, or add `Vary: *'. |
1871 |
|
1872 |
Servers SHOULD always be able to provide unencoded versions of |
1873 |
every transparently negotiated response. This means in particular |
1874 |
that every variant in the variant list SHOULD at least be available |
1875 |
in an unencoded form. |
1876 |
|
1877 |
Like HTTP/1.1, this specification allows proxies to encode or |
1878 |
decode relayed or cached responses on the fly, unless explicitly |
1879 |
forbidden by a Cache-Control directive. The encoded or decoded |
1880 |
response still contains the same variant as far as transparent |
1881 |
content negotiation is concerned. Note that HTTP/1.1 requires |
1882 |
proxies to add a Warning header if the encoding of a response is |
1883 |
changed. |
1884 |
|
1885 |
|
1886 |
11 User agent support for transparent negotiation |
1887 |
|
1888 |
This section specifies the requirements a user agent needs to |
1889 |
satisfy in order to support transparent negotiation. If the user |
1890 |
agent contains an internal cache, this cache MUST conform to the |
1891 |
rules for proxy caches in section 13. |
1892 |
|
1893 |
|
1894 |
11.1 Handling of responses |
1895 |
|
1896 |
If a list response is received when a resource is accessed, the |
1897 |
user agent MUST be able to automatically choose, retrieve, and |
1898 |
display the best variant, or display an error message if none of |
1899 |
the variants are acceptable. |
1900 |
|
1901 |
If a choice response is received when a resource is accessed, the |
1902 |
usual action is to automatically display the enclosed entity. |
1903 |
However, if a remote variant selection algorithm which was enabled |
1904 |
could have made a choice different from the choice the local |
1905 |
algorithm would make, the user agent MAY apply its local algorithm |
1906 |
to the variant list in the response, and automatically retrieve and |
1907 |
display another variant if the local algorithm makes an other |
1908 |
choice. |
1909 |
|
1910 |
When receiving a choice response, a user agent SHOULD check if |
1911 |
variant resource is a neighboring variant resource of the |
1912 |
negotiable resource. If this is not the case, the user agent |
1913 |
SHOULD reject the choice response as a probable spoofing attempt |
1914 |
and display an error message, for example by internally replacing |
1915 |
the choice response with a 502 (bad gateway) response. |
1916 |
|
1917 |
|
1918 |
11.2 Presentation of a transparently negotiated resource |
1919 |
|
1920 |
If the user agent is displaying a variant which is not an embedded |
1921 |
or inlined object and which is the result of transparent |
1922 |
negotiation, the following requirements apply. |
1923 |
|
1924 |
1. The user agent SHOULD allow the user to review a list of all |
1925 |
variants bound to the negotiable resource, and to manually |
1926 |
retrieve another variant if desired. There are two general |
1927 |
ways of providing such a list. First, the information in the |
1928 |
Alternates header of the negotiable resource could be used to |
1929 |
make an annotated menu of variants. Second, the entity |
1930 |
included in a list response of the negotiable resource could be |
1931 |
displayed. Note that a list response can be obtained by doing |
1932 |
a GET request which only has the "trans" directive in the |
1933 |
Negotiate header. |
1934 |
|
1935 |
2. The user agent SHOULD make available though its user interface |
1936 |
some indication that the resource being displayed is a |
1937 |
negotiated resource instead of a plain resource. It SHOULD |
1938 |
also allow the user to examine the variant list included in the |
1939 |
Alternates header. Such a notification and review mechanism is |
1940 |
needed because of privacy considerations, see section 14.1. |
1941 |
|
1942 |
3. If the user agent shows the URI of the displayed information to |
1943 |
the user, it SHOULD be the negotiable resource URI, not the |
1944 |
variant URI that is shown. This encourages third parties, who |
1945 |
want to refer to the displayed information in their own |
1946 |
documents, to make a hyperlink to the negotiable resource as a |
1947 |
whole, rather than to the variant resource which happens to be |
1948 |
shown. Such correct linking is vital for the interoperability |
1949 |
of content across sites. The user agent SHOULD however also |
1950 |
provide a means for reviewing the URI of the particular variant |
1951 |
which is currently being displayed. |
1952 |
|
1953 |
4. Similarly, if the user agent stores a reference to the |
1954 |
displayed information for future use, for example in a hotlist, |
1955 |
it SHOULD store the negotiable resource URI, not the |
1956 |
variant URI. |
1957 |
|
1958 |
It is encouraged, but not required, that some of the above |
1959 |
functionality is also made available for inlined or embedded |
1960 |
objects, and when a variant which was selected manually is being |
1961 |
displayed. |
1962 |
|
1963 |
|
1964 |
12 Origin server support for transparent negotiation |
1965 |
|
1966 |
12.1 Requirements |
1967 |
|
1968 |
To implement transparent negotiation on a resource, the origin |
1969 |
server MUST be able to send a list response when getting a GET |
1970 |
request on the resource. It SHOULD also be able to send |
1971 |
appropriate list responses for HEAD requests. A list response MUST |
1972 |
ALWAYS be sent if the request includes a Negotiate header with only |
1973 |
a "trans" directive. If the Negotiate header allows it, the origin |
1974 |
server MAY run a remote variant selection algorithm. If the |
1975 |
algorithm has sufficient information to choose a best variant, and |
1976 |
if the best variant is a neighboring variant, the origin server MAY |
1977 |
return a choice response with this variant. |
1978 |
|
1979 |
When getting a request on a transparently negotiable resource from |
1980 |
a user agent which does not support transparent content |
1981 |
negotiation, the origin server MAY use a custom algorithm to select |
1982 |
between sending a list, choice, or ad hoc response. When getting a |
1983 |
request on a transparently negotiable resource, the origin server |
1984 |
MUST NEVER return a response with a 2xx status code or any 3xx |
1985 |
status code, except 304, which is not a list, choice, or ad hoc |
1986 |
response. |
1987 |
|
1988 |
Negotiability is a binary property: a resource is either |
1989 |
transparently negotiated, or it is not. Origin servers SHOULD NOT |
1990 |
vary the negotiability of a resource, or the variant list bound to |
1991 |
that resource, based on the request headers which are received. |
1992 |
The variant list and the property of being negotiated MAY however |
1993 |
change through time. The Cache-Control header can be used to |
1994 |
control the propagation of such time-dependent changes through |
1995 |
caches. |
1996 |
|
1997 |
It is the responsibility of the author of the negotiable resource |
1998 |
to ensure that all resources in the variant list serve the intended |
1999 |
content, and that the variant resources do not engage in |
2000 |
transparent content negotiation themselves. |
2001 |
|
2002 |
|
2003 |
12.2 Negotiation on transactions other than GET and HEAD |
2004 |
|
2005 |
If a resource is transparently negotiable, this only has an impact |
2006 |
on the GET and HEAD transactions on the resource. It is not |
2007 |
possible (under this specification) to do transparent content |
2008 |
negotiation on the direct result of a POST request. |
2009 |
|
2010 |
However, a POST request can return an unnegotiated 303 (See Other) |
2011 |
response which causes the user agent to do a GET request on a |
2012 |
second resource. This second resource could then use transparent |
2013 |
content negotiation to return an appropriate final response. The |
2014 |
figure below illustrates this. |
2015 |
|
2016 |
Server ______ proxy ______ proxy ______ user |
2017 |
x.org cache cache agent |
2018 |
|
2019 |
< ------------------------------------- |
2020 |
| POST http://x.org/cgi/submit |
2021 |
| <form contents in request body> |
2022 |
| |
2023 |
-------------------------------------- > |
2024 |
303 See Other | |
2025 |
Location: http://x.org/result/OK | |
2026 |
| |
2027 |
< ------------------------------------- |
2028 |
| GET http://x.org/result/OK |
2029 |
| small Accept- headers |
2030 |
| |
2031 |
able to choose on |
2032 |
behalf of user agent |
2033 |
| |
2034 |
------------------------------------- > |
2035 |
choice response with | |
2036 |
..result/OK.nl variant | |
2037 |
displays OK.nl |
2038 |
|
2039 |
See the HTTP/1.1 specification [1] for details on the 303 (See |
2040 |
Other) status code. Note that this status code is not understood |
2041 |
by some HTTP/1.0 clients. |
2042 |
|
2043 |
|
2044 |
13 Proxy support for transparent negotiation |
2045 |
|
2046 |
Transparent content negotiation is an extension on top of HTTP/1.x. |
2047 |
It is designed to work through any proxy which only implements the |
2048 |
HTTP/1.1 specification [1]. If Expires headers are added as |
2049 |
discussed in section 10.7, negotiation will also work though |
2050 |
proxies which implement HTTP/1.0 [3]. Thus, every HTTP/1.0 or |
2051 |
HTTP/1.1 proxy provides support for transparent content |
2052 |
negotiation. However, if it is to be claimed that a HTTP/1.x proxy |
2053 |
offers transparent content negotiation services, at least one of |
2054 |
the specific optimizations below MUST be implemented. |
2055 |
|
2056 |
An HTTP/1.x proxy MUST ONLY optimize (change) the HTTP traffic |
2057 |
flowing through it in ways which are explicitly allowed by the |
2058 |
specification(s) it conforms to. A proxy which supports |
2059 |
transparent content negotiation on top of HTTP/1.x MAY perform the |
2060 |
optimizations allowed for by HTTP/1.x. In addition, it MAY perform |
2061 |
three additional optimizations, defined below, on the HTTP traffic |
2062 |
for transparently negotiated resources and their neighboring |
2063 |
variant resources. |
2064 |
|
2065 |
First, when getting a request on a transparently negotiable |
2066 |
resource from a user agent which supports transparent content |
2067 |
negotiation, the proxy MAY return any cached, fresh list response |
2068 |
from that resource, even if the selecting request headers, as |
2069 |
specified by the Vary header, do not match. |
2070 |
|
2071 |
Second, when allowed by the user agent and origin server, a proxy |
2072 |
MAY reuse an Alternates header taken from a previous response |
2073 |
(section 10.4) to run a remote variant selection algorithm. If the |
2074 |
algorithm has sufficient information to choose a best variant, and |
2075 |
if the best variant is a neighboring variant, the proxy MAY return |
2076 |
a choice response with this variant. |
2077 |
|
2078 |
Third, if a proxy receives a choice response, it MAY extract and |
2079 |
cache the normal response embedded therein, as described in section |
2080 |
10.5. |
2081 |
|
2082 |
|
2083 |
14 Security and privacy considerations |
2084 |
|
2085 |
14.1 Accept- headers revealing information of a private nature |
2086 |
|
2087 |
Accept- headers, in particular Accept-Language headers, may reveal |
2088 |
information which the user would rather keep private unless it will |
2089 |
directly improve the quality of service. For example, a user may |
2090 |
not want to send language preferences to sites which do not offer |
2091 |
multi-lingual content. The transparent content negotiation |
2092 |
mechanism allows user agents to omit sending of the Accept-Language |
2093 |
header by default, without adversely affecting the outcome of the |
2094 |
negotiation process if transparently negotiated multi-lingual |
2095 |
content is accessed. |
2096 |
|
2097 |
However, even if Accept- headers are never sent, the automatic |
2098 |
selection and retrieval of a variant by a user agent will reveal a |
2099 |
preference for this variant to the server. A malicious service |
2100 |
author could provide a page with `fake' negotiability on |
2101 |
(ethnicity-correlated) languages, with all variants actually being |
2102 |
the same English document, as a means of obtaining |
2103 |
privacy-sensitive information. Such a plot would however be |
2104 |
visible to an alert victim if the list of available variants and |
2105 |
their properties is reviewed. |
2106 |
|
2107 |
Some additional privacy considerations connected to Accept- headers |
2108 |
are discussed in [1]. |
2109 |
|
2110 |
|
2111 |
14.2 Spoofing of responses from variant resources |
2112 |
|
2113 |
The caching optimization in section 10.5 gives the implementer of a |
2114 |
negotiable resource control over the responses cached for all |
2115 |
neighboring variant resources. This is a security problem if a |
2116 |
neighboring variant resource belongs to another author. To provide |
2117 |
security in this case, the HTTP server will have to filter the |
2118 |
Content-Location headers in the choice responses generated by the |
2119 |
negotiable resource implementation. |
2120 |
|
2121 |
|
2122 |
15 Acknowledgments |
2123 |
|
2124 |
Work on HTTP content negotiation has been done since at least 1993. |
2125 |
The authors are unable to trace the origin of many of the ideas |
2126 |
incorporated in this document. This specification builds on an |
2127 |
earlier incomplete specification of content negotiation recorded in |
2128 |
[2]. Many members of the HTTP working group have contributed to |
2129 |
the negotiation model in this specification. The authors wish to |
2130 |
thank the individuals who have commented on earlier versions of |
2131 |
this document, including Brian Behlendorf, Daniel DuBois, Roy |
2132 |
T. Fielding, Dirk van Gulik, Ted Hardie, Larry Masinter, Jeffrey |
2133 |
Mogul, Frederick G.M. Roeber, Paul Sutton, and Klaus Weide. |
2134 |
|
2135 |
|
2136 |
16 References |
2137 |
|
2138 |
[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and |
2139 |
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC |
2140 |
2068, HTTP Working Group, January, 1997. |
2141 |
|
2142 |
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. |
2143 |
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft |
2144 |
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, |
2145 |
1996. |
2146 |
|
2147 |
[3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext |
2148 |
Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, |
2149 |
May 1996. |
2150 |
|
2151 |
[4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. |
2152 |
Internet-Draft draft-ietf-http-feature-reg-00.txt, HTTP Working |
2153 |
Group, October 30, 1996. |
2154 |
|
2155 |
[5] K. Holtman, A. Mutz. HTTP Remote Variant Selection Algorithm |
2156 |
-- RVSA/1.0. Internet-Draft draft-ietf-http-rvsa-v10-00.txt, |
2157 |
HTTP Working Group. |
2158 |
|
2159 |
|
2160 |
17 Authors' addresses |
2161 |
|
2162 |
Koen Holtman |
2163 |
Technische Universiteit Eindhoven |
2164 |
Postbus 513 |
2165 |
Kamer HG 6.57 |
2166 |
5600 MB Eindhoven (The Netherlands) |
2167 |
Email: koen@win.tue.nl |
2168 |
|
2169 |
Andrew H. Mutz |
2170 |
Hewlett-Packard Company |
2171 |
1501 Page Mill Road 3U-3 |
2172 |
Palo Alto CA 94304, USA |
2173 |
Fax +1 415 857 4691 |
2174 |
Email: mutz@hpl.hp.com |
2175 |
|
2176 |
|
2177 |
|
2178 |
18 Appendix: feature negotiation examples |
2179 |
|
2180 |
This appendix contains examples of the use of feature tags in |
2181 |
variant descriptions. The tag names used here are examples only, |
2182 |
they do not in general reflect the tag naming scheme proposed in |
2183 |
[4]. |
2184 |
|
2185 |
18.1 Use of feature tags |
2186 |
|
2187 |
Feature tags can be used in variant lists to express the quality |
2188 |
degradation associated with the presence or absence of certain |
2189 |
features. One example is |
2190 |
|
2191 |
{"index.html.plain" 0.7 }, |
2192 |
{"index.html" 1.0 {features tables frames}} |
2193 |
|
2194 |
Here, the "{features tables frames}" part expresses that index.html |
2195 |
uses the features tagged as tables and frames. If these features |
2196 |
are absent, the overall quality of index.html degrades to 0. |
2197 |
Another example is |
2198 |
|
2199 |
{"home.graphics" 1.0 {features !textonly}}, |
2200 |
{"home.textonly" 0.7 } |
2201 |
|
2202 |
where the "{features !textonly}" part expresses that home.graphics |
2203 |
requires the absence of the textonly feature. If the feature is |
2204 |
present, the overall quality of home.graphics degrades to 0. |
2205 |
|
2206 |
The absence of a feature need not always degrade the overall quality |
2207 |
to 0. In the example |
2208 |
|
2209 |
{"x.html.1" 1.0 {features fonts/0.7}} |
2210 |
|
2211 |
the absence of the fonts feature degrades the quality with a factor |
2212 |
of 0.7. "fonts/0.7" can be pronounced as "fonts, or a degradation |
2213 |
of 0.7". Finally, in the example |
2214 |
|
2215 |
{"y.html" 1.0 {features [blebber wolx] }} |
2216 |
|
2217 |
The "[blebber wolx]" expresses that y.html requires the presence of |
2218 |
the blebber feature or the wolx feature. This construct can be |
2219 |
used in a number of cases: |
2220 |
|
2221 |
1. blebber and wolx actually tag the same feature, but they were |
2222 |
registered by different people, and some user agents say they |
2223 |
support blebber while others say they support wolx. |
2224 |
|
2225 |
2. blebber and wolx are HTML tags of different vendors which |
2226 |
implement the same functionality, and which are used |
2227 |
together in y.html without interference. |
2228 |
|
2229 |
3. blebber and wolx are HTML tags of different vendors which |
2230 |
implement the same functionality, and y.html uses the tags in |
2231 |
a conditional HTML construct. |
2232 |
|
2233 |
4. blebber is a complicated HTML tag with only a sketchy |
2234 |
definition, implemented by one user agent vendor, and wolx |
2235 |
indicates implementation of a well-defined subset of the |
2236 |
blebber tag by some other vendor(s). y.html uses only this |
2237 |
well-defined subset. |
2238 |
|
2239 |
|
2240 |
18.2 Use of numeric feature tags |
2241 |
|
2242 |
As an example of negotiation in a numeric area, the following |
2243 |
variant list describes four variants with title graphics designed |
2244 |
for increasing screen widths: |
2245 |
|
2246 |
{"home.pda" 1.0 {features screenwidth=<-199> }}, |
2247 |
{"home.narrow" 1.0 {features screenwidth=<200-599> }}, |
2248 |
{"home.normal" 1.0 {features screenwidth=<600-999> }}, |
2249 |
{"home.wide" 1.0 {features screenwidth=<1000-> }}, |
2250 |
{"home.normal"} |
2251 |
|
2252 |
The last element of the list specifies a safe default for user |
2253 |
agents which do not implement screen width negotiation. Such user |
2254 |
agents will reject the first four variants as unusable, as they |
2255 |
seem to rely on a feature which they do not understand. |
2256 |
|
2257 |
|
2258 |
18.3 Feature tag design |
2259 |
|
2260 |
When designing a new feature tag, it is important to take into |
2261 |
account that existing user agents, which do not recognize the new |
2262 |
tag will treat the feature as absent. In general, a new feature |
2263 |
tag needs to be designed in such a way that absence of the tag is |
2264 |
the default case which reflects current practice. If this design |
2265 |
principle is ignored, the resulting feature tag will generally be |
2266 |
unusable. |
2267 |
|
2268 |
As an example, one could try to support negotiation between |
2269 |
monochrome and color content by introducing a `color' feature tag, |
2270 |
the presence of which would indicate the capability to display |
2271 |
color graphics. However, if this new tag is used in a variant |
2272 |
list, for example |
2273 |
|
2274 |
{"rainbow.gif" 1.0 {features color} } |
2275 |
{"rainbow.mono.gif" 0.6 {features !color}} |
2276 |
|
2277 |
then existing user agents, which would not recognize the color tag, |
2278 |
would all display the monochrome rainbow. The color tag is |
2279 |
therefore unusable in situations where optimal results for existing |
2280 |
user agents are desired. To provide for negotiation in this area, |
2281 |
one must introduce a `monochrome' feature tag; its presence |
2282 |
indicates that the user agent can only render (or the user prefers |
2283 |
to view) monochrome graphics. |
2284 |
|
2285 |
|
2286 |
19 Appendix: origin server implementation considerations |
2287 |
|
2288 |
19.1 Implementation with a CGI script |
2289 |
|
2290 |
Transparent content negotiation has been designed to allow a broad |
2291 |
range of implementation options at the origin server side. A very |
2292 |
minimal implementation can be done using the CGI interface. The |
2293 |
CGI script below is an example. |
2294 |
|
2295 |
#!/bin/sh |
2296 |
|
2297 |
cat - <<'blex' |
2298 |
TCN: list |
2299 |
Alternates: {"stats.tables.html" 1.0 {type text/html} {features |
2300 |
tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95 |
2301 |
{type application/postscript}} |
2302 |
Vary: * |
2303 |
Content-Type: text/html |
2304 |
|
2305 |
<title>Multiple Choices for Web Statistics</title> |
2306 |
<h2>Multiple Choices for Web Statistics:</h2> |
2307 |
<ul> |
2308 |
<li><a href=stats.tables.html>Version with HTML tables</a> |
2309 |
<p> |
2310 |
<li><a href=stats.html>Version without HTML tables</a> |
2311 |
<p> |
2312 |
<li><a href=stats.ps>Postscript version</a> |
2313 |
</ul> |
2314 |
blex |
2315 |
|
2316 |
The Alternates header in the above script must be read as a single |
2317 |
line. The script always generates a list response with the 200 |
2318 |
(OK) code, which ensures compatibility with non-negotiating |
2319 |
HTTP/1.0 agents. |
2320 |
|
2321 |
|
2322 |
19.2 Direct support by HTTP servers |
2323 |
|
2324 |
Sophisticated HTTP servers could make a transparent negotiation |
2325 |
module available to content authors. Such a module could |
2326 |
incorporate a remote variant selection algorithm and an |
2327 |
implementation of the algorithm for generating choice responses |
2328 |
(section 10.2). The definition of interfaces to such modules is |
2329 |
beyond the scope of this specification. |
2330 |
|
2331 |
|
2332 |
19.3 Web publishing tools |
2333 |
|
2334 |
Web publishing tools could automatically generate several variants |
2335 |
of a document (for example the original TeX version, a HTML version |
2336 |
with tables, a HTML version without tables, and a Postscript |
2337 |
version), together with an appropriate variant list in the |
2338 |
interface format of a HTTP server transparent negotiation module. |
2339 |
This would allow documents to be published as transparently |
2340 |
negotiable resources. |
2341 |
|
2342 |
|
2343 |
20 Appendix: Example of choice response construction |
2344 |
|
2345 |
The following is an example of the construction of a choice |
2346 |
response by a proxy cache which supports HTTP/1.1 and transparent |
2347 |
content negotiation. The use of the HTTP/1.1 conditional request |
2348 |
mechanisms is also shown. |
2349 |
|
2350 |
Assume that a user agent has cached a variant list with the |
2351 |
validator "1234" for the negotiable resource http://x.org/paper. |
2352 |
Also assume that it has cached responses from two neighboring |
2353 |
variants, with the entity tags "gonkyyyy" and W/"a;b". Assume that |
2354 |
all three user agent cache entries are stale: they would need to be |
2355 |
revalidated before the user agent can use them. If |
2356 |
http://x.org/paper accessed in this situation, the user agent could |
2357 |
send the following request to its proxy cache: |
2358 |
|
2359 |
GET /paper HTTP/1.1 |
2360 |
Host: x.org |
2361 |
User-Agent: WuxtaWeb/2.4 |
2362 |
Negotiate: 1.0 |
2363 |
Accept: text/html, application/postscript;q=0.4, */* |
2364 |
Accept-Language: en |
2365 |
If-None-Match: "gonkyyyy;1234", W/"a;b;1234" |
2366 |
|
2367 |
Assume that the proxy cache has cached the same three items as the |
2368 |
user agent, but that it has revalidated the variant list 8000 |
2369 |
seconds ago, so that the list is still fresh for the proxy. This |
2370 |
means that the proxy can run a remote variant selection algorithm |
2371 |
on the list and the incoming request. |
2372 |
|
2373 |
Assume that the remote algorithm is able to choose paper.en.html as |
2374 |
the best variant. The proxy can now construct a choice response, |
2375 |
using the algorithm in section 10.2. In steps 1 and 2 of the |
2376 |
algorithm, the proxy can construct the following conditional |
2377 |
request on the best variant, and send it to the origin server: |
2378 |
|
2379 |
GET /paper.html.en HTTP/1.1 |
2380 |
Host: x.org |
2381 |
User-Agent: WuxtaWeb/2.4 |
2382 |
Negotiate: 1.0 |
2383 |
Accept: text/html, application/postscript;q=0.4, */* |
2384 |
Accept-Language: en |
2385 |
If-None-Match: "gonkyyyy", W/"a;b" |
2386 |
Via: 1.1 fred |
2387 |
|
2388 |
On receipt of the response |
2389 |
|
2390 |
HTTP/1.1 304 Not Modified |
2391 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
2392 |
Etag: "gonkyyyy" |
2393 |
|
2394 |
from the origin server, the proxy can use its freshly revalidated |
2395 |
paper.html.en cache entry to expand the response to a non-304 |
2396 |
response: |
2397 |
|
2398 |
HTTP/1.1 200 OK |
2399 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
2400 |
Content-Type: text/html |
2401 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
2402 |
Content-Length: 5327 |
2403 |
Cache-control: max-age=604800 |
2404 |
Etag: "gonkyyyy" |
2405 |
Via: 1.1 fred |
2406 |
Age: 0 |
2407 |
|
2408 |
<title>A paper about .... |
2409 |
|
2410 |
Using this 200 response, the proxy can construct a choice response |
2411 |
in step 4 of the algorithm: |
2412 |
|
2413 |
HTTP/1.1 200 OK |
2414 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
2415 |
TCN: choice |
2416 |
Content-Type: text/html |
2417 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
2418 |
Content-Length: 5327 |
2419 |
Cache-control: max-age=604800 |
2420 |
Content-Location: paper.html.en |
2421 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
2422 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
2423 |
{"paper.ps.en" 1.0 {type application/postscript} |
2424 |
{language en}} |
2425 |
Etag: "gonkyyyy;1234" |
2426 |
Vary: negotiate, accept, accept-language |
2427 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
2428 |
Via: 1.1 fred |
2429 |
Age: 8000 |
2430 |
|
2431 |
<title>A paper about .... |
2432 |
|
2433 |
The choice response can subsequently be shortened to a 304 |
2434 |
response, because of the If-None-Match header in the original |
2435 |
request from the user agent. Thus, the proxy can finally return |
2436 |
|
2437 |
HTTP/1.1 304 Not Modified |
2438 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
2439 |
Etag: "gonkyyyy;1234" |
2440 |
Content-Location: paper.html.en |
2441 |
Vary: negotiate, accept, accept-language |
2442 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
2443 |
Via: 1.1 fred |
2444 |
Age: 8000 |
2445 |
|
2446 |
to the user agent. |
2447 |
|
2448 |
|
2449 |
Expires: September 9, 1997 |
2450 |
|