1 |
HTTP Working Group Koen Holtman, TUE |
2 |
Internet-Draft Andrew Mutz, Hewlett-Packard |
3 |
Expires: May 21, 1997 November 21, 1996 |
4 |
|
5 |
|
6 |
Transparent Content Negotiation in HTTP |
7 |
|
8 |
draft-holtman-http-negotiation-04.txt |
9 |
|
10 |
|
11 |
STATUS OF THIS MEMO |
12 |
|
13 |
This document is an Internet-Draft. Internet-Drafts are |
14 |
working documents of the Internet Engineering Task Force |
15 |
(IETF), its areas, and its working groups. Note that other |
16 |
groups may also distribute working documents as |
17 |
Internet-Drafts. |
18 |
|
19 |
Internet-Drafts are draft documents valid for a maximum of |
20 |
six months and may be updated, replaced, or obsoleted by |
21 |
other documents at any time. It is inappropriate to use |
22 |
Internet-Drafts as reference material or to cite them other |
23 |
than as "work in progress". |
24 |
|
25 |
To learn the current status of any Internet-Draft, please |
26 |
check the "1id-abstracts.txt" listing contained in the |
27 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
28 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
29 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
30 |
West Coast). |
31 |
|
32 |
Distribution of this document is unlimited. Please send |
33 |
comments to the HTTP working group at |
34 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
35 |
group are archived at |
36 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
37 |
discussions about HTTP and the applications which use HTTP |
38 |
should take place on the <www-talk@w3.org> mailing list. |
39 |
|
40 |
A HTML version of this document, and versions with change |
41 |
bars, are available at |
42 |
<URL:http://gewis.win.tue.nl/~koen/conneg/>. |
43 |
|
44 |
|
45 |
ABSTRACT |
46 |
|
47 |
HTTP allows one to put multiple versions of the same |
48 |
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 |
Design goals for transparent content negotiation include: low |
55 |
overhead on the request message size, downwards compatibility, |
56 |
extensibility, enabling the rapid introduction of new areas of |
57 |
negotiation, scalability, low cost for minimal support, end |
58 |
user control, and good cacheability. |
59 |
|
60 |
|
61 |
TABLE OF CONTENTS |
62 |
|
63 |
Note: the section numbering is this document is sometimes irregular |
64 |
because it tries to preserve the numbering in the 02 version as |
65 |
much as possible. |
66 |
|
67 |
1 Introduction |
68 |
1.1 Background |
69 |
1.2 Note for readers |
70 |
1.3 Revision History |
71 |
|
72 |
2 Terminology |
73 |
2.1 Terms from HTTP/1.1 |
74 |
2.2 New terms |
75 |
|
76 |
3 Notation |
77 |
|
78 |
4 Overview |
79 |
4.1 Content negotiation |
80 |
4.2 HTTP/1.0 style negotiation scheme |
81 |
4.3 Transparent content negotiation scheme |
82 |
4.4 Optimizing the negotiation process |
83 |
4.4B Downwards compatibility with non-negotiating user agents |
84 |
4.5 Retrieving a variant by hand |
85 |
4.6 Dimensions of negotiation |
86 |
4.7 Feature negotiation |
87 |
|
88 |
5 Variant descriptions |
89 |
5.1 Syntax |
90 |
5.2 URI |
91 |
5.3 Source-quality |
92 |
5.4 Type, language, length, and charset. |
93 |
5.5 Features |
94 |
5.6 Description |
95 |
5.7 Extension-attribute |
96 |
|
97 |
6 Feature negotiation |
98 |
6.1 Feature tags |
99 |
6.2 Accept-Features header |
100 |
6.3 Feature predicates |
101 |
6.4 Features attribute |
102 |
|
103 |
7 Feature negotiation examples |
104 |
7.1 Use of feature tags |
105 |
7.2 Use of numeric feature tags |
106 |
|
107 |
8 Feature tag registration |
108 |
8.1 Evolution of feature tags |
109 |
8.2 Core set of feature tags |
110 |
8.3 Feature tag design |
111 |
|
112 |
9 Content negotiation response codes and headers |
113 |
9.1 506 Variant Also Negotiates |
114 |
9.2 Accept-Features |
115 |
9.3 Content-Features |
116 |
9.4 Alternates |
117 |
9.6 Negotiate |
118 |
9.7 Variant-Vary |
119 |
|
120 |
9B Cache validators |
121 |
9B.1 Variant list validators |
122 |
9B.2 Structured entity tags |
123 |
9B.3 Assigning entity tags to variants |
124 |
|
125 |
10 Content negotiation responses |
126 |
10.1 List response |
127 |
10.2 Choice response |
128 |
10.2B Ad hoc response |
129 |
10.3 Reusing the Alternates header |
130 |
10.4 Extracting a normal response from a choice response |
131 |
10.5 Elaborate Vary headers |
132 |
10.5.1 Construction of an elaborate Vary header |
133 |
10.5.2 Caching of an elaborate Vary header |
134 |
10.6 Negotiation on content encoding |
135 |
|
136 |
11 The network negotiation algorithm |
137 |
11.1 Input |
138 |
11.2 Output |
139 |
11.2.1 Output for proxies |
140 |
11.2.2 Output for origin servers |
141 |
11.2.3 Output for user agents |
142 |
11.3 Computing the overall quality values |
143 |
11.4 Definite and speculative quality values |
144 |
11.5 Determining the result |
145 |
11.5.1 Result for proxies and origin servers |
146 |
11.5.2 Result for user agents |
147 |
11.6 Construction of short requests |
148 |
|
149 |
12 User agent support for transparent negotiation |
150 |
12.1 Handling of responses |
151 |
12.2 Presentation of a transparently negotiated resource |
152 |
|
153 |
13 Origin server support for transparent negotiation |
154 |
13.1 Requirements |
155 |
13.2 Negotiation on transactions other than GET and HEAD |
156 |
|
157 |
14 Proxy support for transparent negotiation |
158 |
|
159 |
15 Security and privacy considerations |
160 |
15.1 Accept headers revealing information of a private nature |
161 |
15.2 Spoofing of responses from variant resources |
162 |
|
163 |
16 Acknowledgments |
164 |
|
165 |
17 References |
166 |
|
167 |
18 Authors' addresses |
168 |
|
169 |
19 Appendices |
170 |
19.1 Adding an Expires header to ensure HTTP/1.0 compatibility |
171 |
19.2 Origin server implementation considerations |
172 |
19.2.1 Implementation with a CGI script |
173 |
19.2.2 Direct support by HTTP servers |
174 |
19.2.3 Web publishing tools |
175 |
19.3 Open issues in transparent content negotiation |
176 |
19.3B Server-side rendering engines |
177 |
19.3C Quality factors in the Accept-Features header |
178 |
19.4 Other negotiation specifications |
179 |
19.4.1 User-Agent Display Attributes |
180 |
19.4.2 HTTP/1.2 Extension Protocol (PEP) |
181 |
19.5 Related issues |
182 |
19.5.1 Current negotiation practice |
183 |
19.5.2 Bandwidth negotiation |
184 |
|
185 |
|
186 |
1 Introduction |
187 |
|
188 |
HTTP allows one to put multiple versions of the same information |
189 |
under a single URI. Each of these versions is called a `variant'. |
190 |
Transparent content negotiation is a mechanism for automatically |
191 |
and efficiently retrieving the best variant when a GET or HEAD |
192 |
request is made. This enables the smooth deployment of new web |
193 |
data formats and markup tags. |
194 |
|
195 |
This specification defines transparent content negotiation as an |
196 |
extension on top of the HTTP/1.1 protocol [1]. However, use of |
197 |
this extension does not require use of HTTP/1.1: transparent |
198 |
content negotiation can also be done if some or all of the parties |
199 |
are HTTP/1.0 [3] systems. |
200 |
|
201 |
Transparent negotiation is called `transparent' because it makes |
202 |
all variants inside the origin server visible to outside parties. |
203 |
|
204 |
|
205 |
1.1 Background |
206 |
|
207 |
The addition of content negotiation to the web infrastructure has |
208 |
been considered important since the early days of the web. Among |
209 |
the expected benefits of a sufficiently powerful system for content |
210 |
negotiation are |
211 |
|
212 |
* smooth deployment of new data formats and markup tags will |
213 |
allow graceful evolution of the web |
214 |
|
215 |
* eliminating the need to choose between a `state of the art |
216 |
multimedia homepage' and one which can be viewed by all web |
217 |
users |
218 |
|
219 |
* enabling good service to a wider range of browsing |
220 |
platforms (from low-end PDA's to high-end VR setups) |
221 |
|
222 |
* eliminating error-prone and cache-unfriendly |
223 |
User-Agent based negotiation |
224 |
|
225 |
* enabling construction of sites without `click here for the X |
226 |
version' links |
227 |
|
228 |
* internationalization, and the ability to offer multi-lingual |
229 |
content without a bias towards one language. |
230 |
|
231 |
The development of content negotiation has been a slow process, |
232 |
perhaps because the expected benefits are mostly long-term |
233 |
benefits. Also, all immediately obvious content negotiation |
234 |
solutions involve sending larger HTTP request messages. Larger |
235 |
request messages are unacceptable to many people: a small overhead |
236 |
on the request size is often cited as the main technical |
237 |
requirement for any scheme which offers the above benefits. |
238 |
|
239 |
Therefore, a low overhead on the request message size is one of the |
240 |
main design goals of this specification. A large fraction of the |
241 |
text below is devoted to the definition of mechanisms for meeting |
242 |
this design goal. The desire to provide for good cacheability in |
243 |
all cases accounts for another considerable part of the content of |
244 |
this document. |
245 |
|
246 |
Other design goals include downwards compatibility, extensibility, |
247 |
enabling the rapid introduction of new areas of negotiation, |
248 |
scalability, low cost of minimal support, and end user control. |
249 |
End user control, the option to manually select a variant if |
250 |
desired, is the one redeeming quality of the `click here for the X |
251 |
version' type of negotiation. Preserving this option is considered |
252 |
important. |
253 |
|
254 |
|
255 |
1.2 Note for readers |
256 |
|
257 |
Some sections in this document discuss requirements for proxy |
258 |
caches only. Implementers of origin servers and user agents (but |
259 |
not implementers of user agent caches) can skip these sections. |
260 |
The sections which can be skipped are: |
261 |
|
262 |
10.3 Reusing the Alternates header |
263 |
10.4 Extracting a normal response from a choice response |
264 |
10.5.2 Caching of an elaborate Vary header |
265 |
14 Proxy support for transparent negotiation |
266 |
|
267 |
The skipping of these sections is also recommended on first |
268 |
reading. |
269 |
|
270 |
|
271 |
1.3 Revision History |
272 |
|
273 |
The change bars in this document reflect the changes with respect |
274 |
to the 03 version of this draft. Major functional changes are: |
275 |
|
276 |
- The model for the caching of variant lists has been changed |
277 |
extensively. (The previous version had a problem with downwards |
278 |
compatibility.) |
279 |
|
280 |
- The definition of the Negotiate header has been changed to |
281 |
include a `trans' keyword. |
282 |
|
283 |
- The form `ftag=<N-M>', with N-M a range of numeric values, was |
284 |
added to the feature expressions and feature predicates. |
285 |
|
286 |
Major changes in the presentation are: |
287 |
|
288 |
- Feature tag registration is now covered in a separate draft |
289 |
|
290 |
- Some new explanatory material was added |
291 |
|
292 |
- Some existing text has been improved |
293 |
|
294 |
In the text version of this document with change bars, all changes |
295 |
are marked except changes in formatting and punctuation. |
296 |
|
297 |
In the HTML version of this document with changes marked, all |
298 |
changed words and symbols are typeset in bold text. Deletions and |
299 |
changes in punctuation are not marked in the HTML version. |
300 |
|
301 |
|
302 |
2 Terminology |
303 |
|
304 |
2.1 Terms from HTTP/1.1 |
305 |
|
306 |
This specification mostly uses the terminology of the HTTP/1.1 |
307 |
specification [1]. The definitions below were reproduced from [1]. |
308 |
|
309 |
request |
310 |
An HTTP request message. |
311 |
|
312 |
response |
313 |
An HTTP response message. |
314 |
|
315 |
resource |
316 |
A network data object or service that can be identified by a URI. |
317 |
Resources may be available in multiple representations |
318 |
(e.g. multiple languages, data formats, size, resolutions) or |
319 |
vary in other ways. |
320 |
|
321 |
content negotiation |
322 |
The mechanism for selecting the appropriate representation when |
323 |
servicing a request. |
324 |
|
325 |
variant |
326 |
A resource may have one, or more than one, representation(s) |
327 |
associated with it at any given instant. Each of these |
328 |
representations is termed a `variant.' Use of the term `variant' |
329 |
does not necessarily imply that the resource is subject to |
330 |
content negotiation. |
331 |
|
332 |
client |
333 |
A program that establishes connections for the purpose of sending |
334 |
requests. |
335 |
|
336 |
user agent |
337 |
The client which initiates a request. These are often browsers, |
338 |
editors, spiders (web-traversing robots), or other end user |
339 |
tools. |
340 |
|
341 |
server |
342 |
An application program that accepts connections in order to |
343 |
service requests by sending back responses. Any given program may |
344 |
be capable of being both a client and a server; our use of these |
345 |
terms refers only to the role being performed by the program for |
346 |
a particular connection, rather than to the program's |
347 |
capabilities in general. Likewise, any server may act as an |
348 |
origin server, proxy, gateway, or tunnel, switching behavior |
349 |
based on the nature of each request. |
350 |
|
351 |
origin server |
352 |
The server on which a given resource resides or is to be created. |
353 |
|
354 |
proxy |
355 |
An intermediary program which acts as both a server and a client |
356 |
for the purpose of making requests on behalf of other |
357 |
clients. Requests are serviced internally or by passing them on, |
358 |
with possible translation, to other servers. A proxy must |
359 |
implement both the client and server requirements of this |
360 |
specification. |
361 |
|
362 |
age |
363 |
The age of a response is the time since it was sent by, or |
364 |
successfully validated with, the origin server. |
365 |
|
366 |
fresh |
367 |
A response is fresh if its age has not yet exceeded its freshness |
368 |
lifetime. |
369 |
|
370 |
2.2 New terms |
371 |
|
372 |
transparently negotiable resource |
373 |
A resource, identified by a single URI, which has multiple |
374 |
representations (variants) associated with it. When servicing a |
375 |
request on its URI, it allows selection of the best |
376 |
representation using the transparent content negotiation |
377 |
mechanism. A transparently negotiable resource always has a |
378 |
variant list bound to it, which can be represented as an |
379 |
Alternates header. |
380 |
|
381 |
variant list |
382 |
A list containing variant descriptions, which can be bound to a |
383 |
transparently negotiable resource. |
384 |
|
385 |
variant description |
386 |
A machine-readable description of a variant resource, usually |
387 |
found in a variant list. A variant description contains the |
388 |
variant resource URI and various attributes which describe |
389 |
properties of the variant. Variant descriptions are defined in |
390 |
Section 5. |
391 |
|
392 |
variant resource |
393 |
A resource from which a variant of a negotiable resource can be |
394 |
retrieved with a simple GET request. A variant resource usually |
395 |
has only one representation (variant) associated with it. |
396 |
|
397 |
list response |
398 |
A list response contains the variant list of the negotiable |
399 |
resource, but no variant data. It is generated when the server |
400 |
does not (perhaps cannot) choose a particular best variant for the |
401 |
request. List responses are defined in Section 10.1. |
402 |
|
403 |
choice response |
404 |
A choice response contains both the variant list of the |
405 |
negotiable resource and a representation of the best variant for |
406 |
the request. Choice responses are defined in Section 10.2. |
407 |
|
408 |
ad hoc response |
409 |
An ad hoc response contains the variant list of the negotiable |
410 |
resource, and any other data the origin server wants to send. It |
411 |
can be generated as a response to a non-negotiating user agent if |
412 |
the server does not (perhaps cannot) choose any particular |
413 |
variant. Ad hoc responses are defined in Section 10.2B. |
414 |
|
415 |
normal response |
416 |
A HTTP response which is not a list response, choice response, or |
417 |
ad hoc response. Normal responses are never generated by |
418 |
transparently negotiable resources, and are always generated by |
419 |
variant resources. |
420 |
|
421 |
Accept headers |
422 |
The request headers: Accept, Accept-Charset, Accept-Language, and |
423 |
Accept-Features. |
424 |
|
425 |
network negotiation algorithm |
426 |
A standardized algorithm by which a party in the negotiation |
427 |
process can choose a best variant on behalf of another party. |
428 |
The algorithm computes whether the Accept headers in the request |
429 |
contain sufficient information to allow a choice, and if so, |
430 |
which variant must be chosen. The network negotiation algorithm |
431 |
is defined in Section 11. |
432 |
|
433 |
neighbor |
434 |
Two resources are called neighbors if the absolute URI of the |
435 |
first resource up to its last slash equals the absolute URI of |
436 |
the second resource up to its last slash. The neighboring |
437 |
relation is important because of security considerations; see |
438 |
Section 15.2. |
439 |
|
440 |
[##Historical note: In the context of old versions of the HTTP/1.1 |
441 |
specification like [2], list responses can be called `pre-emptive |
442 |
negotiation responses', and choice responses can be called |
443 |
`reactive negotiation responses'.##] |
444 |
|
445 |
[##Note: In the context of the HTTP/1.1 specification [1], both |
446 |
list and choice responses are the result of server-driven |
447 |
negotiation, though a list response is a server-driven negotiation |
448 |
response meant to initiate agent-driven negotiation.##] |
449 |
|
450 |
|
451 |
3 Notation |
452 |
|
453 |
The notation [## ... ##] in this document encloses an editorial |
454 |
comment. Such a comment will be either removed or replaced by real |
455 |
text in the final version of this document. |
456 |
|
457 |
The version of BNF used in this document is taken from [1], and |
458 |
many of the nonterminals used are defined in [1]. |
459 |
|
460 |
One new BNF construct is added: |
461 |
|
462 |
1%rule |
463 |
|
464 |
stands for one or more instances of "rule", separated by |
465 |
whitespace: |
466 |
|
467 |
1%rule = rule *( 1*LWS rule ) |
468 |
|
469 |
|
470 |
4 Overview |
471 |
|
472 |
This section gives an overview of transparent content negotiation. |
473 |
It starts with a more general discussion of negotiation as provided |
474 |
by HTTP. |
475 |
|
476 |
|
477 |
4.1 Content negotiation |
478 |
|
479 |
HTTP/1.1 allows one to put multiple versions of the same |
480 |
information under a single resource URI. Each of these versions is |
481 |
called a `variant'. For example, a resource http://x.org/paper |
482 |
could bind to three different variants of a paper: |
483 |
|
484 |
1. HTML, English |
485 |
2. HTML, French |
486 |
3. Postscript, English |
487 |
|
488 |
Content negotiation is the process by which the best variant is |
489 |
selected if the resource is accessed. The selection is done by |
490 |
matching the properties of the available variants to the |
491 |
capabilities of the user agent and the preferences of the user. |
492 |
|
493 |
It has always been possible under HTTP to have multiple |
494 |
representations available for one resource, and to return the most |
495 |
appropriate representation for each subsequent request. |
496 |
HTTP/1.1 is the first version of HTTP which has provisions for |
497 |
doing this in a cache-friendly way. These provisions include the |
498 |
Vary response header, entity tags, and the If-None-Match request |
499 |
header. |
500 |
|
501 |
|
502 |
4.2 HTTP/1.0 style negotiation scheme |
503 |
|
504 |
The HTTP/1.0 protocol elements allow for a negotiation scheme as |
505 |
follows: |
506 |
|
507 |
Server _____ proxy _____ proxy _____ user |
508 |
x.org cache cache agent |
509 |
|
510 |
< ---------------------------------- |
511 |
| GET http://x.org/paper |
512 |
| Accept headers |
513 |
choose |
514 |
| |
515 |
---------------------------------- > |
516 |
Best variant |
517 |
|
518 |
When the resource is accessed, the user agent sends (along with its |
519 |
request) various Accept headers which express the user agent |
520 |
capabilities and the user preferences. Then the origin server uses |
521 |
these Accept headers to choose the best variant, which is returned |
522 |
in the response. |
523 |
|
524 |
The biggest problem with this scheme is that it does not scale |
525 |
well. For all but the most minimal user agents, Accept headers |
526 |
expressing all capabilities and preferences would be very large, |
527 |
and sending them in every request would be hugely inefficient, in |
528 |
particular because only a small fraction of the resources on the |
529 |
web have multiple variants. |
530 |
|
531 |
|
532 |
4.3 Transparent content negotiation scheme |
533 |
|
534 |
The transparent negotiation scheme eliminates the need to send huge |
535 |
Accept headers, and nevertheless allows for a selection process |
536 |
that always yields either the best variant, or an error message |
537 |
indicating that user agent is not capable of displaying any of the |
538 |
available variants. |
539 |
|
540 |
Under the transparent content negotiation scheme, the server sends |
541 |
a list with the available variants and their properties to the user |
542 |
agent. An example of a list with three variants is |
543 |
|
544 |
{"paper.html.en" 0.9 {type text/html} {language en}}, |
545 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
546 |
{"paper.ps.en" 1.0 {type application/postscript} {language en}} |
547 |
|
548 |
The syntax and semantics of the variant descriptions in this list |
549 |
are covered in depth in Section 5. When the list is received, the |
550 |
user agent can choose the best variant and retrieve it. |
551 |
Graphically, the communication can be represented as follows: |
552 |
|
553 |
Server _____ proxy _____ proxy _____ user |
554 |
x.org cache cache agent |
555 |
|
556 |
< ---------------------------------- |
557 |
| GET http://x.org/paper |
558 |
| |
559 |
----------------------------------- > [list response] |
560 |
return of list | |
561 |
choose |
562 |
| |
563 |
< ---------------------------------- |
564 |
| GET http://x.org/paper.html.en |
565 |
| |
566 |
---------------------------------- > [normal response] |
567 |
return of html.en |
568 |
|
569 |
The first response returning the list of variants is called a `list |
570 |
response'. The second response is a normal HTTP response: it does |
571 |
not contain special content negotiation related information. Only |
572 |
the user agent needs to know that the second request actually |
573 |
retrieves a variant, for the other parties in the communication, |
574 |
the second transaction is indistinguishable from a normal HTTP |
575 |
transaction. |
576 |
|
577 |
With this scheme, information about capabilities and user |
578 |
preferences is only used by the user agent itself. Therefore, |
579 |
sending such information in large Accept headers is unnecessary. |
580 |
Accept headers do have a limited use in transparent content |
581 |
negotiation however; the sending of small Accept headers can often |
582 |
speed up the negotiation process. This is covered in Section 4.4. |
583 |
|
584 |
List responses are covered in depth in Section 10.1. As an |
585 |
example, the list response in the above picture could be: |
586 |
|
587 |
HTTP/1.1 300 Multiple Choices |
588 |
Date: Tue, 11 Jun 1996 20:02:21 GMT |
589 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
590 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
591 |
{"paper.ps.en" 1.0 {type application/postscript} |
592 |
{language en}} |
593 |
Vary: negotiate, accept, accept-language |
594 |
ETag: "blah;1234" |
595 |
Cache-control: max-age=86400 |
596 |
Content-Type: text/html |
597 |
Content-Length: 227 |
598 |
|
599 |
<h2>Multiple Choices:</h2> |
600 |
<ul> |
601 |
<li><a href=paper.html.en>HTML, English version</a> |
602 |
<li><a href=paper.html.fr>HTML, French version</a> |
603 |
<li><a href=paper.ps.en>Postscript, English version</a> |
604 |
</ul> |
605 |
|
606 |
The Alternates header in the response contains the variant list. |
607 |
The Vary header is included to ensure correct caching by HTTP/1.1 |
608 |
caches not capable of transparent content negotiation (see Section |
609 |
10.5). The ETag header allows the response to be revalidated by |
610 |
caches, the Cache-Control header controls this revalidation. The |
611 |
HTML entity included in the response allows the user to select the |
612 |
best variant by hand if desired. |
613 |
|
614 |
|
615 |
4.4 Optimizing the negotiation process |
616 |
|
617 |
The basic transparent negotiation scheme involves two HTTP |
618 |
transactions: one to retrieve the list, and a second one to retrieve |
619 |
the chosen variant. There are however several ways to `cut corners' |
620 |
in the data flow path of the basic scheme. |
621 |
|
622 |
First, caching proxies can cache both variant lists and complete |
623 |
responses. Such caching can reduce the communication overhead, as |
624 |
shown in the following example: |
625 |
|
626 |
Server _____ proxy _____ proxy __________ user |
627 |
x.org cache cache agent |
628 |
|
629 |
< -------------- |
630 |
| GET ../paper |
631 |
| |
632 |
has the list |
633 |
in cache |
634 |
| |
635 |
------------- > [list response] |
636 |
list | |
637 |
| |
638 |
choose |
639 |
| |
640 |
< -------------------------- |
641 |
| GET ../paper.html.en |
642 |
| |
643 |
has the variant |
644 |
in cache |
645 |
| |
646 |
-------------------------- > [normal response] |
647 |
return of html.en |
648 |
|
649 |
Second, the user agent can send small Accept headers which could |
650 |
allow a server to determine the choice the user agent would make on |
651 |
receiving the list. If the Accept headers contain enough |
652 |
information, the origin server can send back the variant directly: |
653 |
|
654 |
Server _____ proxy _____ proxy _____ user |
655 |
x.org cache cache agent |
656 |
|
657 |
< ---------------------------------- |
658 |
| GET http://x.org/paper |
659 |
| small Accept headers |
660 |
| |
661 |
able to choose on |
662 |
behalf of user agent |
663 |
| |
664 |
---------------------------------- > [choice response] |
665 |
return of html.en and list |
666 |
|
667 |
This choosing based on small accept headers can be done with the |
668 |
network negotiation algorithm (Section 11). This algorithm takes |
669 |
the variant list and the Accept headers as input. It computes |
670 |
whether the Accept headers contain sufficient information to choose |
671 |
on behalf of the user agent, and if so, which variant must be |
672 |
chosen. |
673 |
|
674 |
The response in the above diagram is called a choice response. It |
675 |
transmits both the chosen variant and the list of all variants |
676 |
bound to the negotiable resource. Choice responses are covered in |
677 |
depth in Section 10.2. For example, the choice response in the |
678 |
above picture could be: |
679 |
|
680 |
HTTP/1.1 200 OK |
681 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
682 |
Content-Type: text/html |
683 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
684 |
Content-Length: 5327 |
685 |
Cache-control: max-age=604800 |
686 |
Content-Location: paper.html.en |
687 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
688 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
689 |
{"paper.ps.en" 1.0 {type application/postscript} |
690 |
{language en}} |
691 |
Etag: "gonkyyyy;1234" |
692 |
Vary: negotiate, accept, accept-language |
693 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
694 |
|
695 |
<title>A paper about .... |
696 |
|
697 |
Finally, the above two kinds of optimization can be combined; a |
698 |
caching proxy which has the list will sometimes be able to choose on |
699 |
behalf of the user agent. This could lead to the following |
700 |
communication pattern: |
701 |
|
702 |
Server _____ proxy _____ proxy __________ user |
703 |
x.org cache cache agent |
704 |
|
705 |
< --------------- |
706 |
| GET ../paper |
707 |
| small Accept |
708 |
| |
709 |
able to choose |
710 |
on behalf |
711 |
| |
712 |
< ---------- |
713 |
| GET ../paper.html.en |
714 |
| |
715 |
---------- > [normal response] |
716 |
html.en | |
717 |
---------------- > [choice response] |
718 |
html.en and list |
719 |
|
720 |
In this case the proxy cache nearest to the user agent has |
721 |
a cached variant list, and chooses on behalf of the user agent. |
722 |
|
723 |
Note that this cutting of corners does not only save bandwidth. It |
724 |
also eliminates delays due to packet round trip times, and reduces |
725 |
the load on the origin server. |
726 |
|
727 |
|
728 |
4.4B Downwards compatibility with non-negotiating user agents |
729 |
|
730 |
To handle requests from user agents not capable of transparent |
731 |
content negotiation, transparent content negotiation basically |
732 |
reverts to a HTTP/1.0 style negotiation scheme. One optimization |
733 |
remaining is that proxy caches may sometimes be able to perform |
734 |
HTTP/1.0 style negotiation on behalf of the origin server. |
735 |
|
736 |
|
737 |
4.5 Retrieving a variant by hand |
738 |
|
739 |
If a transparently negotiated resource is accessed, the user agent |
740 |
will always at some point receive the list of available variants. |
741 |
The user agent can use this list to make available a menu (in HTML or |
742 |
not) of all variants and their characteristics to the user. |
743 |
Such a menu can allow the user to randomly browse other variants, |
744 |
and can make it possible to manually correct any sub-optimal |
745 |
choice made by the automatic negotiation process. |
746 |
|
747 |
|
748 |
4.6 Dimensions of negotiation |
749 |
|
750 |
Transparent content negotiation defines four dimensions of |
751 |
negotiation: |
752 |
|
753 |
1. Media type (MIME type) |
754 |
2. Charset |
755 |
3. Language |
756 |
4. Features |
757 |
|
758 |
The first three dimensions have traditionally been present in HTTP. |
759 |
The fourth dimension is added by this specification. Additional |
760 |
dimensions, beyond the four mentioned above, could be added by |
761 |
future specifications. |
762 |
|
763 |
Negotiation on the content encoding of a response (gzipped, |
764 |
compressed, etc.) is left outside of the realm of transparent |
765 |
negotiation. See Section 10.6 for more information. |
766 |
|
767 |
[##Note: In earlier versions of this specification, content |
768 |
encoding was a regular dimension in transparent content |
769 |
negotiation. It was removed mainly because negotiation on |
770 |
content encoding can be done on a hop-by-hop basis under HTTP/1.1 |
771 |
[1].##] |
772 |
|
773 |
|
774 |
4.7 Feature negotiation |
775 |
|
776 |
Feature negotiation intends to provide for all areas of negotiation |
777 |
not covered by the type, charset, and language dimensions. |
778 |
Examples are negotiation on |
779 |
|
780 |
* HTML extensions |
781 |
* Extensions of other media types |
782 |
* Color capabilities of the user agent |
783 |
* Screen size |
784 |
* Output medium (screen, paper, ...) |
785 |
* Preference for speed vs. preference for graphical detail |
786 |
|
787 |
The feature negotiation framework is the principal means by which |
788 |
transparent negotiation offers extensibility; a new dimension of |
789 |
negotiation (really a sub-dimension of the feature dimension) can be |
790 |
added without the need for a new standards effort by the simple |
791 |
registration of a `feature tag'. Feature registration is discussed |
792 |
in Section 8. |
793 |
|
794 |
|
795 |
5 Variant descriptions |
796 |
|
797 |
5.1 Syntax |
798 |
|
799 |
A variant can be described in a machine-readable way with a variant |
800 |
description. |
801 |
|
802 |
variant-description = |
803 |
"{" <"> URI <"> source-quality *variant-attribute "}" |
804 |
|
805 |
source-quality = qvalue |
806 |
|
807 |
variant-attribute = "{" "type" media-type "}" |
808 |
| "{" "charset" charset "}" |
809 |
| "{" "language" 1#language-tag "}" |
810 |
| "{" "length" 1*DIGIT "}" |
811 |
| "{" "features" feature-list "}" |
812 |
| "{" "description" quoted-string "}" |
813 |
| extension-attribute |
814 |
|
815 |
extension-attribute = "{" extension-name extension-value "}" |
816 |
extension-name = token |
817 |
extension-value = *( token | quoted-string | LWS |
818 |
| extension-specials ) |
819 |
|
820 |
extension-specials = <any element of tspecials except <"> and "}"> |
821 |
|
822 |
Examples are |
823 |
|
824 |
{"paper.html.fr" 0.7 {type text/html} {language fr}} |
825 |
|
826 |
{"paper.html.tables" 0.9 {type text/html} {features tables}} |
827 |
|
828 |
The various attributes which can be present in a variant |
829 |
description are covered in the subsections below. Each attribute |
830 |
may appear only once in a variant description. |
831 |
|
832 |
|
833 |
5.2 URI |
834 |
|
835 |
The URI attribute gives the URI of the resource from which the |
836 |
variant can be retrieved with a GET request. It can be absolute or |
837 |
relative to the Request-URI. The variant resource may vary (on the |
838 |
Cookie request header, for example), but must not engage in |
839 |
transparent content negotiation itself. |
840 |
|
841 |
|
842 |
5.3 Source-quality |
843 |
|
844 |
The source-quality attribute gives the quality of the variant, as a |
845 |
representation of the negotiable resource, when this variant is |
846 |
rendered with a perfect rendering engine on the best possible |
847 |
output medium. |
848 |
|
849 |
If the source-quality is less than 1, it often expresses a quality |
850 |
degradation caused by a lossy conversion to a particular data |
851 |
format. For example, a picture originally in JPEG form would have |
852 |
a lower source quality when translated to the XBM format, and a |
853 |
much lower source quality when translated to an ASCII-art variant. |
854 |
Note however, that degradation is a function of the source; an |
855 |
original piece of ASCII-art may degrade in quality if it is |
856 |
captured in JPEG form. |
857 |
|
858 |
The source-quality could also represent a level of quality |
859 |
caused by skill of language translation, ability of a feature |
860 |
set to capture an artistic expression, or clarity of mathematical |
861 |
expression using a particular character set. |
862 |
|
863 |
It is important that content providers do not assign very low |
864 |
source quality values without good reason, as this would limit the |
865 |
ability of users to influence the negotiation process with their |
866 |
own preference settings. The following table should be used as a |
867 |
guide when assigning source quality values: |
868 |
|
869 |
1.000 perfect representation |
870 |
0.999-0.900 near threshold of noticeable loss of quality |
871 |
0.899-0.700 noticeable, but acceptable quality reduction |
872 |
0.699-0.500 barely acceptable quality |
873 |
0.499-0.000 severely degraded quality |
874 |
|
875 |
Note that most meaningful values in this table are close to 1. |
876 |
This is due to the fact that quality factors are combined by |
877 |
multiplying them, not by adding them. |
878 |
|
879 |
When assigning source-quality values, content providers must not |
880 |
account for the size of the variant and its impact on transmission |
881 |
and rendering delays. Source-quality values are assigned assuming |
882 |
instantaneous transmission and rendering. This rule ensures that a |
883 |
future mechanism for bandwidth negotiation (see Appendix 19.5.2) |
884 |
can be cleanly added. |
885 |
|
886 |
|
887 |
5.4 Type, language, length, and charset. |
888 |
|
889 |
The type, language, and length attributes of a variant description |
890 |
can carry the same information as their Content-* response header |
891 |
counterparts as defined in [1]. The counterpart of the charset |
892 |
attribute is the charset parameter which can be present in the |
893 |
Content-Type response header, for example |
894 |
|
895 |
Content-Type: text/html; charset=ISO-8859-4 |
896 |
|
897 |
Though all of these attributes are optional, it is often desirable |
898 |
to include as many attributes as possible as this will increase the |
899 |
quality of the negotiation process. |
900 |
|
901 |
The length attribute (if present) must reflect the length of the |
902 |
variant alone, and not the sum of the lengths of the variant and |
903 |
any objects inlined or embedded by the variant. |
904 |
|
905 |
Note: A server is not required to maintain a one-to-one |
906 |
correspondence between attributes in the description of a |
907 |
variant and the Content-* headers in responses containing that |
908 |
variant. Examples: If the variant description contains a |
909 |
language attribute, the response does not necessarily have to |
910 |
contain a Content-Language header. If a Content-Language |
911 |
header is present, it does not have to contain an exact copy of |
912 |
the information in the language attribute. |
913 |
|
914 |
|
915 |
5.5 Features |
916 |
|
917 |
The features attribute specifies how the presence or absence of |
918 |
particular features in the user agent affects the overall quality of |
919 |
the variant. This attribute is covered in Section 6.4. |
920 |
|
921 |
|
922 |
5.6 Description |
923 |
|
924 |
The description attribute gives a textual description of the |
925 |
variant. It can be included if the URI and normal attributes of a |
926 |
variant are considered too opaque to allow interpretation by the |
927 |
user. If a user agent is showing a menu of available variants |
928 |
compiled from a variant list, and if a variant has a description |
929 |
attribute, the user agent should show the description attribute of |
930 |
the variant instead of showing the normal attributes of the |
931 |
variant. |
932 |
|
933 |
|
934 |
5.7 Extension-attribute |
935 |
|
936 |
The extension-attribute allows future specifications to |
937 |
incrementally define new dimensions of negotiation, and eases |
938 |
content negotiation experiments under HTTP/1.1. In experimental |
939 |
situations, servers must only generate extension-attributes whose |
940 |
names start with "x-". User agents should ignore all extension |
941 |
attributes they do not recognize. Proxies must not run the network |
942 |
negotiation algorithm if an unknown extension attribute is present |
943 |
in the variant list. |
944 |
|
945 |
|
946 |
6 Feature negotiation |
947 |
|
948 |
Feature negotiation has been introduced in Section 4.7. This |
949 |
section defines the feature negotiation mechanism. Section 7 |
950 |
contains examples of its use. |
951 |
|
952 |
|
953 |
6.1 Feature tags |
954 |
|
955 |
A feature tag (ftag) identifies a capability of a user agent or a |
956 |
preference of a user. A feature is said to be `present' in a user |
957 |
agent if the corresponding capability is implemented, or if the |
958 |
user has expressed corresponding preference. |
959 |
|
960 |
ftag = 1*<any CHAR except CTLs or tspecials or "!"> |
961 |
|
962 |
tspecials = "(" | ")" | "<" | ">" | "@" |
963 |
| "," | ";" | ":" | "\" | <"> |
964 |
| "/" | "[" | "]" | "?" | "=" |
965 |
| "{" | "}" | SP | HT |
966 |
|
967 |
(tspecials definition reproduced from [1]) |
968 |
|
969 |
Examples are |
970 |
|
971 |
tables, fonts, blebber, wolx, screenwidth, colordepth |
972 |
|
973 |
An example of the use of feature tags in a variant description is: |
974 |
|
975 |
{"index.html" 1.0 {type text/html} {features tables frames}} |
976 |
|
977 |
Feature-tags are case-insensitive. The definition of a feature tag |
978 |
may state that a feature tag, if present, can have associated with |
979 |
it one or more values which reflect a particular capability or |
980 |
preference. For example, a feature tag `paper' could be present |
981 |
with the values `A4' and `A5'. |
982 |
|
983 |
Note that context may determine whether a feature tag expresses a |
984 |
capability or a preference. The `textonly' tag is naturally |
985 |
present for a text-only browser, but the user of a graphical |
986 |
browser could set the tag to be present if text-only content is |
987 |
preferred to graphical content. |
988 |
|
989 |
As feature registration will be an ongoing process, it is generally |
990 |
not possible for a user agent to know the meaning of all feature |
991 |
tags it can possibly encounter in a variant description. A user |
992 |
agent should treat all features with tags unknown to it as absent. |
993 |
|
994 |
|
995 |
6.2 Accept-Features header |
996 |
|
997 |
The Accept-Features request header can be used by a client to give |
998 |
information about the presence or absence of certain features. |
999 |
|
1000 |
Accept-Features = "Accept-Features" ":" |
1001 |
#( feature-expr *( ";" feature-extension ) ) |
1002 |
|
1003 |
feature-expr = [ "!" ] ftag [ "=" tag-value ] |
1004 |
| ftag "=" "{" tag-value "}" |
1005 |
| ftag "<=" number |
1006 |
| ftag "=" "<" numeric-range ">" |
1007 |
| "*" |
1008 |
|
1009 |
tag-value = token | quoted-string |
1010 |
|
1011 |
number = 1*DIGIT |
1012 |
|
1013 |
numeric-range = [ number ] "-" [ number ] |
1014 |
|
1015 |
feature-extension = token [ "=" ( token | quoted-string ) ] |
1016 |
|
1017 |
[##Note: an earlier version of this specification did not allow |
1018 |
quoted strings as values. Quoted strings were added because |
1019 |
they make it easier to map existing negotiation dimensions and |
1020 |
formats onto the feature negotiation framework.##] |
1021 |
|
1022 |
Tag values must be compared case-insensitively, and a token value |
1023 |
XYZ is equal to a quoted-string value "XYZ". No feature extensions |
1024 |
are defined in this specification. An example is: |
1025 |
|
1026 |
Accept-Features: blex, !blebber, colordepth<=5, !screenwidth, |
1027 |
UA-media={stationary}, paper=a4, !paper="a0", |
1028 |
x_version=<100-205>, * |
1029 |
|
1030 |
The different feature expressions have the following meaning: |
1031 |
|
1032 |
ftag ftag is present |
1033 |
|
1034 |
!ftag ftag is absent |
1035 |
|
1036 |
ftag=V ftag is present with the value V |
1037 |
|
1038 |
!ftag=V ftag is present, but not with the value V |
1039 |
|
1040 |
ftag={V} ftag is present with the value V, and not with any |
1041 |
other values |
1042 |
|
1043 |
ftag<=N ftag is present with the numeric values from 0 up to |
1044 |
and including N, and not with any other values |
1045 |
|
1046 |
ftag=<N-M> ftag is present with the numeric values from N up to |
1047 |
and including M, and not with any other values. If N |
1048 |
is missing, the lower bound is 0. If M is missing, |
1049 |
the upper bound is infinity. |
1050 |
|
1051 |
* makes true all feature predicates (Section 6.3) which |
1052 |
were not assigned truth values by other elements of |
1053 |
the header |
1054 |
|
1055 |
[##Question to be resolved: is there an alternative to the |
1056 |
ftag=<N-M> notation which looks nicer? We can't use ftag=N-M |
1057 |
because it would be syntactically ambiguous with ftag=V: N-M is |
1058 |
also a HTTP token value. Maybe tag@N-M is a nicer notation.##] |
1059 |
|
1060 |
Absence of the Accept-Features header in a request is equivalent to |
1061 |
the inclusion of |
1062 |
|
1063 |
Accept-Features: * |
1064 |
|
1065 |
[##Note: One possible use of the feature-extensions would be the |
1066 |
introduction of quality values on feature tags, see Appendix |
1067 |
19.3C##] |
1068 |
|
1069 |
|
1070 |
6.3 Feature predicates |
1071 |
|
1072 |
Feature predicates are used in the features attribute of a variant |
1073 |
description. |
1074 |
|
1075 |
fpred = [ "!" ] ftag [ "=" tag-value ] |
1076 |
| ftag "=" "<" numeric-range ">" |
1077 |
|
1078 |
Examples of feature predicates are |
1079 |
|
1080 |
blebber, !blebber, paper=a4, colordepth=5, !blex=54, |
1081 |
dpi=<300-599>, colordepth=<24-> |
1082 |
|
1083 |
The network negotiation algorithm can compute the truth value of a |
1084 |
feature predicate by using the contents of the Accept-Features |
1085 |
header of the current request. |
1086 |
|
1087 |
The truth value of a predicate is assigned as follows, depending on |
1088 |
its form, by using the information in the Accept-Features |
1089 |
header: |
1090 |
|
1091 |
ftag true if the feature is known to be present |
1092 |
|
1093 |
false if the feature is known to be absent |
1094 |
|
1095 |
!ftag true if the feature is known to be absent |
1096 |
|
1097 |
false if the feature is known to be present |
1098 |
|
1099 |
ftag=V true if the feature is known to be present with |
1100 |
the value V, |
1101 |
|
1102 |
false if the feature is known not to be present with |
1103 |
the value V |
1104 |
|
1105 |
!ftag=V true if the feature is known to be present, but known |
1106 |
not to be present with the value V, |
1107 |
|
1108 |
false if the feature is known to be absent or present |
1109 |
with the value V |
1110 |
|
1111 |
ftag=<N-M> true if the feature is known to be present with some |
1112 |
numeric values, while the highest value with which it |
1113 |
is present is known and in the range N-M, |
1114 |
|
1115 |
false if the feature is known to be absent, or if it |
1116 |
is known to be present with some numeric values, |
1117 |
while the highest value with which it is present is |
1118 |
known and not in the range N-M. |
1119 |
|
1120 |
If N is missing, the lower bound is 0. If M is |
1121 |
missing, the upper bound is infinity. |
1122 |
|
1123 |
If the information in the Accept-Features header does not provide |
1124 |
sufficient knowledge to assign a value to a predicate using the |
1125 |
above rules, then the value is true if there is a "*" in the |
1126 |
Accept-Features header, false otherwise. |
1127 |
|
1128 |
As an example, the header |
1129 |
|
1130 |
Accept-Features: blex, !blebber, colordepth<=5, !screenwidth, |
1131 |
UA-media={stationary}, paper=a4, !paper="a0", |
1132 |
x_version=<100-205>, * |
1133 |
|
1134 |
makes the following predicates true: |
1135 |
|
1136 |
blex, colordepth=4, !colordepth=6, colordepth, !screenwidth, |
1137 |
UA-media=stationary, !UA-media=screen, paper=a4, !paper=a0, |
1138 |
colordepth=<4-6>, !colordepth=<10->, x_version="101", |
1139 |
blex=wox, !blex=wox, paper=a5, |
1140 |
frtnbf, !frtnbf, frtnbf=4, !frtnbf=4, frtnbf=<1-42> |
1141 |
|
1142 |
and makes the following predicates false: |
1143 |
|
1144 |
!blex, blebber, colordepth=6, colordepth=foo, !colordepth, |
1145 |
screenwidth, screenwidth=640, !screenwidth=640, x_version=99, |
1146 |
UA-media=screen, paper=a0 |
1147 |
|
1148 |
|
1149 |
6.4 Features attribute |
1150 |
|
1151 |
The features attribute |
1152 |
|
1153 |
"{" "features" feature-list "}" |
1154 |
|
1155 |
is used in a variant description to specify how the presence or |
1156 |
absence of particular features in the user agent affects the overall |
1157 |
quality of the variant. |
1158 |
|
1159 |
feature-list = 1%feature-list-element |
1160 |
|
1161 |
feature-list-element = ( fpred | fpred-bag ) |
1162 |
[ ":" true-improvement ] |
1163 |
[ "/" false-degradation ] |
1164 |
|
1165 |
fpred-bag = "[" 1%fpred "]" |
1166 |
|
1167 |
true-improvement = 1*3DIGIT [ "." 0*3DIGIT ] |
1168 |
false-degradation = 1*3DIGIT [ "." 0*3DIGIT ] |
1169 |
|
1170 |
Examples are: |
1171 |
|
1172 |
{features !textonly [blebber !wolx] colordepth=3:0.7 } |
1173 |
|
1174 |
{features !blink/0.5 background:1.5 [blebber !wolx]:1.4/0.8 } |
1175 |
|
1176 |
The default value for the true-improvement is 1. The default value |
1177 |
for the false-degradation is 0, or 1 if a true-improvement value is |
1178 |
given. |
1179 |
|
1180 |
The network negotiation algorithm can compute the quality |
1181 |
degradation factor associated with the features attribute by |
1182 |
multiplying all quality degradation factors of the elements of the |
1183 |
feature-list. Note that the result can be a factor greater than 1. |
1184 |
|
1185 |
A feature list element yields its true-improvement factor if the |
1186 |
corresponding feature predicate is true, or if at least one element |
1187 |
of the corresponding fpred-bag is true. The element yields its |
1188 |
false-degradation factor otherwise. |
1189 |
|
1190 |
[##Note: The attribute grammar above was designed to be parseable |
1191 |
with simple non-recursive parsers. The true-improvement construct |
1192 |
does not add expressive power in a theoretical sense, but does make |
1193 |
the (automatic) construction of variant lists more straightforward |
1194 |
in many cases.##] |
1195 |
|
1196 |
[##Aside for mathematicians: note the similarity between the |
1197 |
feature-list |
1198 |
|
1199 |
[f1 !f2] [!f1 f3] |
1200 |
|
1201 |
and the conjunctive normal form of a boolean expression. This |
1202 |
similarity implies good things about the expressive power of the |
1203 |
features attribute.##] |
1204 |
|
1205 |
|
1206 |
7 Feature negotiation examples |
1207 |
|
1208 |
This section contains examples of the use of feature tags in |
1209 |
variant descriptions. |
1210 |
|
1211 |
[##Note: A future version of this document will probably revise and |
1212 |
extend this section.##] |
1213 |
|
1214 |
|
1215 |
7.1 Use of feature tags |
1216 |
|
1217 |
Feature tags can be used in variant lists to express the quality |
1218 |
degradation associated with the presence or absence of certain |
1219 |
features. One example is |
1220 |
|
1221 |
{"index.html.plain" 0.7 }, |
1222 |
{"index.html" 1.0 {features tables frames}} |
1223 |
|
1224 |
Here, the "{features tables frames}" part expresses that index.html |
1225 |
uses the features tagged as tables and frames. If these features |
1226 |
are absent, the overall quality of index.html degrades to 0. |
1227 |
Another example is |
1228 |
|
1229 |
{"home.graphics" 1.0 {features !textonly}}, |
1230 |
{"home.textonly" 0.7 } |
1231 |
|
1232 |
where the "{features !textonly}" part expresses that home.graphics |
1233 |
requires the absence of the textonly feature. If the feature is |
1234 |
present, the overall quality of home.graphics degrades to 0. |
1235 |
|
1236 |
The absence of a feature need not always degrade the overall quality |
1237 |
to 0. In the example |
1238 |
|
1239 |
{"x.html.1" 1.0 {features fonts/0.7}} |
1240 |
|
1241 |
the absence of the fonts feature degrades the quality with a factor |
1242 |
of 0.7. "fonts/0.7" can be pronounced as "fonts, or a degradation of |
1243 |
0.7". In the example |
1244 |
|
1245 |
{"x.html.2" 0.5 {features fonts:1.5}} |
1246 |
|
1247 |
the presence of the fonts feature improves the overall quality with a |
1248 |
factor of 1.5. If the fonts feature is absent, the overall quality is |
1249 |
not affected. "fonts:1.5" can be pronounced as "fonts improves with |
1250 |
1.5". Finally, in the example |
1251 |
|
1252 |
{"y.html" 1.0 {features [blebber wolx] }} |
1253 |
|
1254 |
The "[blebber wolx]" expresses that y.html requires the presence of |
1255 |
the blebber feature or the wolx feature. This construct can be |
1256 |
used in a number of cases: |
1257 |
|
1258 |
1. blebber and wolx actually tag the same feature, but they |
1259 |
were registered by different people, and some browsers say |
1260 |
they support blebber while others say they support wolx. |
1261 |
|
1262 |
2. blebber and wolx are HTML tags of different vendors which |
1263 |
implement the same functionality, and which were used |
1264 |
together in y.html without interference. |
1265 |
|
1266 |
3. blebber and wolx are HTML tags of different vendors which |
1267 |
implement the same functionality, and y.html uses the tags in |
1268 |
a conditional HTML construct. |
1269 |
|
1270 |
4. blebber is a complicated HTML tag with only a sketchy |
1271 |
definition, implemented by one browser vendor, and wolx |
1272 |
indicates implementation of a well-defined subset of the blebber |
1273 |
tag by some other vendor(s). y.html uses only this well-defined |
1274 |
subset. |
1275 |
|
1276 |
|
1277 |
7.2 Use of numeric feature tags |
1278 |
|
1279 |
As an example of negotiation in a numeric area, the following |
1280 |
variant list describes four variants with title graphics designed |
1281 |
for increasing screen widths: |
1282 |
|
1283 |
{"home.pda" 1.0 {features pagewidth=<-199> }}, |
1284 |
{"home.narrow" 1.0 {features pagewidth=<200-599> }}, |
1285 |
{"home.normal" 1.0 {features pagewidth=<600-999> }}, |
1286 |
{"home.wide" 1.0 {features pagewidth=<1000-> }} |
1287 |
|
1288 |
The accept header |
1289 |
|
1290 |
Accept-Features: pagewidth<=250, * |
1291 |
|
1292 |
which indicates that the pagewidth tag is present with the |
1293 |
numeric values from 0 up to and including 250, makes the following |
1294 |
feature predicates false: |
1295 |
|
1296 |
pagewidth=<-199> pagewidth=<600-999> pagewidth=<1000-> |
1297 |
|
1298 |
and thereby degrades the overall quality of all above variants |
1299 |
except home.narrow to 0. The above variant list has a serious |
1300 |
problem, however: a user agent not supporting pagewidth |
1301 |
negotiation is given no guidance on which variant to select. The |
1302 |
header |
1303 |
|
1304 |
Accept-Features: !pagewidth, * |
1305 |
|
1306 |
degrades the overall quality of all above variants to 0. |
1307 |
|
1308 |
A variant list which solves this problem is |
1309 |
|
1310 |
{"home.pda" 1.0 {features pagewidth=<-199> }}, |
1311 |
{"home.narrow" 1.0 {features pagewidth=<200-599> }}, |
1312 |
{"home.normal" 0.99 }, |
1313 |
{"home.wide" 1.0 {features pagewidth=<1000-> }} |
1314 |
|
1315 |
With this list, a user agent which does not support the pagewidth |
1316 |
feature will always select the home.normal variant. Another |
1317 |
solution would be to describe the normal variant as: |
1318 |
|
1319 |
{"home.normal" 1.0 {features [pagewidth=<600-999> !pagewidth] }} |
1320 |
|
1321 |
|
1322 |
8 Feature tag registration |
1323 |
|
1324 |
Feature tag registration procedures are defined in [4]. Note that |
1325 |
the feature tag names in the examples of this specification do not |
1326 |
in general reflect the tag naming schemes proposed in [4]. |
1327 |
|
1328 |
|
1329 |
8.1 Evolution of feature tags |
1330 |
|
1331 |
The feature negotiation mechanism is designed not to break if 1000+ |
1332 |
features, partially overlapping, are registered. This allows for |
1333 |
feature tag creation to be an evolutionary process, in which many |
1334 |
tags are created while only a few `survive' to become generally |
1335 |
used. |
1336 |
|
1337 |
As the development of new web content formats is currently in an |
1338 |
evolutionary phase, rather than a standardization phase, it is |
1339 |
thought that this evolutionary approach to feature tag creation has |
1340 |
the best chances of keeping up with new developments. |
1341 |
|
1342 |
|
1343 |
8.2 Core set of feature tags |
1344 |
|
1345 |
[##In order to jump-start feature negotiation, it seems useful to |
1346 |
define a `core set' of feature tags in a separate document. These |
1347 |
feature tags would cover the areas of negotiation which are |
1348 |
currently well understood, like negotiation on currently stable |
1349 |
HTML extensions. The transparent content negotiation specification |
1350 |
could then require (or strongly encourage) that user agents |
1351 |
implementing transparent content negotiation must recognize (not |
1352 |
support!) all tags in the core set. |
1353 |
|
1354 |
The core set will be proposed in a non-standards track document |
1355 |
which will be completed along with this document.##] |
1356 |
|
1357 |
|
1358 |
8.3 Feature tag design |
1359 |
|
1360 |
When designing a new feature tag, it is important to take into |
1361 |
account that existing user agents which do not recognize the new |
1362 |
tag will treat the feature as absent. In general, a new feature |
1363 |
tag needs to be designed in such a way that absence of the tag is |
1364 |
the default case which reflects current practice. If this design |
1365 |
principle is ignored, the resulting feature tag will generally be |
1366 |
unusable. |
1367 |
|
1368 |
As an example, one could try to support negotiation between |
1369 |
monochrome and color content by introducing a `color' feature tag, |
1370 |
the presence of which would indicate the capability to display |
1371 |
color graphics. However, if this new tag is used in a variant |
1372 |
list, for example |
1373 |
|
1374 |
{"rainbow.gif" 1.0 {features color} } |
1375 |
{"rainbow.mono.gif" 0.6 {features !color}} |
1376 |
|
1377 |
then existing user agents, which would not recognize the color tag, |
1378 |
would all display the monochrome rainbow. The color tag is |
1379 |
therefore unusable in situations where optimal results for existing |
1380 |
user agents are desired. To provide for negotiation in this area, |
1381 |
one must introduce a `monochrome' feature tag; its presence |
1382 |
indicates that the user agent can only render (or the user prefers |
1383 |
to view) monochrome graphics. |
1384 |
|
1385 |
|
1386 |
9 Content negotiation response codes and headers |
1387 |
|
1388 |
This specification adds one new response code to those defined in |
1389 |
HTTP/1.1 [1]. This is a 5xx (Server Error) class response. It |
1390 |
also adds six new headers. |
1391 |
|
1392 |
|
1393 |
9.1 506 Variant Also Negotiates |
1394 |
|
1395 |
The server has an internal configuration error; the chosen variant |
1396 |
resource is configured to engage in transparent content negotiation |
1397 |
itself, and is therefore not a proper end point in the negotiation |
1398 |
process. |
1399 |
|
1400 |
|
1401 |
9.2 Accept-Features |
1402 |
|
1403 |
This request header was defined in Section 6.2. |
1404 |
|
1405 |
|
1406 |
9.3 Content-Features |
1407 |
|
1408 |
The Content-Features response header can be used by a server to |
1409 |
indicate how the presence or absence of particular features in the |
1410 |
user agent affects the overall quality of the response. |
1411 |
|
1412 |
Content-Features = "Content-Features" ":" feature-list |
1413 |
|
1414 |
|
1415 |
9.4 Alternates |
1416 |
|
1417 |
The Alternates response header is used to convey the list of |
1418 |
variants bound to a negotiable resource in a response. It can also |
1419 |
contain other directives for the content negotiation process. |
1420 |
|
1421 |
Alternates = "Alternates" ":" 1#( variant-description |
1422 |
| alternates-directive ) |
1423 |
|
1424 |
alternates-directive = ( "min-q" "=" short-float ) |
1425 |
| extension-alternates-directive |
1426 |
|
1427 |
delta-seconds = 1*DIGIT |
1428 |
|
1429 |
short-float = 1*3DIGIT [ "." 0*3DIGIT ] |
1430 |
|
1431 |
extension-alternates-directive = |
1432 |
token [ "=" ( token | quoted-string ) ] |
1433 |
|
1434 |
An example is |
1435 |
|
1436 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1437 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1438 |
{"paper.ps.en" 1.0 {type application/postscript} |
1439 |
{language en}}, |
1440 |
min-q=0.4 |
1441 |
|
1442 |
Any relative URI specified in a variant-description field is |
1443 |
relative to the request-URI. The min-q directive, if present, can |
1444 |
influence decisions made by the network negotiation algorithm on |
1445 |
behalf of the origin server. Clients should ignore all |
1446 |
extension-alternates-directives they do not understand. |
1447 |
|
1448 |
A variant list may contain multiple differing descriptions of the |
1449 |
same variant. This can be convenient if the variant uses |
1450 |
conditional rendering constructs, or if the variant resource |
1451 |
returns multiple representations using a multipart media type. |
1452 |
|
1453 |
|
1454 |
9.6 Negotiate |
1455 |
|
1456 |
The Negotiate request header can contain directives for any content |
1457 |
negotiation process initiated by the request. Presence of the |
1458 |
`trans' directive in this header indicates that the user agent |
1459 |
supports transparent content negotiation for the current request. |
1460 |
|
1461 |
Negotiate = "Negotiate" ":" 1#negotiate-directive |
1462 |
|
1463 |
negotiate-directive = "trans" | negotiate-extension |
1464 |
|
1465 |
negotiate-extension = token [ "=" token ] |
1466 |
|
1467 |
An example is |
1468 |
|
1469 |
Negotiate: trans |
1470 |
|
1471 |
Servers should ignore all negotiate-directives they do not |
1472 |
understand. The presence of a `trans' directive is significant in |
1473 |
calculations performed by the network negotiation algorithm. |
1474 |
|
1475 |
[#Note: The name `trans' is a compromise between the long |
1476 |
`transparent' and the short `t'. The HTTP-WG is divided on the |
1477 |
naming issue, and `trans' was chosen to minimize overall |
1478 |
unhappiness. The WG will only be truly happy if a shorter synonym |
1479 |
of `negotiate' can be found.##] |
1480 |
|
1481 |
|
1482 |
9.7 Variant-Vary |
1483 |
|
1484 |
The Variant-Vary response header can be used in a list response to |
1485 |
record any vary information which applies to the variant data |
1486 |
contained in the response, rather than to the response as a whole. |
1487 |
|
1488 |
Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name ) |
1489 |
|
1490 |
Use of the Variant-Vary header is discussed in Section 10.2. |
1491 |
|
1492 |
|
1493 |
9B Cache validators |
1494 |
|
1495 |
To allow for correct and efficient caching and revalidation of |
1496 |
negotiated responses, this specification extends the caching model |
1497 |
of HTTP/1.1 [1] in various ways. |
1498 |
|
1499 |
Under the rules in this specification, the maximal age (time since |
1500 |
last revalidation) of a variant list bound to a negotiable |
1501 |
resource, as received from a cache in an Alternates header, is the |
1502 |
maximum of |
1503 |
|
1504 |
1. the freshness lifetimes (max-age values) in the responses |
1505 |
from the negotiable resource itself, and |
1506 |
|
1507 |
2. the freshness lifetimes (max-age values) of the variant |
1508 |
resources of the negotiable resource which are also neighbors |
1509 |
of the negotiable resource. |
1510 |
|
1511 |
If no freshness lifetimes are assigned by the origin server, the |
1512 |
maximal age of a variant list is the maximum of the freshness |
1513 |
lifetime values which were heuristically assigned by the cache. |
1514 |
|
1515 |
|
1516 |
9B.1 Variant list validators |
1517 |
|
1518 |
A variant list validator is an opaque value which acts as the cache |
1519 |
validator of a variant list bound to a negotiable resource. |
1520 |
|
1521 |
variant-list-validator = <quoted-string not containing any ";"> |
1522 |
|
1523 |
If two responses contain the same variant list validator, a cache |
1524 |
can treat the Alternates headers in these responses as equivalent |
1525 |
(though the headers themselves need not be identical). |
1526 |
|
1527 |
|
1528 |
9B.2 Structured entity tags |
1529 |
|
1530 |
A structured entity tag consists of a normal entity tag of which |
1531 |
the opaque string is extended with a semicolon followed by a |
1532 |
variant list validator: |
1533 |
|
1534 |
normal | variant list | structured |
1535 |
entity tag | validator | entity tag |
1536 |
-------------+----------------+----------------- |
1537 |
"etag" | "vlv" | "etag;vlv" |
1538 |
W/"etag" | "vlv" | W/"etag;vlv" |
1539 |
|
1540 |
Note that a structured entity tag is itself also an entity tag. |
1541 |
The structured nature of the tag allows caching proxies capable of |
1542 |
transparent content negotiation to perform certain optimizations. |
1543 |
Examples of structured entity tags are: |
1544 |
|
1545 |
"xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234" |
1546 |
|
1547 |
In the last example, the normal entity tag is "a;b;c;" and the |
1548 |
variant list validator is "1234". |
1549 |
|
1550 |
If a transparently negotiated response includes an entity tag, it |
1551 |
must be a structured entity tag. The variant list validator in the |
1552 |
structured tag must act as a validator for the variant list |
1553 |
contained in the Alternates header. The normal entity tag in the |
1554 |
structured tag must act as a validator of the entity body in the |
1555 |
response and of all entity headers except Alternates. |
1556 |
|
1557 |
|
1558 |
9B.3 Assigning entity tags to variants |
1559 |
|
1560 |
To ensure the correct revalidation of transparently negotiated |
1561 |
responses, origin servers should maintain some uniqueness |
1562 |
requirements when assigning entity tags to variant resources. |
1563 |
|
1564 |
First, two different variant resources of the same negotiable |
1565 |
resource, which are both neighbors of this negotiable resource, may |
1566 |
never use the same (normal) entity tag, even not at different |
1567 |
times, unless this tag labels exactly the same entity on all |
1568 |
occasions. |
1569 |
|
1570 |
Second, the server should ensure that, if a normal entity tag of a |
1571 |
neighboring variant resource is extended to a structured tag, this |
1572 |
structured tag never equals a different normal entity tag used by |
1573 |
another variant or at another time. An easy way to ensure this is |
1574 |
by never including a semicolon in a normal tag. |
1575 |
|
1576 |
|
1577 |
10 Content negotiation responses |
1578 |
|
1579 |
If a request on a transparently negotiated resource yields a |
1580 |
response with a 2xx status code or any 3xx status code except 304, |
1581 |
this response must always be either a list response, a choice |
1582 |
response, or an ad hoc response. These responses always include |
1583 |
the Alternates header bound to the negotiable resource. |
1584 |
|
1585 |
Transparently negotiated responses with other status codes may also |
1586 |
include an Alternates header, if this is allowed by the HTTP/1.1 |
1587 |
specification [1]. Note that HTTP/1.1 does not allow an Alternates |
1588 |
header in a 304 (Not Modified) response. When generating a |
1589 |
response from a resource which does not support transparent content |
1590 |
negotiation, a server must never include an Alternates header. |
1591 |
|
1592 |
A list response always has the 300 (Multiple Choices) response |
1593 |
code. A choice response never has the 300 code, and always has a |
1594 |
Content-Location header. An ad hoc response never has the 300 |
1595 |
code, and never has a Content-Location header. |
1596 |
|
1597 |
10.1 List response |
1598 |
|
1599 |
A list response has the 300 response status code. It must contain |
1600 |
(besides the normal headers required by HTTP) the Alternates header |
1601 |
bound to the negotiable resource, a Vary header and (unless it was |
1602 |
a HEAD request) an entity body which allows the user to manually |
1603 |
select the best variant. It is generated as a response to a user |
1604 |
agent capable of transparent content negotiation if the server does |
1605 |
not (perhaps cannot) choose a particular best variant for the |
1606 |
request. |
1607 |
|
1608 |
An example of a list response is |
1609 |
|
1610 |
HTTP/1.1 300 Multiple Choices |
1611 |
Date: Tue, 11 Jun 1996 20:02:21 GMT |
1612 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1613 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1614 |
{"paper.ps.en" 1.0 {type application/postscript} |
1615 |
{language en}} |
1616 |
Vary: negotiate, accept, accept-language |
1617 |
ETag: "blah;1234" |
1618 |
Cache-control: max-age=86400 |
1619 |
Content-Type: text/html |
1620 |
Content-Length: 227 |
1621 |
|
1622 |
<h2>Multiple Choices:</h2> |
1623 |
<ul> |
1624 |
<li><a href=paper.html.en>HTML, English version</a> |
1625 |
<li><a href=paper.html.fr>HTML, French version</a> |
1626 |
<li><a href=paper.ps.en>Postscript, English version</a> |
1627 |
</ul> |
1628 |
|
1629 |
The Vary header in the response should ensure correct handling by |
1630 |
HTTP/1.1 caching proxies not capable of transparent content |
1631 |
negotiation. This header can either be |
1632 |
|
1633 |
Vary: * |
1634 |
|
1635 |
or a more elaborate header; see Section 10.5.1. |
1636 |
|
1637 |
Only the origin server may construct list responses. List |
1638 |
responses are cacheable unless indicated otherwise. |
1639 |
|
1640 |
According to the HTTP/1.1 specification [1], a user agent not |
1641 |
capable of transparent content negotiation will, when receiving a |
1642 |
list response, display the entity body included in the response. |
1643 |
If the response contains a Location header, however, the user agent |
1644 |
may automatically redirect to this location. |
1645 |
|
1646 |
The handling of list responses by clients supporting transparent |
1647 |
content negotiation is described in Sections 12.1 and 14. |
1648 |
|
1649 |
Note: Some existing versions of HTTP/1.0 clients are known to |
1650 |
silently ignore list responses, instead of handling them |
1651 |
according to the HTTP/1.0 specification [3]. Servers should |
1652 |
therefore be careful in sending list responses to |
1653 |
non-negotiating HTTP/1.0 user agents, and in making these |
1654 |
responses cacheable. |
1655 |
|
1656 |
|
1657 |
10.2 Choice response |
1658 |
|
1659 |
A choice response merges a normal HTTP response from the chosen |
1660 |
variant, a Content-Location header giving the location of the |
1661 |
variant, and the Alternates headers bound to the negotiable |
1662 |
resource. Depending on the response code, a choice response is |
1663 |
cacheable unless indicated otherwise. |
1664 |
|
1665 |
Origin servers and proxy caches must construct choice responses |
1666 |
with the following algorithm (or any other algorithm which gives |
1667 |
equal results). |
1668 |
|
1669 |
In this algorithm, `the current Alternates header' refers to the |
1670 |
Alternates header containing the variant list which was used to |
1671 |
choose the best variant, and `the current variant list validator' |
1672 |
refers to the validator of this list. Section 10.3 specifies how |
1673 |
these two things can be obtained by a proxy cache. |
1674 |
|
1675 |
The algorithm consists of five steps. |
1676 |
|
1677 |
1. Construct a HTTP request message on the best variant resource |
1678 |
by rewriting the request-URI and Host header (if appropriate) |
1679 |
of the received request message on the negotiable resource. |
1680 |
|
1681 |
2. Generate a valid HTTP response message, but not one with the |
1682 |
304 (Not Modified) code, for the request message constructed |
1683 |
in step 1. |
1684 |
|
1685 |
In a proxy cache, the response can be obtained from cache |
1686 |
memory, or by passing the constructed HTTP request towards the |
1687 |
origin server. If the request is passed on, the proxy may |
1688 |
add, modify, or delete If-None-Match and If-Range headers to |
1689 |
optimize the transaction with the upstream server. |
1690 |
|
1691 |
3. Check for an origin server configuration error. If the HTTP |
1692 |
response message generated in step 2 contains an Alternates |
1693 |
header, a Content-Location header, or has the 300 status code, |
1694 |
then the best variant resource is not a proper end point in |
1695 |
the negotiation process, and a 506 (Variant Also Negotiates) |
1696 |
error response message should be generated instead of going to |
1697 |
step 4. |
1698 |
|
1699 |
4. Add a number of headers to the HTTP response message generated |
1700 |
in step 2. |
1701 |
|
1702 |
a. Add a Content-Location header giving the location of the |
1703 |
chosen variant. |
1704 |
|
1705 |
Note: According to the HTTP/1.1 specification [1], if |
1706 |
the Content-Location header contains a relative URI, |
1707 |
this URI is relative to the URI in the Content-Base |
1708 |
header, if present. |
1709 |
|
1710 |
b. If any Vary headers are present in the response message |
1711 |
from step 2, add, for every Vary header, a Variant-Vary |
1712 |
header with a copy of the contents of this Vary header. |
1713 |
|
1714 |
c. Add the current Alternates header. |
1715 |
|
1716 |
d. Add a Vary header to ensure correct handling by HTTP/1.1 |
1717 |
caching proxies not capable of transparent content |
1718 |
negotiation. This header can either be |
1719 |
|
1720 |
Vary: * |
1721 |
|
1722 |
or a more elaborate header, see Section 10.5. |
1723 |
|
1724 |
e. To ensure compatibility with HTTP/1.0 caching proxies which |
1725 |
do not recognize the Vary header, an Expires header with a |
1726 |
date in the past may be added. See Appendix 19.1 for more |
1727 |
information. |
1728 |
|
1729 |
f. If an ETag header is present in the response message from |
1730 |
step 2, then extend the entity tag in that header with the |
1731 |
current variant list validator, as specified in Section |
1732 |
9B.2. |
1733 |
|
1734 |
g. Only in proxy caches: set the Age header of the response to |
1735 |
|
1736 |
max( variant_age , alternates_age ) |
1737 |
|
1738 |
where variant_age is the age of the best variant response |
1739 |
obtained in step 2, calculated according to the rules in |
1740 |
the HTTP/1.1 specification [1], and alternates_age is the |
1741 |
age of the Alternates header added in step c, calculated |
1742 |
according to the rules in Section 10.3. |
1743 |
|
1744 |
5. The response may be shortened to a 304 (Not Modified) or 206 |
1745 |
(Partial Content) response if an If-No-Match or If-Range |
1746 |
header in the original request message allows it according to |
1747 |
the HTTP/1.1 specification [1]. |
1748 |
|
1749 |
Note: In this algorithm, a proxy cache always generates a |
1750 |
full response message in step 2. In practice, proxy caches |
1751 |
can use a more efficient algorithm which produces equal |
1752 |
results, but which avoids expanding 304 responses from |
1753 |
upstream servers to full responses in step 2 if these |
1754 |
responses will be shortened again in step 5. By |
1755 |
shortcutting the expansion, a proxy cache can sometimes |
1756 |
generate a legal 304 response even if it has not cached the |
1757 |
variant data itself. |
1758 |
|
1759 |
An example of a choice response is: |
1760 |
|
1761 |
HTTP/1.1 200 OK |
1762 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
1763 |
Content-Type: text/html |
1764 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
1765 |
Content-Length: 5327 |
1766 |
Cache-control: max-age=604800 |
1767 |
Content-Location: paper.html.en |
1768 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1769 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1770 |
{"paper.ps.en" 1.0 {type application/postscript} |
1771 |
{language en}} |
1772 |
Etag: "gonkyyyy;1234" |
1773 |
Vary: negotiate, accept, accept-language |
1774 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
1775 |
|
1776 |
<title>A paper about .... |
1777 |
|
1778 |
An example of forwarding by a proxy cache: if a proxy receives the |
1779 |
request |
1780 |
|
1781 |
GET /paper HTTP/1.1 |
1782 |
Host: x.org |
1783 |
User-Agent: WuxtaWeb/2.4 |
1784 |
Negotiate: trans |
1785 |
Accept: text/html, * |
1786 |
Accept-Language: en |
1787 |
If-None-Match: "gonkyyyy;1234", W/"a;b;1234" |
1788 |
|
1789 |
and if it can reuse a cached variant list with the validator |
1790 |
"1234", taken from a cached response with an age of 8000 seconds, |
1791 |
to choose paper.html.en as the best variant, then the proxy can |
1792 |
pass on the request |
1793 |
|
1794 |
GET /paper.html.en HTTP/1.1 |
1795 |
Host: x.org |
1796 |
User-Agent: WuxtaWeb/2.4 |
1797 |
Negotiate: trans |
1798 |
Accept: text/html, * |
1799 |
Accept-Language: en |
1800 |
If-None-Match: "gonkyyyy", W/"a;b" |
1801 |
Via: 1.1 fred |
1802 |
|
1803 |
to an upstream server. On receipt of the response |
1804 |
|
1805 |
HTTP/1.1 304 Not Modified |
1806 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
1807 |
Etag: "gonkyyyy" |
1808 |
|
1809 |
from the upstream server, it can return |
1810 |
|
1811 |
HTTP/1.1 304 Not Modified |
1812 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
1813 |
Etag: "gonkyyyy;1234" |
1814 |
Content-Location: paper.html.en |
1815 |
Vary: negotiate, accept, accept-language |
1816 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
1817 |
Via: 1.1 fred |
1818 |
Age: 8000 |
1819 |
|
1820 |
to its own client. |
1821 |
|
1822 |
|
1823 |
10.2B Ad hoc response |
1824 |
|
1825 |
An ad hoc response never has the 300 response status code and never |
1826 |
has a Content-Location header. It must contain the Alternates |
1827 |
header bound to the negotiable resource, and a Vary header if the |
1828 |
response is cacheable. It may be generated by an origin server, |
1829 |
usually as a response to a non-negotiating user agent, if the |
1830 |
server cannot or does not want to send a list or choice response. |
1831 |
|
1832 |
The Vary header in the response should ensure correct handling by |
1833 |
HTTP/1.1 caching proxies not capable of transparent content |
1834 |
negotiation. This header can either be |
1835 |
|
1836 |
Vary: * |
1837 |
|
1838 |
or a more elaborate header, see Section 10.5.1. Ad hoc responses |
1839 |
are cacheable unless indicated otherwise. The handling of ad hoc |
1840 |
responses by clients supporting transparent content negotiation is |
1841 |
described in Sections 12.1 and 14. |
1842 |
|
1843 |
An example of an ad hoc response is: |
1844 |
|
1845 |
HTTP/1.1 200 OK |
1846 |
Date: Tue, 11 Jun 1996 20:02:26 GMT |
1847 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1848 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1849 |
{"paper.ps.en" 1.0 {type application/postscript} |
1850 |
{language en}} |
1851 |
Vary: negotiate, accept, accept-language |
1852 |
Etag: "gonkzzzz;1234" |
1853 |
Cache-control: max-age=86400 |
1854 |
Content-Type: text/html |
1855 |
Content-Length: 227 |
1856 |
|
1857 |
<h2>Multiple Choices:</h2> |
1858 |
<ul> |
1859 |
<li><a href=paper.html.en>HTML, English version</a> |
1860 |
<li><a href=paper.html.fr>HTML, French version</a> |
1861 |
<li><a href=paper.ps.en>Postscript, English version</a> |
1862 |
</ul> |
1863 |
|
1864 |
Another example is |
1865 |
|
1866 |
HTTP/1.1 302 Moved Temporarily |
1867 |
Date: Tue, 11 Jun 1996 20:02:28 GMT |
1868 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
1869 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
1870 |
{"paper.ps.en" 1.0 {type application/postscript} |
1871 |
{language en}} |
1872 |
Location: paper.html.en |
1873 |
Content-Type: text/html |
1874 |
Content-Length: 59 |
1875 |
|
1876 |
This document is available <a href=paper.html.en>here</a>. |
1877 |
|
1878 |
|
1879 |
10.3 Reusing the Alternates header |
1880 |
|
1881 |
If a proxy cache has available a negotiated response which is |
1882 |
cacheable, fresh, and has an ETag header, then it may extract the |
1883 |
Alternates header and associated variant list validator from the |
1884 |
response, and reuse them (without unnecessary delay) to negotiate |
1885 |
on behalf of the user agent or origin server (Section 14) or to |
1886 |
construct a choice response (Section 10.2). The age of the |
1887 |
extracted Alternates header is the age of the response from which |
1888 |
it is extracted, calculated according to the rules in the HTTP/1.1 |
1889 |
specification [1]. |
1890 |
|
1891 |
|
1892 |
10.4 Extracting a normal response from a choice response |
1893 |
|
1894 |
If a proxy receives a choice response, it may extract and cache the |
1895 |
normal HTTP response contained therein. The normal response can be |
1896 |
extracted by taking a copy of the choice response and then deleting |
1897 |
the Content-Location, Alternates, and Vary headers, renaming any |
1898 |
Variant-Vary headers to Vary headers, and shortening the structured |
1899 |
entity tag in any ETag header to a normal entity tag. |
1900 |
|
1901 |
This normal response may then be cached (as a HTTP response to the |
1902 |
variant request as constructed in step 1. of Section 10.2) and |
1903 |
reused to answer future direct requests on the variant resource |
1904 |
according to the rules in the HTTP/1.1 specification [1]. This |
1905 |
caching of extracted responses can increase overall efficiency with |
1906 |
up to a factor 2. |
1907 |
|
1908 |
For security reasons (see Section 15.2), an extracted normal |
1909 |
response may only be cached if the negotiable resource and the |
1910 |
variant resource are neighbors. If they are not neighbors, the |
1911 |
proxy should reject the choice response as a probable spoofing |
1912 |
attempt and pass on a 502 (bad gateway) error response instead. |
1913 |
|
1914 |
|
1915 |
10.5 Elaborate Vary headers |
1916 |
|
1917 |
If a HTTP/1.1 [1] server can generate varying responses for a |
1918 |
request on a single resource, then the server must include a Vary |
1919 |
header in these responses if they are cacheable. This Vary header |
1920 |
is a signal to HTTP/1.1 caches that something special is going on. |
1921 |
It prevents the caches from returning the currently chosen response |
1922 |
to every future request on the resource. |
1923 |
|
1924 |
Servers engaging in transparent content negotiation will generate |
1925 |
varying responses. Therefore, cacheable list, choice, and ad hoc |
1926 |
responses must always include a Vary header. |
1927 |
|
1928 |
The most simple Vary header which can be included is |
1929 |
|
1930 |
Vary: * |
1931 |
|
1932 |
This header leaves the way in which the response is selected by the |
1933 |
server completely unspecified. |
1934 |
|
1935 |
A more elaborate Vary header can be used to allow for certain |
1936 |
optimizations in HTTP/1.1 caches which are not capable of |
1937 |
transparent content negotiation, but which do cache multiple |
1938 |
variant responses for one resource. Such a more elaborate Vary |
1939 |
header lists all request headers which can be used by the server |
1940 |
when selecting a response for a request on the resource. |
1941 |
|
1942 |
10.5.1 Construction of an elaborate Vary header |
1943 |
|
1944 |
Origin servers can construct a more elaborate Vary header in the |
1945 |
following way. First, start with the header |
1946 |
|
1947 |
Vary: negotiate |
1948 |
|
1949 |
`negotiate' is always included because servers using the network |
1950 |
negotiation algorithm will sometimes use the information in the |
1951 |
Negotiate header when choosing between a list, choice, or ad-hoc |
1952 |
response. |
1953 |
|
1954 |
Then, if any of the following attributes is present in any variant |
1955 |
description in the Alternates header, add the corresponding header |
1956 |
name to the Vary header |
1957 |
|
1958 |
attribute | header name to add |
1959 |
-----------+--------------------- |
1960 |
type | accept |
1961 |
charset | accept-charset |
1962 |
language | accept-language |
1963 |
features | accept-features |
1964 |
|
1965 |
The Vary header constructed in this way specifies the response |
1966 |
variation which can be caused by the use of the network negotiation |
1967 |
algorithm in proxies. If the origin server uses a custom |
1968 |
negotiation algorithm which takes additional headers (for example |
1969 |
User-Agent) into account, these should also be added to the Vary |
1970 |
header. |
1971 |
|
1972 |
10.5.2 Caching of an elaborate Vary header |
1973 |
|
1974 |
Proxy caches cannot construct elaborate Vary headers by themselves, |
1975 |
because they may not assume that the origin server uses the |
1976 |
standard network negotiation algorithm to vary its responses. |
1977 |
However, when extracting an Alternates header from a response |
1978 |
(Section 10.3) caches may also extract the Vary header in the |
1979 |
response, and reuse it along with the Alternates header. A clean |
1980 |
Vary header can however only be extracted if the variant does not |
1981 |
vary itself, i.e. if a Variant-Vary header is absent. |
1982 |
|
1983 |
|
1984 |
10.6 Negotiation on content encoding |
1985 |
|
1986 |
Negotiation on the content encoding of a response is orthogonal to |
1987 |
transparent content negotiation. The rules for when a content |
1988 |
encoding may be applied are the same as in HTTP/1.1: servers may |
1989 |
content-encode responses that are the result of transparent content |
1990 |
negotiation whenever an Accept-Encoding header in the request |
1991 |
allows it. When negotiating on content encoding, servers must add |
1992 |
the accept-encoding header name to the Vary header of the response, |
1993 |
or add `Vary: *', if the response is cacheable. |
1994 |
|
1995 |
Servers should always be able to provide unencoded versions of |
1996 |
every transparently negotiated response. This means in particular |
1997 |
that every variant in the variant list must at least be available |
1998 |
in an unencoded form. |
1999 |
|
2000 |
Like HTTP/1.1, this specification allows proxies to encode or |
2001 |
decode relayed or cached responses on the fly: the response still |
2002 |
contains the same variant as far as transparent content negotiation |
2003 |
is concerned. Note that HTTP/1.1 requires proxies to add a Warning |
2004 |
header if the encoding of a response is changed. |
2005 |
|
2006 |
|
2007 |
11 The network negotiation algorithm |
2008 |
|
2009 |
The network negotiation algorithm is a standardized algorithm by |
2010 |
which a party in the negotiation process can make a choice on |
2011 |
behalf of another party. For example, a proxy could choose a |
2012 |
particular variant on behalf of the user agent in order to speed up |
2013 |
the negotiation process by cutting corners (see Section 4.4). |
2014 |
|
2015 |
General principles underlying the network negotiation algorithm are |
2016 |
as follows. |
2017 |
|
2018 |
- When running on an origin server or proxy, the algorithm will |
2019 |
usually only have partial user agent capabilities and |
2020 |
preferences information as input. Therefore, instead of a |
2021 |
choice for a best variant, the algorithm can also yield an |
2022 |
`insufficient data, cannot choose' result. |
2023 |
|
2024 |
- Decisions are always made on either on behalf of the user agent |
2025 |
or on behalf of the origin server. They are made on behalf of |
2026 |
the user agent if the user agent indicates that it is capable of |
2027 |
transparent content negotiation, and on behalf of the origin |
2028 |
server otherwise. |
2029 |
|
2030 |
- By including an Alternates header in the response, the origin |
2031 |
server gives upstream proxies the permission to perform actions |
2032 |
prescribed by the network negotiation algorithm instead of |
2033 |
actions prescribed by the plain HTTP specification. |
2034 |
|
2035 |
- It is expected that user agents will use the network negotiation |
2036 |
algorithm by default, locally supplying their complete |
2037 |
capabilities and preferences to the algorithm, but this is not |
2038 |
required. User agents may use customized negotiation algorithms |
2039 |
to automatically choose a variant. Such algorithms could for |
2040 |
example account for cross-dependencies between dimensions of |
2041 |
negotiation. |
2042 |
|
2043 |
Note that in this specification, `use of the network negotiation |
2044 |
algorithm' means use of any algorithm which yields equal results. |
2045 |
|
2046 |
|
2047 |
11.1 Input |
2048 |
|
2049 |
The algorithm is always executed for a particular request on a |
2050 |
particular transparently negotiable resource. It takes the |
2051 |
following information as input. |
2052 |
|
2053 |
1. The list of variants of the resource, as present in the |
2054 |
Alternates header of the resource. |
2055 |
|
2056 |
2. Any "min-q" directive pertaining to the negotiation process, as |
2057 |
specified by the Alternates header of the resource. |
2058 |
|
2059 |
3. (Partial) Information about capabilities and preferences of the |
2060 |
user agent for this particular request, as given in the Accept |
2061 |
headers of the request, or, if the algorithm runs on a user |
2062 |
agent, as given by the internal capabilities and preferences |
2063 |
database. |
2064 |
|
2065 |
4. A boolean indicating whether or not the user agent is capable |
2066 |
of transparent content negotiation for this request. (This can |
2067 |
be determined by looking for a `trans' directive in a Negotiate |
2068 |
header, see Section 9.6.) |
2069 |
|
2070 |
|
2071 |
11.2 Output |
2072 |
|
2073 |
As its output, the network negotiation algorithm and will yield the |
2074 |
appropriate action to be performed. Actions have labels `ACT_UA' |
2075 |
for actions performed on behalf of the user agent, and `ACT_OS' for |
2076 |
actions performed on behalf of the origin server. |
2077 |
|
2078 |
11.2.1 Output for proxies |
2079 |
|
2080 |
If the algorithm runs on a proxy, there are four different possible |
2081 |
results. The first two results can be generated if the user agent |
2082 |
is capable of transparent content negotiation: |
2083 |
|
2084 |
Choice_UA |
2085 |
|
2086 |
Choice on behalf of the user agent. The best variant may be |
2087 |
retrieved and returned in a choice response. |
2088 |
|
2089 |
List_UA |
2090 |
|
2091 |
No choice possible, return the list. The Accept headers do |
2092 |
not contain sufficient information to make a choice on behalf |
2093 |
of the user agent possible. A list response should be |
2094 |
returned, allowing the user agent to make the choice itself. |
2095 |
|
2096 |
The following results can be generated if the user agent is not |
2097 |
capable of transparent content negotiation: |
2098 |
|
2099 |
Choice_OS |
2100 |
|
2101 |
Choice on behalf of the origin server. The best variant may |
2102 |
be retrieved and returned in a choice response. |
2103 |
|
2104 |
Forward_OS |
2105 |
|
2106 |
No choice possible, forward the request towards the origin |
2107 |
server. The Accept headers do not contain sufficient |
2108 |
information to make a choice on behalf of the origin server |
2109 |
possible. The request should be forwarded towards the origin |
2110 |
server so that it can choose the most appropriate action with |
2111 |
a custom algorithm. |
2112 |
|
2113 |
11.2.2 Output for origin servers |
2114 |
|
2115 |
If the algorithm runs on an origin server, all results above are |
2116 |
possible. The last result has a different interpretation: |
2117 |
|
2118 |
Forward_OS |
2119 |
|
2120 |
No choice possible, internally forward the request to a custom |
2121 |
algorithm which chooses an appropriate action. |
2122 |
|
2123 |
Usually, the appropriate action is the sending of an ad hoc |
2124 |
response. |
2125 |
|
2126 |
11.2.3 Output for user agents |
2127 |
|
2128 |
If the algorithm runs on a user agent, only the results List_UA and |
2129 |
Choice_UA are possible, with the following interpretations. |
2130 |
|
2131 |
Choice_UA |
2132 |
|
2133 |
Automatic choice. A particular variant X must be retrieved and |
2134 |
displayed. |
2135 |
|
2136 |
List_UA |
2137 |
|
2138 |
No automatic choice possible, none of of the variants can be |
2139 |
rendered according to the preferences and capabilities |
2140 |
database. An appropriate action like showing an error message |
2141 |
with the list of variants to the user must be performed. |
2142 |
|
2143 |
|
2144 |
11.3 Computing the overall quality values |
2145 |
|
2146 |
As a first step in the network negotiation algorithm, the overall |
2147 |
qualities of the individual variants in the list are computed. |
2148 |
|
2149 |
The overall quality Q of a variant is the value |
2150 |
|
2151 |
Q = qs * qt * qc * ql * qf |
2152 |
|
2153 |
where the factors qs, qt, qc, ql, and qf are determined as follows. |
2154 |
|
2155 |
qs Is the source quality factor in the variant description. |
2156 |
|
2157 |
qt The media type quality factor is 1 if there is no type |
2158 |
attribute in the variant description, or if there is no |
2159 |
Accept header in the request. Otherwise, it is the quality |
2160 |
assigned by the Accept header to the media type in the type |
2161 |
attribute. |
2162 |
|
2163 |
Note: If a type is matched by none of the elements of an |
2164 |
Accept header, the Accept header assigns the quality factor |
2165 |
0 to that type. |
2166 |
|
2167 |
qc The charset quality factor is 1 if there is no charset |
2168 |
attribute in the variant description, or if there is no |
2169 |
Accept-Charset header in the request. Otherwise, the charset |
2170 |
quality factor is the quality assigned by the Accept-Charset |
2171 |
header to charset in the charset attribute. |
2172 |
|
2173 |
Note: If a charset does not appear in an Accept-Charset |
2174 |
header, the Accept-Charset header assigns the quality |
2175 |
factor 0 to that charset. |
2176 |
|
2177 |
ql The language quality factor is 1 if there is no language |
2178 |
attribute in the variant description, or if there is no |
2179 |
Accept-Language header in the request. Otherwise, the |
2180 |
language quality factor is the highest quality factor |
2181 |
assigned by the Accept-Language header to any one of the |
2182 |
languages listed in the language attribute. |
2183 |
|
2184 |
qf The features quality factor is 1 if there is no features |
2185 |
attribute in the variant description, or if there is no |
2186 |
Accept-Features header in the request. Otherwise, it is |
2187 |
the feature negotiation quality degradation value for the |
2188 |
features attribute, see Section 6.4. |
2189 |
|
2190 |
As an example, if a variant list contains the variant description |
2191 |
|
2192 |
{"paper.html.en" 0.7 {type text/html} {language fr}} |
2193 |
|
2194 |
and if the request contains the Accept headers |
2195 |
|
2196 |
Accept: text/html:q=1.0, */*:q=0.8 |
2197 |
Accept-Language: en;q=1.0, fr;q=0.5 |
2198 |
|
2199 |
the network negotiation algorithm will compute an overall quality |
2200 |
for the variant as follows: |
2201 |
|
2202 |
{"paper.html.en" 0.7 {type text/html} {language fr}} |
2203 |
| | | |
2204 |
| | | |
2205 |
V V V |
2206 |
0.7 * 1.0 * 0.5 = 0.35 |
2207 |
|
2208 |
With the above Accept headers, the complete variant list |
2209 |
|
2210 |
{"paper.html.en" 0.9 {type text/html} {language en}}, |
2211 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
2212 |
{"paper.ps.en" 1.0 {type application/postscript} {language en}} |
2213 |
|
2214 |
would yield the following computations: |
2215 |
|
2216 |
qs * qt * qc * ql * qf = Q |
2217 |
--- --- --- --- --- ---- |
2218 |
paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.9 |
2219 |
paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35 |
2220 |
paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.8 |
2221 |
|
2222 |
|
2223 |
11.4 Definite and speculative quality values |
2224 |
|
2225 |
An overall quality value computed by an origin server or proxy can |
2226 |
be either definite or speculative. |
2227 |
|
2228 |
An overall quality value for a variant is definite if it was |
2229 |
computed without using any wildcard characters '*' in the Accept |
2230 |
headers, and without the need to use the absence of a particular |
2231 |
Accept header. An overall quality value is speculative otherwise. |
2232 |
|
2233 |
As an example, in the previous section, the quality values of |
2234 |
paper.html.en and paper.html.fr are definite, and the quality value |
2235 |
of paper.ps.en is speculative because the type |
2236 |
application/postscript was matched to the range */*. |
2237 |
|
2238 |
Definiteness can be defined more formally as follows. An overall |
2239 |
quality value Q is definite if the same quality value Q could be |
2240 |
computed after the request message is changed in the following way: |
2241 |
|
2242 |
1. If an Accept, Accept-Charset, Accept-Language, or |
2243 |
Accept-Features, header is missing from the request, add |
2244 |
this header with an empty field. |
2245 |
|
2246 |
2. Delete any media ranges containing a wildcard character '*' |
2247 |
from the Accept header. Delete the language-range '*', if |
2248 |
present, from the Accept-Language header. Delete the |
2249 |
wildcard '*', if present, from the Accept-Features header. |
2250 |
|
2251 |
As another example, the overall quality factor for the variant |
2252 |
|
2253 |
{"blah.html" 1 {language en-gb} {features blebber [x y]}} |
2254 |
|
2255 |
is 1 and definite with the Accept headers |
2256 |
|
2257 |
Accept-Language: en-gb, fr |
2258 |
Accept-Features: blebber, x, !y, * |
2259 |
|
2260 |
and |
2261 |
|
2262 |
Accept-Language: en, fr |
2263 |
Accept-Features: blebber, x, * |
2264 |
|
2265 |
The overall quality factor is still 1, but speculative, with the |
2266 |
Accept headers |
2267 |
|
2268 |
Accept-language: en-gb, fr |
2269 |
Accept-Features: blebber, !y, * |
2270 |
|
2271 |
and |
2272 |
|
2273 |
Accept-Language: fr, * |
2274 |
Accept-Features: blebber, x, !y, * |
2275 |
|
2276 |
|
2277 |
11.5 Determining the result |
2278 |
|
2279 |
The best variant, as determined by the network negotiation |
2280 |
algorithm, is the one variant with the highest overall quality |
2281 |
value, or, if there are multiple variants which share the highest |
2282 |
overall quality, the first variant in the list with this value. |
2283 |
|
2284 |
11.5.1 Result for proxies and origin servers |
2285 |
|
2286 |
When running on a proxy or origin server, the result of the network |
2287 |
negotiation algorithm is determined as follows. |
2288 |
|
2289 |
1. If the negotiable resource and the best variant resource are not |
2290 |
neighbors, then the result is List_UA if the user agent is |
2291 |
capable of transparent content negotiation, Forward_OS otherwise. |
2292 |
This rule exists for security reasons: it prevents some forms of |
2293 |
spoofing, see Section 15.2. |
2294 |
|
2295 |
2. If the above rule does not apply, then |
2296 |
|
2297 |
1. If the user agent is capable of transparent content |
2298 |
negotiation, the result is Choice_UA if the best variant has |
2299 |
an overall quality value greater than 0 which is also a |
2300 |
definite quality value, and List_UA otherwise. |
2301 |
|
2302 |
2. If the user agent is not capable of transparent content |
2303 |
negotiation, the result is Choice_OS if the best variant has |
2304 |
a (definite or speculative) overall quality value which is |
2305 |
greater than 0, or at least the value of the "min-q" |
2306 |
directive if this directive is present in the Alternates |
2307 |
header. The result is Forward_OS otherwise. |
2308 |
|
2309 |
11.5.2 Result for user agents |
2310 |
|
2311 |
When running on a user agent, the result of the network negotiation |
2312 |
algorithm is Choice_UA if the best variant has an overall quality |
2313 |
value greater than 0, and List_UA otherwise. |
2314 |
|
2315 |
|
2316 |
11.6 Construction of short requests |
2317 |
|
2318 |
Under normal HTTP semantics, the interpretation of the request |
2319 |
header `Accept: */*' is |
2320 |
|
2321 |
`I accept all media types with a quality of 1.0'. |
2322 |
|
2323 |
One of the most important properties of the network negotiation |
2324 |
algorithm is that this interpretation is different if the header is |
2325 |
sent by a user agent which supports transparent content |
2326 |
negotiation. In this case, the interpretation of the header is |
2327 |
|
2328 |
`I accept several media types, and assign quality factors from 0.0 |
2329 |
up to 1.0 to them. If this information is insufficient to make a |
2330 |
choice on my behalf, do not make a choice but send the list of |
2331 |
variants'. |
2332 |
|
2333 |
According to the HTTP/1.1 specification [1], the complete absence |
2334 |
of an Accept header from the request is to be interpreted in the |
2335 |
same way. This means that a user agent which supports transparent |
2336 |
content negotiation can send a minimal request, without any Accept |
2337 |
headers but with a Negotiate header, by default: |
2338 |
|
2339 |
GET /paper HTTP/1.1 |
2340 |
Host: x.org |
2341 |
User-Agent: WuxtaWeb/2.4 |
2342 |
Negotiate: |
2343 |
|
2344 |
The sending of this minimal request will never have an adverse |
2345 |
effect on the quality of the transparent negotiation process: if |
2346 |
the requested resource happens to be transparently negotiated, the |
2347 |
user agent will always get a list response, so that it can choose |
2348 |
the best variant itself. Only the speed of the negotiation process |
2349 |
can be affected, because servers will no longer be able to cut |
2350 |
corners by choosing on behalf of the user agent. |
2351 |
|
2352 |
If it is found that the requests to a particular origin server |
2353 |
often return a less efficient list response, the user agent can |
2354 |
dynamically introduce short Accept headers in its future requests |
2355 |
to that server, for example |
2356 |
|
2357 |
GET /paper HTTP/1.1 |
2358 |
Host: x.org |
2359 |
User-Agent: WuxtaWeb/2.4 |
2360 |
Negotiate: |
2361 |
Accept: text/html, application/postscript:q=0.8, */* |
2362 |
Accept-language: en, fr;q=0.5 |
2363 |
|
2364 |
This will increase the chance that the network negotiation |
2365 |
algorithm will have sufficient information to choose on behalf of |
2366 |
the user agent, thereby optimizing the negotiation process. A good |
2367 |
strategy for dynamic extension would be to extend the request with |
2368 |
with those media types, languages, charsets, and feature tags |
2369 |
mentioned in the variant lists of past list responses from the |
2370 |
server. The Accept header in the extended request, if present, |
2371 |
will generally contain "*/*" to indicate that only partial |
2372 |
information is given in this header. The Accept-Features header, |
2373 |
if present, will generally contain a "*" for the same reason. |
2374 |
|
2375 |
|
2376 |
12 User agent support for transparent negotiation |
2377 |
|
2378 |
This section specifies the requirements a user agent must satisfy |
2379 |
in order to support transparent negotiation. If the user agent |
2380 |
contains an internal cache, this cache should satisfy the |
2381 |
requirements for proxy caches in Section 14. |
2382 |
|
2383 |
|
2384 |
12.1 Handling of responses |
2385 |
|
2386 |
If a list response is received when a resource is accessed, the |
2387 |
user agent must be able to automatically choose, retrieve, and |
2388 |
display the best variant, or display an error message if it is not |
2389 |
capable of displaying any of the available variants. The |
2390 |
negotiation algorithm which chooses the best variant (or chooses to |
2391 |
display an error message) need not be the network negotiation |
2392 |
algorithm. |
2393 |
|
2394 |
If a choice response or ad hoc response is received when a resource |
2395 |
is accessed, the usual action is to automatically display the |
2396 |
enclosed entity. A user agent may however choose to apply its |
2397 |
(custom) negotiation algorithm to the received variant list, and to |
2398 |
automatically retrieve and display another variant if the algorithm |
2399 |
indicates that this other variant has a better quality. |
2400 |
|
2401 |
When receiving a choice response, a user agent should check if the |
2402 |
if the negotiable resource and the chosen variant resource are |
2403 |
neighbors. If this is not the case, the user agent should reject |
2404 |
the choice response as a probable spoofing attempt and display an |
2405 |
error message, for example by internally replacing the choice |
2406 |
response with a 502 (bad gateway) response. |
2407 |
|
2408 |
|
2409 |
12.2 Presentation of a transparently negotiated resource |
2410 |
|
2411 |
If the user agent is displaying a variant which is not an embedded |
2412 |
or inlined object and which is the result of transparent |
2413 |
negotiation, the following requirements must be met. |
2414 |
|
2415 |
1. The user agent should allow the user to review a list of all |
2416 |
variants bound to the negotiable resource, and to manually |
2417 |
retrieve another variant if desired. There are two general |
2418 |
ways of providing such a list. First, the information in the |
2419 |
Alternates header of the negotiable resource could be used to |
2420 |
make an annotated menu of variants. Second, the entity |
2421 |
included in a list response of the negotiable resource could be |
2422 |
displayed. Note that a list response can always be obtained by |
2423 |
doing a GET request on the negotiable resource with a Negotiate |
2424 |
header but without Accept headers. |
2425 |
|
2426 |
2. The user agent should make available though its user interface |
2427 |
some indication that the resource being displayed is a |
2428 |
negotiated resource instead of a plain resource. It should |
2429 |
also allow the user to examine the variant list included in the |
2430 |
Alternates header. Such a notification and review mechanism is |
2431 |
needed because of privacy considerations, see Section 15.1. |
2432 |
|
2433 |
3. If the user agent shows the URI of the displayed information to |
2434 |
the user, it should be the negotiable resource URI, not the |
2435 |
variant URI that is shown. This encourages third parties, who |
2436 |
want to refer to the displayed information in their own |
2437 |
documents, to make a hyperlink to the negotiable resource as a |
2438 |
whole, rather than to the variant resource which happens to be |
2439 |
shown. Such correct linking is vital for the interoperability |
2440 |
of content across sites. |
2441 |
|
2442 |
4. Similarly, if the user agent stores a reference to the |
2443 |
displayed information for future use, for example in a hotlist, |
2444 |
it should store the negotiable resource URI, not the |
2445 |
variant URI. |
2446 |
|
2447 |
It is encouraged, but not required, that some of the above |
2448 |
functionality is also made available for inlined or embedded |
2449 |
objects, and when a variant which was selected manually is being |
2450 |
displayed. |
2451 |
|
2452 |
|
2453 |
13 Origin server support for transparent negotiation |
2454 |
|
2455 |
This section covers origin server support from a HTTP viewpoint. |
2456 |
see Appendix 19.2 for implementation considerations. |
2457 |
|
2458 |
|
2459 |
13.1 Requirements |
2460 |
|
2461 |
To implement transparent negotiation on a resource, the origin |
2462 |
server must be able to send a list response when getting a GET |
2463 |
request on the resource. It should also be able to send |
2464 |
appropriate list responses for HEAD requests. The origin server |
2465 |
must always send a list response for a request with a Negotiate |
2466 |
header but without Accept headers. |
2467 |
|
2468 |
The origin server may also return choice responses and ad hoc |
2469 |
responses, except in the special case above. The negotiation |
2470 |
algorithm used need not be the network negotiation algorithm. |
2471 |
|
2472 |
Negotiability is a binary property: a resource is either |
2473 |
transparently negotiated, or it is not. Origin servers should not |
2474 |
vary the negotiability of a resource, or the variant list bound to |
2475 |
that resource, based on the request headers which are received. |
2476 |
The variant list and the property of being negotiated may however |
2477 |
change through time. The Cache-Control header can be used to |
2478 |
control the propagation of such time-dependent changes through |
2479 |
caches. |
2480 |
|
2481 |
It is the responsibility of the author of the negotiable resource |
2482 |
to ensure that all resources in the variant list serve the intended |
2483 |
content, and that the variant resources do not engage in |
2484 |
transparent content negotiation themselves. |
2485 |
|
2486 |
An origin server may shorten a list, choice, or ad-hoc response to |
2487 |
a 304 (Not Modified) or 206 (Partial Content) response if an |
2488 |
If-No-Match or If-Range header in the request message allows it |
2489 |
according to the HTTP/1.1 specification [1]. |
2490 |
|
2491 |
|
2492 |
13.2 Negotiation on transactions other than GET and HEAD |
2493 |
|
2494 |
If a resource is transparently negotiable, this only has an impact |
2495 |
on the GET and HEAD transactions on the resource. It is not |
2496 |
possible (under this specification) to do transparent content |
2497 |
negotiation on the direct result of a POST request. |
2498 |
|
2499 |
However, a POST request can return an unnegotiated 303 (See Other) |
2500 |
response which causes the user agent to do a GET request on a |
2501 |
second resource. This second resource could then use transparent |
2502 |
content negotiation to return an appropriate final response. The |
2503 |
figure below illustrates this. |
2504 |
|
2505 |
Server ______ proxy ______ proxy ______ user |
2506 |
x.org cache cache agent |
2507 |
|
2508 |
< ------------------------------------- |
2509 |
| POST http://x.org/cgi/submit |
2510 |
| <form contents in request body> |
2511 |
| |
2512 |
-------------------------------------- > |
2513 |
302 See Other | |
2514 |
Location: http://x.org/result/OK | |
2515 |
| |
2516 |
< ------------------------------------- |
2517 |
| GET http://x.org/result/OK.nl |
2518 |
| small Accept headers |
2519 |
| |
2520 |
able to choose on |
2521 |
behalf of user agent |
2522 |
| |
2523 |
------------------------------------- > |
2524 |
choice response with | |
2525 |
..result/OK.nl variant | |
2526 |
displays OK.nl |
2527 |
|
2528 |
See the HTTP/1.1 specification [1] for details on the 303 (See |
2529 |
Other) response code. Note that this response code is not |
2530 |
understood by most HTTP/1.0 clients. |
2531 |
|
2532 |
|
2533 |
14 Proxy support for transparent negotiation |
2534 |
|
2535 |
Transparent content negotiation is designed to work through proxies |
2536 |
which only implement the HTTP/1.1 specification [1]. Thus, in a |
2537 |
sense, all HTTP/1.1 proxies support transparent content |
2538 |
negotiation. |
2539 |
|
2540 |
Plain HTTP/1.1 allows proxies to cache list, choice, and ad hoc |
2541 |
responses, and to efficiently revalidate them by using the |
2542 |
If-None-Match header. This specification defines additional |
2543 |
optimization mechanisms. |
2544 |
|
2545 |
First, a proxy may sometimes reuse an Alternates header taken from |
2546 |
a previous response (Section 10.3) to negotiate on behalf of the |
2547 |
user agent or origin server and to construct choice responses |
2548 |
(Section 10.2). Proxies must not use custom negotiation |
2549 |
algorithms, they may only use the network negotiation algorithm. |
2550 |
|
2551 |
Second, if a proxy receives a choice response, it may extract and |
2552 |
cache the normal response embedded therein, as described in |
2553 |
Section 10.4. |
2554 |
|
2555 |
Third, a proxy may shorten a list, choice, or ad-hoc response to a |
2556 |
304 (Not Modified) or 206 (Partial Content) response if an |
2557 |
If-No-Match or If-Range header in the request message allows it |
2558 |
according to the HTTP/1.1 specification [1]. |
2559 |
|
2560 |
|
2561 |
15 Security and privacy considerations |
2562 |
|
2563 |
15.1 Accept headers revealing information of a private nature |
2564 |
|
2565 |
Accept headers, in particular Accept-Language headers, may reveal |
2566 |
information which the user would rather keep private unless it will |
2567 |
directly improve the quality of service. For example, a user may |
2568 |
not want to send language preferences to sites which do not offer |
2569 |
multi-lingual content. The transparent content negotiation |
2570 |
mechanism allows user agents to omit sending of the Accept-Language |
2571 |
header by default, without this affecting the outcome of the |
2572 |
negotiation process if transparently negotiated multi-lingual |
2573 |
content is accessed. |
2574 |
|
2575 |
However, even if Accept headers are never sent, the automatic |
2576 |
selection and retrieval of a variant by a user agent will reveal a |
2577 |
preference for this variant to the server. A malicious service |
2578 |
author could provide a page with `fake' negotiability on |
2579 |
(ethnicity-correlated) languages, with all variants actually being |
2580 |
the same English document, as a means of obtaining |
2581 |
privacy-sensitive information. Such a plot would however be |
2582 |
visible to an alert victim if the list of available variants and |
2583 |
their properties is reviewed. |
2584 |
|
2585 |
Some additional privacy considerations connected to Accept headers |
2586 |
are discussed in [1]. |
2587 |
|
2588 |
|
2589 |
15.2 Spoofing of responses from variant resources |
2590 |
|
2591 |
The caching optimization in Section 10.4 gives the implementer of a |
2592 |
negotiable resource control over the responses cached for all of |
2593 |
its variant resources which are neighbors. This is a security |
2594 |
problem if a neighboring variant resource belongs to another |
2595 |
author. To provide security in this case, the HTTP server will |
2596 |
have to filter the Content-Location headers in the choice responses |
2597 |
generated by the negotiable resource implementation. |
2598 |
|
2599 |
|
2600 |
16 Acknowledgments |
2601 |
|
2602 |
Work on HTTP content negotiation has been done since at least 1993. |
2603 |
The author is unable to trace the origin of many of the ideas |
2604 |
incorporated in this document. This document builds on an earlier |
2605 |
specification of content negotiation as recorded in [2]. Many |
2606 |
members of the HTTP working group have contributed to the work |
2607 |
reflected in this document. The authors wish to thank the |
2608 |
individuals who have commented on earlier versions of this |
2609 |
document, including Brian Behlendorf, Daniel DuBois, Ted Hardie, |
2610 |
Larry Masinter, and Roy T. Fielding. |
2611 |
|
2612 |
|
2613 |
17 References |
2614 |
|
2615 |
[1] Fielding et al, Hypertext Transfer Protocol -- HTTP/1.1. |
2616 |
Internet-Draft draft-ietf-http-v11-spec-06.txt, HTTP Working |
2617 |
Group, July 4, 1996. |
2618 |
|
2619 |
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. |
2620 |
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft |
2621 |
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, |
2622 |
1996. |
2623 |
|
2624 |
[3] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer |
2625 |
Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, May 1996. |
2626 |
|
2627 |
[4] K. Holtman, A. Mutz, Feature Tag Registration Procedures. |
2628 |
Internet-Draft draft-ietf-http-feature-reg-00.txt, HTTP |
2629 |
Working Group, October 30, 1996. |
2630 |
|
2631 |
|
2632 |
18 Authors' addresses |
2633 |
|
2634 |
Koen Holtman |
2635 |
Technische Universiteit Eindhoven |
2636 |
Postbus 513 |
2637 |
Kamer HG 6.57 |
2638 |
5600 MB Eindhoven (The Netherlands) |
2639 |
Email: koen@win.tue.nl |
2640 |
|
2641 |
Andrew H. Mutz |
2642 |
Hewlett-Packard Company |
2643 |
1501 Page Mill Road 3U-3 |
2644 |
Palo Alto CA 94304, USA |
2645 |
Fax +1 415 857 4691 |
2646 |
Email: mutz@hpl.hp.com |
2647 |
|
2648 |
|
2649 |
|
2650 |
19 Appendices |
2651 |
|
2652 |
19.1 Adding an Expires header to ensure HTTP/1.0 compatibility |
2653 |
|
2654 |
To ensure compatibility with HTTP/1.0 caching proxies which do not |
2655 |
recognize the Vary header, an Expires header with a date in the |
2656 |
past can be be added to the response, for example |
2657 |
|
2658 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
2659 |
|
2660 |
If this is done by an origin server, it should usually also include |
2661 |
a Cache-Control header for the benefit of HTTP/1.1 caches, for |
2662 |
example |
2663 |
|
2664 |
Cache-Control: max-age=604800 |
2665 |
|
2666 |
which overrides the freshness lifetime of zero seconds specified by |
2667 |
the included Expires header. |
2668 |
|
2669 |
|
2670 |
19.2 Origin server implementation considerations |
2671 |
|
2672 |
19.2.1 Implementation with a CGI script |
2673 |
|
2674 |
Transparent content negotiation has been designed to allow a broad |
2675 |
range of implementation options at the origin server side. A very |
2676 |
minimal implementation can be done using the CGI interface. The |
2677 |
CGI script below is an example. |
2678 |
|
2679 |
#!/bin/sh |
2680 |
|
2681 |
echo $HTTP_NEGOTIATE | awk '$0~"^(|.*,)[\t ]*trans[\t ]*(|,.*)$" \ |
2682 |
{ print "Status: 300 Multiple Choices" }' - |
2683 |
|
2684 |
cat - <<'blex' |
2685 |
Alternates: {"stats.tables.html" 1.0 {type text/html} {features |
2686 |
tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95 |
2687 |
{type application/postscript}} |
2688 |
Vary: * |
2689 |
Content-Type: text/html |
2690 |
|
2691 |
<title>Multiple Choices for Web Statistics</title> |
2692 |
<h2>Multiple Choices for Web Statistics:</h2> |
2693 |
<ul> |
2694 |
<li><a href=stats.tables.html>Version with HTML tables</a> |
2695 |
<p> |
2696 |
<li><a href=stats.html>Version without HTML tables</a> |
2697 |
<p> |
2698 |
<li><a href=stats.ps>Postscript version</a> |
2699 |
</ul> |
2700 |
blex |
2701 |
|
2702 |
The Alternates header in the above script must be read as a single |
2703 |
line. The script generates a list response for user agents capable |
2704 |
of transparent content negotiation, and an ad hoc 200 (OK) response |
2705 |
for all non-negotiating agents. |
2706 |
|
2707 |
19.2.2 Direct support by HTTP servers |
2708 |
|
2709 |
Sophisticated HTTP servers could make a transparent negotiation |
2710 |
module available to content authors. Such a module could |
2711 |
incorporate implementations of the network negotiation algorithm |
2712 |
(Section 11) and the algorithm for generating choice responses |
2713 |
(Section 10.2). The definition of interfaces to such modules is |
2714 |
beyond the scope of this document. |
2715 |
|
2716 |
19.2.3 Web publishing tools |
2717 |
|
2718 |
Web publishing tools could automatically generate several variants |
2719 |
of a document (for example the original TeX version, a HTML version |
2720 |
with tables, a HTML version without tables, and a Postscript |
2721 |
version), together with an appropriate variant list in the |
2722 |
interface format of a HTTP server transparent negotiation module. |
2723 |
This would allow documents to be published as transparently |
2724 |
negotiable resources. |
2725 |
|
2726 |
|
2727 |
19.3 Open issues in transparent content negotiation |
2728 |
|
2729 |
At the time of writing of this specification, the following issues |
2730 |
are still open. |
2731 |
|
2732 |
- The feature tag registration process has yet to be defined. |
2733 |
|
2734 |
- A core set of feature tags (Section 8.2) has not yet been |
2735 |
defined, though there has been some related work on display |
2736 |
attributes, see Appendix 19.4.1. |
2737 |
|
2738 |
- Though it is expected that the feature negotiation framework will |
2739 |
solve many current and future negotiation problems, it is also |
2740 |
expected that there will remain current and future negotiation |
2741 |
problems not solved by feature negotiation. Currently, there is |
2742 |
little experience in this area. |
2743 |
|
2744 |
|
2745 |
19.3B Server-side rendering engines |
2746 |
|
2747 |
Cache efficiency considerations generally demand that content |
2748 |
negotiation is limited to a few variants, and that any fine-tuning |
2749 |
of a representation (for example the scaling of a title image to |
2750 |
fit the exact screen width) is done at the user agent side. |
2751 |
|
2752 |
However, some negotiation models may demand the use of server-side |
2753 |
rendering engines, which fine-tune a representation depending on |
2754 |
exact parameters supplied by the user agent. This appendix |
2755 |
discusses how to extend the transparent negotiation framework with |
2756 |
a mechanism for reliably delivering such parameters to the server. |
2757 |
|
2758 |
The variant description syntax can be extended with an optional |
2759 |
sent-tags attribute: |
2760 |
|
2761 |
sent-tags-attribute = "{" "send-tags" 1%ftag "}" |
2762 |
|
2763 |
The presence of this attribute would indicate that the variant URI |
2764 |
gives access to a server side rendering engine. An example variant |
2765 |
description is: |
2766 |
|
2767 |
{"paper.server-render.ps" 1.0 {type application/postscript} |
2768 |
{send-tags paper-size dpi printcolor print-gamma}} |
2769 |
|
2770 |
If this variant is chosen as the best variant and retrieved in a |
2771 |
GET request, the user agent would extend the |
2772 |
paper.server-render.ps URI with those feature tags in the |
2773 |
send-tags attribute it supports, and their associated preferred |
2774 |
values if applicable: |
2775 |
|
2776 |
GET paper.server-render.ps?paper-size=A4&dpi=600 HTTP/1.1 |
2777 |
|
2778 |
Thus, the exact rendering parameters end up at the server side |
2779 |
rendering engine. The URI is extended using the form submission |
2780 |
syntax for downwards compatibility reasons: this allows the list |
2781 |
response to contain a HTML form giving access to the engine. |
2782 |
|
2783 |
Server-side rendering engines may by interesting as a fallback |
2784 |
mechanism when new client-side rendering engines are introduced. |
2785 |
The following variant list illustrates this: |
2786 |
|
2787 |
{"paper.html" 0.8 {type text/html}}, |
2788 |
{"paper.tex" 1.0 {type application/x-tex} |
2789 |
{features client-render-tex}}, |
2790 |
{"paper.server-render.ps" 1.0 {type application/postscript} |
2791 |
{features !client-render-tex} |
2792 |
{send-tags paper-size dpi printcolor print-gamma}} |
2793 |
|
2794 |
|
2795 |
19.3C Quality factors in the Accept-Features header |
2796 |
|
2797 |
The feature negotiation framework specified in Section 6 does not |
2798 |
allow for the introduction of new dimensions like the type and |
2799 |
language dimension, in which the user can express a relative |
2800 |
preference for each of the elements by sending quality factors in |
2801 |
the Accept header. To support the introduction of such dimensions, |
2802 |
the Accept-Features header syntax could be extended with quality |
2803 |
factors. An example would be the following Accept-Features header: |
2804 |
|
2805 |
Accept-Features: paper=a4;q=1.0, paper=a5;q=0.8, !paper=a3, * |
2806 |
|
2807 |
Examples of overall quality factors computed using this header |
2808 |
would be: |
2809 |
|
2810 |
0.8 for {"x" 1.0 {features paper=a5}} |
2811 |
1.0 for {"y" 1.0 {features paper=a4/0.95}} |
2812 |
0.0 for {"z" 1.0 {features paper=a3}} |
2813 |
|
2814 |
Quality factors could also be useful on value-less feature tags, |
2815 |
for example |
2816 |
|
2817 |
Accept-Features: tables, larger_2x;q=0.7, * |
2818 |
|
2819 |
would degrade the overall quality of any variant which uses the |
2820 |
`larger_2x' feature with a factor of 0.7. The quality factor on |
2821 |
`larger_2x' would express the relative preference of getting a |
2822 |
variant which is about twice as large as the smallest variant. |
2823 |
Examples of overall quality factors computed using this header |
2824 |
would be: |
2825 |
|
2826 |
0.8 for {"small" 0.8 {features tables}} |
2827 |
0.7 for {"large" 1.0 {features tables larger_2x/1}} |
2828 |
|
2829 |
In this example, the small variant is chosen: the resource author |
2830 |
assigned a lower source quality to the small variant, but the |
2831 |
difference in source quality was not big enough to offset the |
2832 |
user's dislike of getting a variant which is twice as large. Note |
2833 |
that the `/1' causes user agents which do not recognize the |
2834 |
`larger_2x' tag to select the large variant. |
2835 |
|
2836 |
The proposed semantics for quality factors on feature tags are as |
2837 |
follows. First, the Accept-Features headers element |
2838 |
|
2839 |
ftag;q=Q |
2840 |
|
2841 |
assigns the quality factor Q to the feature predicate `ftag' made |
2842 |
true by it, and the elements |
2843 |
|
2844 |
ftag=V;q=Q ftag={V};q=Q ftag<=N;q=Q |
2845 |
|
2846 |
assign the quality value Q to all feature predicates `ftag=X' made |
2847 |
true by them, but not to the plain predicate `ftag'. All true |
2848 |
feature predicates not explicitly assigned a quality factor get the |
2849 |
default factor 1. |
2850 |
|
2851 |
To account for the quality factors on the feature tags, the overall |
2852 |
quality of the variant is multiplied with the quality factor |
2853 |
of every `active feature predicate' in the variant description. |
2854 |
A predicate is active if it |
2855 |
|
2856 |
1. is made true by the Accept-Features header |
2857 |
|
2858 |
2. does not start with ! |
2859 |
|
2860 |
3. and, if appearing in an fpred-bag, does not appear after |
2861 |
another predicate which also satisfies 1. and 2. |
2862 |
|
2863 |
As an example, with |
2864 |
|
2865 |
Accept-Features: aa, !bb, cc;q=0.7, dd, * |
2866 |
|
2867 |
the variant described as |
2868 |
|
2869 |
{"x" 1.0 {features aa/0.8 !xx !bb [!yy cc dd]}} |
2870 |
|
2871 |
has the active feature predicates `aa' and `cc', while the `!bb' |
2872 |
and `dd' predicates are not active. |
2873 |
|
2874 |
Note: If a user sends quality factors with feature tags not |
2875 |
specifically designed to have them, this will in general not |
2876 |
produce improved negotiation results. For example, depending |
2877 |
on the particular variant list, sending `animated_gifs;q=0.8' |
2878 |
to express a mild dislike of animated gifs can easily fail to |
2879 |
be effective. Sending `!animated_gives' could be a bit more |
2880 |
effective, but only a user agent configuration option which |
2881 |
completely disables animated gifs can deliver good results in |
2882 |
all cases. |
2883 |
|
2884 |
|
2885 |
|
2886 |
19.4 Other negotiation specifications |
2887 |
|
2888 |
19.4.1 User-Agent Display Attributes |
2889 |
|
2890 |
(Comments based on the internet draft |
2891 |
draft-mutz-http-attributes-01.txt.) |
2892 |
|
2893 |
User-Agent Display Attributes provide a means for an HTTP client to |
2894 |
inform a server about its display capabilities. The draft |
2895 |
mentioned above defines a number of such attributes as feature |
2896 |
tags. |
2897 |
|
2898 |
19.4.2 HTTP/1.2 Extension Protocol (PEP) |
2899 |
|
2900 |
(Comments based on the internet draft draft-ietf-http-pep-02.txt.) |
2901 |
|
2902 |
PEP is a system for HTTP clients, servers, and proxies to reliably |
2903 |
reason about custom extensions to HTTP. Its purpose places PEP one |
2904 |
meta-level above transparent content negotiation, which is intended |
2905 |
as a (standardized) extension of HTTP. |
2906 |
|
2907 |
Transparent content negotiation and HTTP/1.1 were both carefully |
2908 |
designed to work together without requiring meta-negotiation. |
2909 |
Therefore, transparent content negotiation does not require or rely |
2910 |
on the use of PEP. |
2911 |
|
2912 |
Though PEP and transparent content negotiation both offer |
2913 |
extensible negotiation frameworks, they operate in different areas |
2914 |
of negotiation. PEP negotiates on the use of mutually understood |
2915 |
protocol extensions, while transparent content negotiation is a |
2916 |
method for efficiently retrieving the best representation of some |
2917 |
information. Thus, deployment and use of PEP can be orthogonal to |
2918 |
deployment and use of transparent content negotiation. |
2919 |
|
2920 |
Though some elements of PEP resemble some elements of transparent |
2921 |
content negotiation, it does not seem advantageous to attempt to |
2922 |
generalize (parts of) both specifications in order to allow sharing |
2923 |
of code by implementations. The two specifications seem to have |
2924 |
more unrelated parts than similar parts. |
2925 |
|
2926 |
|
2927 |
19.5 Related issues |
2928 |
|
2929 |
19.5.1 Current negotiation practice |
2930 |
|
2931 |
In current practice, most user agents send short Accept headers in |
2932 |
every request. These headers usually inadequately describe the |
2933 |
user agent capabilities and user preferences, except maybe for |
2934 |
inline image requests. Servers providing multiple representations |
2935 |
of the same information usually do so under different URIs, and |
2936 |
allow users to manually select a representation by clicking a |
2937 |
particular link. |
2938 |
|
2939 |
Some HTTP servers implement extensive negotiation capabilities |
2940 |
based on HTTP/1.0 headers. However, with current user agents, |
2941 |
these capabilities can seldom be used effectively. |
2942 |
|
2943 |
Some origin servers use the contents of the User-Agent request |
2944 |
header for negotiation purposes. These contents sometimes allow |
2945 |
the server to infer information about capabilities which cannot be |
2946 |
expressed with the existing Accept headers. |
2947 |
|
2948 |
Some sites use Netscape cookies (persistent client state http |
2949 |
cookies) to implement a user preferences mechanism. |
2950 |
|
2951 |
19.5.2 Bandwidth negotiation |
2952 |
|
2953 |
With a bandwidth negotiation mechanism, the time needed to retrieve |
2954 |
a particular variant over the network can be taken into account |
2955 |
during the negotiation process. Work on mechanisms for bandwidth |
2956 |
negotiation has been done since at least 1993, but this work has |
2957 |
not yet yielded a successful standard mechanism for bandwidth |
2958 |
negotiation. Cascaded proxy caches introduce additional complexity |
2959 |
in this area. |
2960 |
|
2961 |
This specification does not attempt to solve the problem of |
2962 |
bandwidth negotiation. There is some hope that the feature |
2963 |
negotiation framework will allow the introduction of an adequate |
2964 |
solution for bandwidth negotiation. |
2965 |
|
2966 |
|
2967 |
Expires: May 21, 1997 |