1 |
|
2 |
HTTP Working Group Koen Holtman, TUE |
3 |
Internet-Draft Andrew Mutz, Hewlett-Packard |
4 |
Expires: March 15, 1998 September 15, 1997 |
5 |
|
6 |
|
7 |
The Alternates Header Field |
8 |
|
9 |
draft-ietf-http-alternates-00.txt |
10 |
|
11 |
|
12 |
STATUS OF THIS MEMO |
13 |
|
14 |
This document is an Internet-Draft. Internet-Drafts are |
15 |
working documents of the Internet Engineering Task Force |
16 |
(IETF), its areas, and its working groups. Note that other |
17 |
groups may also distribute working documents as |
18 |
Internet-Drafts. |
19 |
|
20 |
Internet-Drafts are draft documents valid for a maximum of |
21 |
six months and may be updated, replaced, or obsoleted by |
22 |
other documents at any time. It is inappropriate to use |
23 |
Internet-Drafts as reference material or to cite them other |
24 |
than as "work in progress". |
25 |
|
26 |
To learn the current status of any Internet-Draft, please |
27 |
check the "1id-abstracts.txt" listing contained in the |
28 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
29 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
30 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
31 |
West Coast). |
32 |
|
33 |
Distribution of this document is unlimited. Please send |
34 |
comments to the HTTP working group at |
35 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
36 |
group are archived at |
37 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
38 |
discussions about HTTP and the applications which use HTTP |
39 |
should take place on the <www-talk@w3.org> mailing list. |
40 |
|
41 |
HTML and change bar versions of this document are available |
42 |
at <URL:http://gewis.win.tue.nl/~koen/conneg/>. |
43 |
|
44 |
|
45 |
ABSTRACT |
46 |
|
47 |
HTTP allows web site authors to put multiple versions of the |
48 |
same information under a single URL. The Alternates header |
49 |
field can be used to transmit a machine-readable description |
50 |
of these versions. This allows the recipient to automatically |
51 |
select the most appropriate version. |
52 |
|
53 |
|
54 |
TABLE OF CONTENTS |
55 |
|
56 |
1 Introduction |
57 |
1.1 Background |
58 |
1.2 Applicability |
59 |
|
60 |
2 Terminology |
61 |
2.1 Terms from HTTP/1.1 |
62 |
2.2 New terms |
63 |
|
64 |
3 Notation |
65 |
|
66 |
4 The Alternates header field |
67 |
4.1 Definition |
68 |
4.2 Length of variant lists |
69 |
|
70 |
5 Variant descriptions |
71 |
5.1 Syntax |
72 |
5.2 URI |
73 |
5.3 Source-quality |
74 |
5.4 Type, charset, language, and length |
75 |
5.5 Extension-attribute |
76 |
|
77 |
6 Use of the Alternates header field |
78 |
6.1 Use in a response which contains a variant |
79 |
6.2 Use in a response which does not contain a variant |
80 |
6.3 Use in a response which redirects to a variant |
81 |
6.4 User agent guidelines |
82 |
6.5 Negotiation on content encoding |
83 |
6.6 Role of proxies |
84 |
|
85 |
7 Security and privacy considerations |
86 |
7.1 User agent choices revealing information of a private nature |
87 |
7.2 Security holes revealed by negotiation |
88 |
|
89 |
8 Acknowledgments |
90 |
|
91 |
9 References |
92 |
|
93 |
10 Authors' addresses |
94 |
|
95 |
11 Appendix: Example of a variant selection algorithm |
96 |
11.1 Computing overall quality values |
97 |
11.2 Determining the result |
98 |
11.3 Ranking dimensions |
99 |
|
100 |
|
101 |
1 Introduction |
102 |
|
103 |
HTTP allows web site authors to put multiple versions of the same |
104 |
information under a single URI. Each of these versions is called a |
105 |
`variant'. The Alternates header field can be used to transmit a |
106 |
machine-readable description of these variants. This allows the |
107 |
recipient to automatically select the most appropriate variant. |
108 |
|
109 |
This specification defines the Alternates header field as part of |
110 |
the HTTP/1.x protocol suite [1]. |
111 |
|
112 |
Note: Though this specification is limited to discussing HTTP |
113 |
transactions, elements of this specification could also be used |
114 |
in other contexts. For example, variant descriptions could be |
115 |
used in multipart mail messages. |
116 |
|
117 |
|
118 |
1.1 Background |
119 |
|
120 |
HTTP/1.1 allows web site authors to put multiple versions of the |
121 |
same information under a single resource URI. Each of these |
122 |
versions is called a `variant'. For example, a resource |
123 |
http://x.org/paper could offer three different variants of a paper: |
124 |
|
125 |
1. HTML, English |
126 |
2. HTML, French |
127 |
3. Postscript, English |
128 |
|
129 |
Content negotiation is the process by which the best variant is |
130 |
selected if the resource is accessed. The selection is done by |
131 |
matching the properties of the available variants to the |
132 |
capabilities of the user agent and the preferences of the user. |
133 |
|
134 |
HTTP/1.1 [1] defines three forms of content negotiation: |
135 |
|
136 |
1. Server-driven content negotiation, in which the origin server |
137 |
selects the best variant |
138 |
|
139 |
2. Agent-driven content negotiation, in which the user agent |
140 |
selects the best variant |
141 |
|
142 |
3. Transparent content negotiation, in which a a distributed |
143 |
process is used to choose the best variant, with either the |
144 |
user agent, the origin server, or a proxy in between making |
145 |
the final choice. |
146 |
|
147 |
See [1] for a detailed definition of these three forms, and a |
148 |
discussion of their individual advantages and disadvantages. |
149 |
HTTP/1.1 only defines the protocol elements necessary to support |
150 |
server-driven negotiation. This document defines the Alternates |
151 |
header field as a way of supporting agent-driven negotiation. The |
152 |
protocol elements needed for transparent content negotiation are |
153 |
defined in [4]. |
154 |
|
155 |
|
156 |
1.2 Applicability |
157 |
|
158 |
This specification allows for agent-driven negotiation, using a |
159 |
subset of the protocol elements in [4]. Implementations based on |
160 |
this specification will be able to co-exist with implementations |
161 |
based on plain HTTP/1.0 [3], plain HTTP/1.1 [1], and with |
162 |
implementations using all protocol elements in [4]. |
163 |
|
164 |
|
165 |
2 Terminology |
166 |
|
167 |
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in |
168 |
this document are to be interpreted as described in RFC 2119 [5]. |
169 |
|
170 |
|
171 |
2.1 Terms from HTTP/1.1 |
172 |
|
173 |
This specification mostly uses the terminology of the HTTP/1.1 |
174 |
specification [1]. The definitions below were reproduced from [1]. |
175 |
|
176 |
request |
177 |
An HTTP request message. |
178 |
|
179 |
response |
180 |
An HTTP response message. |
181 |
|
182 |
resource |
183 |
A network data object or service that can be identified by a URI. |
184 |
Resources may be available in multiple representations |
185 |
(e.g. multiple languages, data formats, size, resolutions) or |
186 |
vary in other ways. |
187 |
|
188 |
content negotiation |
189 |
The mechanism for selecting the appropriate representation when |
190 |
servicing a request. |
191 |
|
192 |
client |
193 |
A program that establishes connections for the purpose of sending |
194 |
requests. |
195 |
|
196 |
user agent |
197 |
The client which initiates a request. These are often browsers, |
198 |
editors, spiders (web-traversing robots), or other end user |
199 |
tools. |
200 |
|
201 |
server |
202 |
An application program that accepts connections in order to |
203 |
service requests by sending back responses. Any given program may |
204 |
be capable of being both a client and a server; our use of these |
205 |
terms refers only to the role being performed by the program for |
206 |
a particular connection, rather than to the program's |
207 |
capabilities in general. Likewise, any server may act as an |
208 |
origin server, proxy, gateway, or tunnel, switching behavior |
209 |
based on the nature of each request. |
210 |
|
211 |
origin server |
212 |
The server on which a given resource resides or is to be created. |
213 |
|
214 |
proxy |
215 |
An intermediary program which acts as both a server and a client |
216 |
for the purpose of making requests on behalf of other |
217 |
clients. Requests are serviced internally or by passing them on, |
218 |
with possible translation, to other servers. A proxy must |
219 |
implement both the client and server requirements of this |
220 |
specification. |
221 |
|
222 |
|
223 |
2.2 New terms |
224 |
|
225 |
negotiable resource |
226 |
A resource, identified by a single URI, which has multiple |
227 |
representations (variants) associated with it. When servicing a |
228 |
request on its URI, it allows selection of the best |
229 |
variant using some form of content negotiation. |
230 |
|
231 |
variant list |
232 |
A list containing variant descriptions, which can be bound to a |
233 |
negotiable resource. |
234 |
|
235 |
variant description |
236 |
A machine-readable description of a variant resource, usually |
237 |
found in a variant list. A variant description contains the |
238 |
variant resource URI and various attributes which describe |
239 |
properties of the variant. Variant descriptions are defined in |
240 |
section 5. |
241 |
|
242 |
variant resource |
243 |
A resource from which a variant of a negotiable resource can be |
244 |
retrieved with a normal HTTP/1.x GET request, i.e. a GET request |
245 |
which does not use content negotiation. |
246 |
|
247 |
variant selection algorithm |
248 |
An algorithm which can choose the best variant from a variant |
249 |
list. |
250 |
|
251 |
|
252 |
3 Notation |
253 |
|
254 |
The version of BNF used in this document is taken from [1], and |
255 |
many of the nonterminals used are defined in [1]. |
256 |
|
257 |
|
258 |
4 The Alternates header field |
259 |
|
260 |
When returning a particular piece of content, a server may wish to |
261 |
notify the client that this content is available in multiple |
262 |
variants. This can be done by adding an Alternates header field, |
263 |
which lists the available variants, to the response. The |
264 |
Alternates header field can also be used in a response which does |
265 |
not include any particular variant, but which simply informs the |
266 |
client that multiple variants are available. |
267 |
|
268 |
An example of an alternates response header field, which lists |
269 |
three variants, is |
270 |
|
271 |
Alternates: {"paper.1" 0.9 {type text/html} {language en}}, |
272 |
{"paper.2" 0.7 {type text/html} {language fr}}, |
273 |
{"paper.3" 1.0 {type application/postscript} |
274 |
{language en}} |
275 |
|
276 |
On receipt of an Alternates header field, a user agent can use a |
277 |
variant selection algorithm to choose the best variant from the |
278 |
list. This specification does not define a standard variant |
279 |
selection algorithm, user agent implementers may use whichever |
280 |
algorithm they find most suitable. Appendix 11 contains an example |
281 |
of a variant selection algorithm. |
282 |
|
283 |
|
284 |
4.1 Definition |
285 |
|
286 |
The Alternates response header field describes all available |
287 |
variants for the resource on which the request was made. The |
288 |
description for each variant includes an URI from which this |
289 |
variant can be retrieved. The Alternates header field can also |
290 |
contain directives for any negotiation process which is initiated |
291 |
by the receipt of the response. |
292 |
|
293 |
Alternates = "Alternates" ":" variant-list |
294 |
|
295 |
variant-list = 1#( variant-description ; see section 5 |
296 |
| fallback-variant |
297 |
| negotiation-directive ) |
298 |
|
299 |
fallback-variant = "{" <"> URI <"> "}" |
300 |
|
301 |
negotiation-directive = token [ "=" ( token | quoted-string ) ] |
302 |
|
303 |
An example is |
304 |
|
305 |
Alternates: {"paper.1" 0.9 {type text/html} {language en}}, |
306 |
{"paper.2" 0.7 {type text/html} {language fr}}, |
307 |
{"paper.3" 1.0 {type application/postscript} |
308 |
{language en}}, |
309 |
{"paper.html.en"}, x=y |
310 |
|
311 |
Any relative URI specified in a variant-description or |
312 |
fallback-variant field is relative to the request-URI. |
313 |
|
314 |
A variant list may contain multiple differing descriptions of the |
315 |
same variant. This can be convenient if the variant uses |
316 |
conditional rendering constructs, or if the variant resource |
317 |
returns multiple representations using a multipart media type. |
318 |
|
319 |
Only one fallback-variant field may be present. If the variant |
320 |
selection algorithm of the user agent finds that all variants |
321 |
described by variant-description fields are unacceptable, then it |
322 |
SHOULD choose the fallback variant, if present, as the best |
323 |
variant. If the user agent computes the overall quality values of |
324 |
the described variants, and finds that several variants share the |
325 |
highest value, then the first variant with this value in the list |
326 |
SHOULD be chosen as the best variant. |
327 |
|
328 |
This specification does not define any specific negotiation |
329 |
directives for the Alternates header field. User agents SHOULD |
330 |
ignore all negotiation directives they do not understand. If a |
331 |
proxy receives an Alternates header field with an unknown |
332 |
negotiation directive, it SHOULD, whenever possible, forward the |
333 |
response towards the user agent instead of trying to take part in a |
334 |
negotiation process itself. |
335 |
|
336 |
|
337 |
4.2 Length of variant lists |
338 |
|
339 |
As a general rule, variant lists in Alternates header fields should |
340 |
be short: it is expected that a typical negotiable resource will |
341 |
have 2 to 10 variants, depending on its purpose. Servers which |
342 |
have many more variants SHOULD use a method of describing them |
343 |
which is more sophisticated than the Alternates header field |
344 |
defined in this document. |
345 |
|
346 |
|
347 |
5 Variant descriptions |
348 |
|
349 |
5.1 Syntax |
350 |
|
351 |
A variant can be described in a machine-readable way with a variant |
352 |
description. |
353 |
|
354 |
variant-description = |
355 |
"{" <"> URI <"> source-quality *variant-attribute"}" |
356 |
|
357 |
source-quality = qvalue |
358 |
|
359 |
variant-attribute = "{" "type" media-type "}" |
360 |
| "{" "charset" charset "}" |
361 |
| "{" "language" 1#language-tag "}" |
362 |
| "{" "length" 1*DIGIT "}" |
363 |
| extension-attribute |
364 |
|
365 |
extension-attribute = "{" extension-name extension-value "}" |
366 |
extension-name = token |
367 |
extension-value = *( token | quoted-string | LWS |
368 |
| extension-specials ) |
369 |
|
370 |
extension-specials = |
371 |
<any element of tspecials except <"> and "}"> |
372 |
|
373 |
Examples are |
374 |
|
375 |
{"paper.2" 0.7 {type text/html} {language fr}} |
376 |
|
377 |
{"paper.5" 0.9 {type text/html} {length 1002}} |
378 |
|
379 |
{"paper.1" 0.001} |
380 |
|
381 |
The various attributes which can be present in a variant |
382 |
description are covered in the subsections below. Each attribute |
383 |
may appear only once in a variant description. |
384 |
|
385 |
|
386 |
5.2 URI |
387 |
|
388 |
The URI attribute gives the URI of the resource from which the |
389 |
variant can be retrieved with a GET request. It can be absolute or |
390 |
relative to the Request-URI. The variant resource may vary the |
391 |
content it sends (on the Cookie request header field, for example), |
392 |
but SHOULD NOT engage in content negotiation itself. |
393 |
|
394 |
|
395 |
5.3 Source-quality |
396 |
|
397 |
The source-quality attribute gives the quality of the variant, as a |
398 |
representation of the negotiable resource, when this variant is |
399 |
rendered with a perfect rendering engine on the best possible |
400 |
output medium. |
401 |
|
402 |
If the source-quality is less than 1, it often expresses a quality |
403 |
degradation caused by a lossy conversion to a particular data |
404 |
format. For example, a picture originally in JPEG form would have |
405 |
a lower source quality when translated to the XBM format, and a |
406 |
much lower source quality when translated to an ASCII-art variant. |
407 |
Note however, that degradation is a function of the source; an |
408 |
original piece of ASCII-art may degrade in quality if it is |
409 |
captured in JPEG form. |
410 |
|
411 |
The source-quality could also represent a level of quality caused |
412 |
by skill of language translation, or ability of the used media type |
413 |
to capture the intended artistic expression. |
414 |
|
415 |
Servers should use the following table a guide when assigning |
416 |
source quality values: |
417 |
|
418 |
1.000 perfect representation |
419 |
0.900 threshold of noticeable loss of quality |
420 |
0.800 noticeable, but acceptable quality reduction |
421 |
0.500 barely acceptable quality |
422 |
0.300 severely degraded quality |
423 |
0.000 completely degraded quality |
424 |
|
425 |
The same table can be used by variant selection algorithms in user |
426 |
agents (see appendix 11) when assigning degradation factors for |
427 |
different content rendering mechanisms. Note that most meaningful |
428 |
values in this table are close to 1. This is due to the fact that |
429 |
quality degradation factors are generally combined by multiplying |
430 |
them, not by adding them. |
431 |
|
432 |
In the source-quality values, servers should not account for the |
433 |
size of the variant and its impact on transmission and rendering |
434 |
delays; the size of the variant should be stated in the length |
435 |
attribute and any size-dependent calculations should be done by a |
436 |
variant selection algorithm in the user agent. |
437 |
|
438 |
|
439 |
5.4 Type, charset, language, and length |
440 |
|
441 |
The type attribute of a variant description carries the same |
442 |
information as its Content-Type response header field counterpart |
443 |
defined in [1], except for any charset information, which MUST be |
444 |
carried in the charset attribute. For, example, the header field |
445 |
|
446 |
Content-Type: text/html; charset=ISO-8859-4 |
447 |
|
448 |
has the counterpart attributes |
449 |
|
450 |
{type text/html} {charset ISO-8859-4} |
451 |
|
452 |
The language and length attributes carry the same information as |
453 |
their Content-* response header field counterparts in [1]. The |
454 |
length attribute, if present, MUST thus reflect the length of the |
455 |
variant alone, and not the total size of the variant and any |
456 |
objects inlined or embedded by the variant. |
457 |
|
458 |
Though all of these attributes are optional, it is often desirable |
459 |
to include as many attributes as possible, as this will increase |
460 |
the quality of the negotiation process. |
461 |
|
462 |
Note: A server is not required to maintain a one-to-one |
463 |
correspondence between the attributes in the variant description |
464 |
and the Content-* header fields in the variant response. For |
465 |
example, if the variant description contains a language |
466 |
attribute, the response does not necessarily have to contain a |
467 |
Content-Language header field. If a Content-Language header |
468 |
field is present, it does not have to contain an exact copy of |
469 |
the information in the language attribute. |
470 |
|
471 |
|
472 |
5.5 Extension-attribute |
473 |
|
474 |
The extension-attribute allows future specifications to |
475 |
incrementally define new dimensions of negotiation, and eases |
476 |
content negotiation experiments. User agents conforming to this |
477 |
specification SHOULD treat all variants with extension attributes |
478 |
they do not recognize as unusable. Proxies SHOULD NOT do any |
479 |
negotiation processing for a response if an extension attribute |
480 |
unknown to them is present in the variant list. They SHOULD |
481 |
forward the response unchanged towards the user agent instead. |
482 |
|
483 |
The extension names "features" and "description" are reserved by |
484 |
this specification for use in transparent content negotiation [4]. |
485 |
|
486 |
|
487 |
6 Use of the Alternates header field |
488 |
|
489 |
This section defines conventions and guidelines for the use of the |
490 |
Alternates header field. |
491 |
|
492 |
|
493 |
6.1 Use in a response which contains a variant |
494 |
|
495 |
If a request is done on a negotiable resource, the server may |
496 |
return a particular variant in the response, together with an |
497 |
Alternates header field which notifies the client that multiple |
498 |
variants are available. An example of such a response is: |
499 |
|
500 |
HTTP/1.1 200 OK |
501 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
502 |
Content-Type: text/html |
503 |
Content-Language: en |
504 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
505 |
Content-Length: 5327 |
506 |
Alternates: {"paper.1" 0.9 {type text/html} {language en}}, |
507 |
{"paper.2" 0.7 {type text/html} {language fr}}, |
508 |
{"paper.3" 1.0 {type application/postscript} |
509 |
{language en}} |
510 |
Content-Location: paper.1 |
511 |
Vary: * |
512 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
513 |
Cache-Control: max-age=604800 |
514 |
|
515 |
<title>A paper about .... |
516 |
|
517 |
In this response, the Content-Location header field tells the user |
518 |
agent which variant was included. The Vary, Expires, and |
519 |
Cache-Control header fields ensure proper handling of the response |
520 |
by HTTP/1.0 and HTTP/1.1 caches. |
521 |
|
522 |
When detecting that an Alternates header field is present, a user |
523 |
agent MAY choose to use a variant selection algorithm to select the |
524 |
best variant of the negotiable resource. If the best variant is |
525 |
not the same one as is included in the response (as identified by |
526 |
the Content-Location header field), the user agent MAY do a new |
527 |
request on the variant resource of the best variant in order to |
528 |
retrieve it. |
529 |
|
530 |
|
531 |
6.2 Use in a response which does not contain a variant |
532 |
|
533 |
If the response to a request on a negotiable resource does not |
534 |
contain a particular variant, the origin server should signal this |
535 |
by not including any Content-Location header field. An example of |
536 |
such a response is: |
537 |
|
538 |
HTTP/1.1 200 OK |
539 |
Date: Tue, 11 Jun 1996 20:02:21 GMT |
540 |
Content-Type: text/html |
541 |
Content-Length: 227 |
542 |
Alternates: {"paper.1" 0.9 {type text/html} {language en}}, |
543 |
{"paper.2" 0.7 {type text/html} {language fr}}, |
544 |
{"paper.3" 1.0 {type application/postscript} |
545 |
{language en}} |
546 |
Vary: * |
547 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
548 |
Cache-Control: max-age=604800 |
549 |
|
550 |
<h2>Multiple Choices:</h2> |
551 |
<ul> |
552 |
<li><a href=paper.1>HTML, English version</a> |
553 |
<li><a href=paper.2>HTML, French version</a> |
554 |
<li><a href=paper.3>Postscript, English version</a> |
555 |
</ul> |
556 |
|
557 |
On receipt of such a response, the user agent SHOULD use a variant |
558 |
selection algorithm to select the best variant of the negotiable |
559 |
resource, and retrieve this variant. For compatibility with user |
560 |
agents which are not capable of handling the Alternates header |
561 |
field, a response body which allows the user to select the best |
562 |
variant manually can be included. |
563 |
|
564 |
|
565 |
6.3 Use in a response which redirects to a variant |
566 |
|
567 |
By putting an Alternates header field in a redirection response, an |
568 |
origin server can avoid the sending of a variant, which may be the |
569 |
wrong variant, to a user agent capable of using the Alternates |
570 |
header field, while still providing automatic selection for user |
571 |
agents which are not capable of using the Alternates header field. |
572 |
An example of such a response is: |
573 |
|
574 |
HTTP/1.1 302 Moved Temporarily |
575 |
Date: Tue, 11 Jun 1996 20:05:31 GMT |
576 |
Content-Type: text/html |
577 |
Alternates: {"paper.1" 0.9 {type text/html} {language en}}, |
578 |
{"paper.2" 0.7 {type text/html} {language fr}}, |
579 |
{"paper.3" 1.0 {type application/postscript} |
580 |
{language en}} |
581 |
Location: paper.1 |
582 |
Content-Length: 53 |
583 |
|
584 |
This document is available <a href=paper.1>here</a>. |
585 |
|
586 |
Note the use of a Location header field instead of a |
587 |
Content-Location header field. On receipt of such a response, the |
588 |
user agent SHOULD use a variant selection algorithm to select the |
589 |
best variant of the negotiable resource, and retrieve this variant. |
590 |
|
591 |
|
592 |
6.4 User agent guidelines |
593 |
|
594 |
Summarizing the three sections above, if an Alternates header field |
595 |
is present in the response, then |
596 |
|
597 |
* a user agent SHOULD use its variant selection algorithm to |
598 |
choose and retrieve the best variant if a Content-Location |
599 |
header field is absent, |
600 |
|
601 |
* and MAY use its variant selection algorithm to choose and |
602 |
retrieve the best variant if a Content-Location header field |
603 |
is present. |
604 |
|
605 |
If the user agent is displaying a variant as the result of a |
606 |
content negotiation process, and the variant is not an embedded or |
607 |
inlined object, the following requirements apply. |
608 |
|
609 |
1. The user agent SHOULD make available though its user interface |
610 |
some indication that the resource being displayed is a |
611 |
negotiated resource instead of a plain resource. It SHOULD |
612 |
also allow the user to examine the variant list included in the |
613 |
Alternates header field. Such a notification and review |
614 |
mechanism is needed because of privacy considerations, see |
615 |
section 7.1. |
616 |
|
617 |
2. If the user agent shows the URI of the displayed information to |
618 |
the user, it SHOULD be the negotiable resource URI, not the |
619 |
variant URI that is shown. This encourages third parties, who |
620 |
want to refer to the displayed information in their own |
621 |
documents, to make a hyperlink to the negotiable resource as a |
622 |
whole, rather than to the variant resource which happens to be |
623 |
shown. Such correct linking is vital for the interoperability |
624 |
of content across sites. The user agent SHOULD however also |
625 |
provide a means for reviewing the URI of the particular variant |
626 |
which is currently being displayed. |
627 |
|
628 |
3. Similarly, if the user agent stores a reference to the |
629 |
displayed information for future use, for example in a hotlist, |
630 |
it SHOULD store the negotiable resource URI, not the variant |
631 |
URI. |
632 |
|
633 |
|
634 |
6.5 Negotiation on content encoding |
635 |
|
636 |
Negotiation on the content encoding of a response is orthogonal to |
637 |
content negotiation based on the Alternates header field. The |
638 |
presence of an Alternates header field in a response does not |
639 |
change the rules, as stated by the HTTP/1.1 specification [1], |
640 |
which determine when a content-encoding may be added or removed by |
641 |
an origin server or proxy. |
642 |
|
643 |
|
644 |
6.6 Role of proxies |
645 |
|
646 |
This specification does not define mechanisms by which proxies can |
647 |
use the Alternates header field, but does allow other |
648 |
specifications to define such mechanisms. To ensure extensibility |
649 |
of the Alternates header field, this specification does however |
650 |
define, in section 4.1 and section 5.5, that a proxy should not |
651 |
engage in a negotiation process when encountering an Alternates |
652 |
header field which has a component unknown to it. |
653 |
|
654 |
|
655 |
7 Security and privacy considerations |
656 |
|
657 |
7.1 User agent choices revealing information of a private nature |
658 |
|
659 |
The automatic selection and retrieval of a variant by a user agent |
660 |
will reveal a preference for this variant to the server. A |
661 |
malicious service author could provide a page with `fake' |
662 |
negotiability on (ethnicity-correlated) languages, with all |
663 |
variants actually being the same English document, as a means of |
664 |
obtaining privacy-sensitive information. Such a plot would however |
665 |
be visible to an alert victim if the list of available variants and |
666 |
their properties is reviewed through a mechanism as described in |
667 |
section 6.4. |
668 |
|
669 |
7.2 Security holes revealed by negotiation |
670 |
|
671 |
Malicious servers could use content negotiation as a means of |
672 |
obtaining information about security holes which may be present in |
673 |
user agents. |
674 |
|
675 |
|
676 |
8 Acknowledgments |
677 |
|
678 |
Work on HTTP content negotiation has been done since at least 1993. |
679 |
This specification builds on an earlier incomplete specification of |
680 |
the Alternates header field recorded in [2]. The authors wish to |
681 |
thank the individuals who have contributed to the work on content |
682 |
negotiation in the HTTP working group, including Brian Behlendorf, |
683 |
Daniel DuBois, Martin J. Duerst, Roy T. Fielding, Jim Gettys, Yaron |
684 |
Goland, Dirk van Gulik, Ted Hardie, Graham Klyne, Scott Lawrence, |
685 |
Larry Masinter, Jeffrey Mogul, Henrik Frystyk Nielsen, Frederick |
686 |
G.M. Roeber, Paul Sutton, and Klaus Weide. |
687 |
|
688 |
|
689 |
9 References |
690 |
|
691 |
[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and |
692 |
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC |
693 |
2068, HTTP Working Group, January 1997. |
694 |
|
695 |
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. |
696 |
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft |
697 |
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January |
698 |
1996. |
699 |
|
700 |
[3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext |
701 |
Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, |
702 |
May 1996. |
703 |
|
704 |
[4] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. |
705 |
Internet-Draft draft-ietf-http-negotiation-04.txt, HTTP Working |
706 |
Group, September 1997. |
707 |
|
708 |
[5] S. Bradner. Key words for use in RFCs to Indicate Requirement |
709 |
Levels. RFC 2119. Harvard University, March 1997. |
710 |
|
711 |
|
712 |
10 Authors' addresses |
713 |
|
714 |
Koen Holtman |
715 |
Technische Universiteit Eindhoven |
716 |
Postbus 513 |
717 |
Kamer HG 6.57 |
718 |
5600 MB Eindhoven (The Netherlands) |
719 |
Email: koen@win.tue.nl |
720 |
|
721 |
Andrew H. Mutz |
722 |
Hewlett-Packard Company |
723 |
1501 Page Mill Road 3U-3 |
724 |
Palo Alto CA 94304, USA |
725 |
Fax +1 415 857 4691 |
726 |
Email: mutz@hpl.hp.com |
727 |
|
728 |
|
729 |
11 Appendix: Example of a variant selection algorithm |
730 |
|
731 |
A negotiating user agent will choose the best variant from a |
732 |
variant list with a variant selection algorithm. This appendix |
733 |
contains an example of such an algorithm. |
734 |
|
735 |
The inputs of the algorithm are a variant list from an Alternates |
736 |
header field, and an agent-side configuration database, which |
737 |
contains |
738 |
|
739 |
- a collection of quality values assigned to media types, |
740 |
languages, and charsets for the current request, following the |
741 |
model of the corresponding HTTP/1.1 [1] Accept- header fields, |
742 |
|
743 |
- a table which lists `forbidden' combinations of media types and |
744 |
charsets, i.e. combinations which cannot be displayed because |
745 |
of some internal user agent limitation. |
746 |
|
747 |
The output of the algorithm is either the best variant, or the |
748 |
conclusion that none of the variants are acceptable. |
749 |
|
750 |
|
751 |
11.1 Computing overall quality values |
752 |
|
753 |
As a first step in the variant selection algorithm, the |
754 |
overall qualities associated with all variant descriptions in the |
755 |
list are computed. |
756 |
|
757 |
The overall quality Q of a variant description is the value |
758 |
|
759 |
Q = round5( qs * qt * qc * ql * qa ) |
760 |
|
761 |
where rounds5 is a function which rounds a floating point value to |
762 |
5 decimal places after the point. It is assumed that the user |
763 |
agent can run on multiple platforms: the rounding function makes |
764 |
the algorithm independent of the exact characteristics of the |
765 |
underlying floating point hardware. |
766 |
|
767 |
The factors qs, qt, qc, ql, and qa are determined as follows. |
768 |
|
769 |
qs Is the source quality factor in the variant description. |
770 |
|
771 |
qt The media type quality factor is 1 if there is no type |
772 |
attribute in the variant description. Otherwise, it is the |
773 |
quality value assigned to this type by the configuration |
774 |
database. If the database does not assign a value, then the |
775 |
factor is 0. |
776 |
|
777 |
qc The charset quality factor is 1 if there is no charset |
778 |
attribute in the variant description. Otherwise, it is the |
779 |
quality value assigned to this charset by the configuration |
780 |
database. If the database does not assign a value, then the |
781 |
factor is 0. |
782 |
|
783 |
ql The language quality factor is 1 if there is no language |
784 |
attribute in the variant description. Otherwise, it is the |
785 |
highest quality value the configuration database assigns to |
786 |
any of the languages listed in the language attribute. If |
787 |
the database does not assign a value to any of the languages |
788 |
listed, then the factor is 0. |
789 |
|
790 |
qa The quality adjustment factor is 0 if the variant description |
791 |
lists a media type - charset combination which is `forbidden' |
792 |
by the table, and 1 otherwise. |
793 |
|
794 |
As an example, if a variant list contains the variant description |
795 |
|
796 |
{"paper.2" 0.7 {type text/html} {language fr}} |
797 |
|
798 |
and if the configuration database contains the quality value |
799 |
assignments |
800 |
|
801 |
types: text/html;q=1.0, type application/postscript;q=0.8 |
802 |
languages: en;q=1.0, fr;q=0.5 |
803 |
|
804 |
then the variant selection algorithm will compute the overall |
805 |
quality for the variant description as follows: |
806 |
|
807 |
{"paper.2" 0.7 {type text/html} {language fr}} |
808 |
| | | |
809 |
| | | |
810 |
V V V |
811 |
round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000 |
812 |
|
813 |
With same configuration database, the variant list |
814 |
|
815 |
{"paper.1" 0.9 {type text/html} {language en}}, |
816 |
{"paper.2" 0.7 {type text/html} {language fr}}, |
817 |
{"paper.3" 1.0 {type application/postscript} {language en}} |
818 |
|
819 |
would yield the following computations: |
820 |
|
821 |
round5 ( qs * qt * qc * ql * qa ) = Q |
822 |
--- --- --- --- --- |
823 |
paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000 |
824 |
paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35000 |
825 |
paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.80000 |
826 |
|
827 |
|
828 |
11.2 Determining the result |
829 |
|
830 |
Using all computed overall quality values, the end result of the |
831 |
variant selection algorithm is determined as follows. |
832 |
|
833 |
If all overall quality values are 0, then the best variant is the |
834 |
fallback variant, if there is one in the Alternates header field, |
835 |
else the result is the conclusion that none of the variants are |
836 |
acceptable. |
837 |
|
838 |
If at least one overall quality value is greater than 0, then the |
839 |
best variant is the variant which has the description with the |
840 |
highest overall quality value, or, if there are multiple variant |
841 |
descriptions which share the highest overall quality value, the |
842 |
variant of the first variant description in the list which has this |
843 |
highest overall quality value. |
844 |
|
845 |
|
846 |
11.3 Ranking dimensions |
847 |
|
848 |
Consider the following variant list: |
849 |
|
850 |
{"paper.greek" 1.0 {language el} {charset ISO-8859-7}}, |
851 |
{"paper.english" 1.0 {language en} {charset ISO-8859-1}} |
852 |
|
853 |
It could be the case that the user prefers the language "el" over |
854 |
"en", while the user agent can render "ISO-8859-1" better than |
855 |
"ISO-8859-7". The result is that in the language dimension, the |
856 |
first variant is best, while the second variant is best in the |
857 |
charset dimension. In this situation, it would be preferable to |
858 |
choose the first variant as the best variant: the user settings in |
859 |
the language dimension should take precedence over the hard-coded |
860 |
values in the charset dimension. |
861 |
|
862 |
To express this ranking between dimensions, the user agent |
863 |
configuration database should have a higher spread in the quality |
864 |
values for the language dimension than for the charset dimension. |
865 |
For example, with |
866 |
|
867 |
languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ... |
868 |
|
869 |
charsets: ISO-8859-1;q=1.0, ISO-8859-7;q=0.95, |
870 |
ISO-8859-5;q=0.97, unicode-1-1;q=0, ... |
871 |
|
872 |
the first variant will have an overall quality of 0.95000, while |
873 |
the second variant will have an overall quality 0.70000. This |
874 |
makes the first variant the best variant. |
875 |
|
876 |
|
877 |
Expires: March 15, 1998 |
878 |
|