1 |
|
2 |
HTTP Working Group Koen Holtman, TUE |
3 |
Internet-Draft Andrew Mutz, Hewlett-Packard |
4 |
Expires: August 5, 1997 February 5, 1997 |
5 |
|
6 |
|
7 |
HTTP Remote Variant Selection Algorithm -- RVSA/1.0 |
8 |
|
9 |
draft-ietf-http-rvsa-v10-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. Transparent content |
49 |
negotiation is a mechanism for automatically selecting the |
50 |
best version when the URL is accessed. A remote variant |
51 |
selection algorithm can be used to speed up the transparent |
52 |
negotiation process. This document defines the remote variant |
53 |
selection algorithm with the version number 1.0. |
54 |
|
55 |
|
56 |
OVERVIEW OF THE TRANSPARENT CONTENT NEGOTIATION DOCUMENT SET |
57 |
|
58 |
An up-to-date overview of documents related to transparent content |
59 |
negotiation is maintained on the web page |
60 |
<URL:http://gewis.win.tue.nl/~koen/conneg/>. |
61 |
|
62 |
The transparent content negotiation document set currently consists |
63 |
of three series of internet drafts. |
64 |
|
65 |
1. draft-ietf-http-negotiation-XX.txt |
66 |
|
67 |
`Transparent Content Negotiation in HTTP' |
68 |
|
69 |
Defines the core mechanism. Standards track. |
70 |
|
71 |
2. draft-ietf-http-rvsa-v10-XX.txt (this document) |
72 |
|
73 |
`HTTP Remote Variant Selection Algorithm -- RVSA/1.0' |
74 |
|
75 |
Defines the remote variant selection algorithm version 1.0. |
76 |
Standards track. |
77 |
|
78 |
3. draft-ietf-http-feature-reg-XX.txt |
79 |
|
80 |
`Feature Tag Registration Procedures' |
81 |
|
82 |
Defines feature tag registration. Best Current Practice track. |
83 |
|
84 |
An additional document about `the core feature set', which may |
85 |
later become an informational RFC, may also appear. Currently, |
86 |
there are two internet drafts which discuss parts of what could be |
87 |
a core feature set: draft-mutz-http-attributes-XX.txt and |
88 |
draft-goland-http-headers-XX.txt |
89 |
|
90 |
Older versions of the text in documents 1 and 2 may be found in the |
91 |
draft-holtman-http-negotiation-XX.txt series of internet drafts. |
92 |
|
93 |
|
94 |
TABLE OF CONTENTS |
95 |
|
96 |
1 Introduction |
97 |
1.1 Revision history |
98 |
|
99 |
2 Terminology and notation |
100 |
|
101 |
3 The remote variant selection algorithm |
102 |
3.1 Input |
103 |
3.2 Output |
104 |
3.3 Computing overall quality values |
105 |
3.4 Definite and speculative quality values |
106 |
3.5 Determining the result |
107 |
|
108 |
4 Use of the algorithm |
109 |
4.1 Using quality factors to rank preferences |
110 |
4.2 Construction of short requests |
111 |
4.2.1 Collapsing Accept header elements |
112 |
4.2.2 Omitting Accept headers |
113 |
4.2.3 Dynamically lengthening requests |
114 |
4.3 Differences between the local and the remote algorithm |
115 |
4.3.1 Avoiding major differences |
116 |
4.3.2 Working around minor differences |
117 |
|
118 |
5 Security and privacy considerations |
119 |
|
120 |
6 Acknowledgments |
121 |
|
122 |
7 References |
123 |
|
124 |
8 Authors' addresses |
125 |
|
126 |
|
127 |
1 Introduction |
128 |
|
129 |
HTTP allows web site authors to put multiple versions (variants) of |
130 |
the same information under a single URL. Transparent content |
131 |
negotiation [5] is a mechanism for automatically selecting the best |
132 |
variant when the URL is accessed. A remote variant selection |
133 |
algorithm can be used by a server to choose a best variant on |
134 |
behalf of a negotiating user agent. The use of a remote algorithm |
135 |
can speed up the transparent negotiation process by eliminating a |
136 |
request-response round trip. |
137 |
|
138 |
This document defines the remote variant selection algorithm with |
139 |
the version number 1.0. The algorithm computes whether the Accept |
140 |
headers in the request contain sufficient information to allow a |
141 |
choice, and if so, which variant must be chosen. |
142 |
|
143 |
|
144 |
1.1 Revision history |
145 |
|
146 |
Most text in section 3 of this draft was taken from section 11 of |
147 |
the draft-holtman-http-negotiation-04.txt internet draft. Major |
148 |
changes are: |
149 |
|
150 |
- The scope of the `network negotiation algorithm' has been |
151 |
limited to variant selection by servers on behalf of the user |
152 |
agent only. The algorithm has been renamed to `remote variant |
153 |
selection algorithm'. |
154 |
|
155 |
In the text and HTML versions with change marks, change bars or |
156 |
change marks only appear in section 3. In the text version, all |
157 |
changes are marked, except changes in formatting and punctuation. |
158 |
In the HTML version, all changed words and symbols are typeset in |
159 |
bold text. Deletions and changes in punctuation are not marked. |
160 |
|
161 |
Section 4 of this draft contains almost exclusively new material. |
162 |
|
163 |
|
164 |
2 Terminology and notation |
165 |
|
166 |
This specification uses the terminology and notation of the HTTP |
167 |
transparent content negotiation specification [5]. |
168 |
|
169 |
|
170 |
3 The remote variant selection algorithm |
171 |
|
172 |
This section defines the remote variant selection algorithm with |
173 |
the version number 1.0. To implement this definition, a server may |
174 |
run any algorithm which gives equal results. |
175 |
|
176 |
Note: According to [5], servers are always free to return a list |
177 |
response instead of running a remote algorithm. Therefore, |
178 |
whenever a server may run a remote algorithm, it may also run a |
179 |
partial implementation of the algorithm, provided that the |
180 |
partial implementation always returns List_Response when it |
181 |
cannot compute the real result. |
182 |
|
183 |
|
184 |
3.1 Input |
185 |
|
186 |
The algorithm is always run for a particular request on a |
187 |
particular transparently negotiable resource. It takes the |
188 |
following information as input. |
189 |
|
190 |
1. The variant list of the resource, as present in the Alternates |
191 |
header of the resource. |
192 |
|
193 |
2. (Partial) Information about capabilities and preferences of the |
194 |
user agent for this particular request, as given in the Accept |
195 |
headers of the request. |
196 |
|
197 |
If a fallback variant description |
198 |
|
199 |
{"fallback.html"} |
200 |
|
201 |
is present in the Alternates header, the algorithm must interpret |
202 |
it as the variant description |
203 |
|
204 |
{"fallback.html" 0.00000000000000000001} |
205 |
|
206 |
The extremely low source quality value ensures that the fallback |
207 |
variant only gets chosen if all other options are exhausted. |
208 |
|
209 |
|
210 |
3.2 Output |
211 |
|
212 |
As its output, the remote variant selection algorithm and will |
213 |
yield the appropriate action to be performed. There are two |
214 |
possibilities: |
215 |
|
216 |
Choice_response |
217 |
|
218 |
The Accept headers contain sufficient information to make a |
219 |
choice on behalf of the user agent possible, and the best |
220 |
variant may be returned in a choice response. |
221 |
|
222 |
List_response |
223 |
|
224 |
The Accept headers do not contain sufficient information to |
225 |
make a choice on behalf of the user agent possible. A list |
226 |
response must be returned, allowing the user agent to make the |
227 |
choice itself. |
228 |
|
229 |
|
230 |
3.3 Computing overall quality values |
231 |
|
232 |
As a first step in the remote variant selection algorithm, the |
233 |
overall qualities of the individual variants in the list are |
234 |
computed. |
235 |
|
236 |
The overall quality Q of a variant is the value |
237 |
|
238 |
Q = qs * qt * qc * ql * qf |
239 |
|
240 |
where the factors qs, qt, qc, ql, and qf are determined as follows. |
241 |
|
242 |
qs Is the source quality factor in the variant description. |
243 |
|
244 |
qt The media type quality factor is 1 if there is no type |
245 |
attribute in the variant description, or if there is no |
246 |
Accept header in the request. Otherwise, it is the quality |
247 |
assigned by the Accept header to the media type in the type |
248 |
attribute. |
249 |
|
250 |
Note: If a type is matched by none of the elements of an |
251 |
Accept header, the Accept header assigns the quality factor |
252 |
0 to that type. |
253 |
|
254 |
qc The charset quality factor is 1 if there is no charset |
255 |
attribute in the variant description, or if there is no |
256 |
Accept-Charset header in the request. Otherwise, the charset |
257 |
quality factor is the quality assigned by the Accept-Charset |
258 |
header to the charset in the charset attribute, see section |
259 |
8.2 of [5]. |
260 |
|
261 |
ql The language quality factor is 1 if there is no language |
262 |
attribute in the variant description, or if there is no |
263 |
Accept-Language header in the request. Otherwise, the |
264 |
language quality factor is the highest quality factor |
265 |
assigned by the Accept-Language header to any one of the |
266 |
languages listed in the language attribute. |
267 |
|
268 |
qf The features quality factor is 1 if there is no features |
269 |
attribute in the variant description, or if there is no |
270 |
Accept-Features header in the request. Otherwise, it is the |
271 |
quality degradation factor for the features attribute, see |
272 |
section 6.4 of [5]. |
273 |
|
274 |
As an example, if a variant list contains the variant description |
275 |
|
276 |
{"paper.html.en" 0.7 {type text/html} {language fr}} |
277 |
|
278 |
and if the request contains the Accept headers |
279 |
|
280 |
Accept: text/html:q=1.0, */*:q=0.8 |
281 |
Accept-Language: en;q=1.0, fr;q=0.5 |
282 |
|
283 |
the remote variant selection algorithm will compute an overall |
284 |
quality for the variant as follows: |
285 |
|
286 |
{"paper.html.fr" 0.7 {type text/html} {language fr}} |
287 |
| | | |
288 |
| | | |
289 |
V V V |
290 |
0.7 * 1.0 * 0.5 = 0.35 |
291 |
|
292 |
With the above Accept headers, the complete variant list |
293 |
|
294 |
{"paper.html.en" 0.9 {type text/html} {language en}}, |
295 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
296 |
{"paper.ps.en" 1.0 {type application/postscript} {language en}} |
297 |
|
298 |
would yield the following computations: |
299 |
|
300 |
qs * qt * qc * ql * qf = Q |
301 |
--- --- --- --- --- ---- |
302 |
paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.9 |
303 |
paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35 |
304 |
paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.8 |
305 |
|
306 |
|
307 |
3.4 Definite and speculative quality values |
308 |
|
309 |
A computed overall quality value can be either definite or |
310 |
speculative. An overall quality value is definite if it was |
311 |
computed without using any wildcard characters '*' in the Accept |
312 |
headers, and without the need to use the absence of a particular |
313 |
Accept header. An overall quality value is speculative otherwise. |
314 |
|
315 |
As an example, in the previous section, the quality values of |
316 |
paper.html.en and paper.html.fr are definite, and the quality value |
317 |
of paper.ps.en is speculative because the type |
318 |
application/postscript was matched to the range */*. |
319 |
|
320 |
Definiteness can be defined more formally as follows. An overall |
321 |
quality value Q is definite if the same quality value Q can be |
322 |
computed after the request message is changed in the following way: |
323 |
|
324 |
1. If an Accept, Accept-Charset, Accept-Language, or |
325 |
Accept-Features header is missing from the request, add |
326 |
this header with an empty field. |
327 |
|
328 |
2. Delete any media ranges containing a wildcard character '*' |
329 |
from the Accept header. Delete any wildcard '*' from the |
330 |
Accept-Charset, Accept-Language, and Accept-Features |
331 |
headers. |
332 |
|
333 |
As another example, the overall quality factor for the variant |
334 |
|
335 |
{"blah.html" 1 {language en-gb} {features blebber [x y]}} |
336 |
|
337 |
is 1 and definite with the Accept headers |
338 |
|
339 |
Accept-Language: en-gb, fr |
340 |
Accept-Features: blebber, x, !y, * |
341 |
|
342 |
and |
343 |
|
344 |
Accept-Language: en, fr |
345 |
Accept-Features: blebber, x, * |
346 |
|
347 |
The overall quality factor is still 1, but speculative, with the |
348 |
Accept headers |
349 |
|
350 |
Accept-language: en-gb, fr |
351 |
Accept-Features: blebber, !y, * |
352 |
|
353 |
and |
354 |
|
355 |
Accept-Language: fr, * |
356 |
Accept-Features: blebber, x, !y, * |
357 |
|
358 |
|
359 |
3.5 Determining the result |
360 |
|
361 |
The best variant, as determined by the remote variant selection |
362 |
algorithm, is the one variant with the highest overall quality |
363 |
value, or, if there are multiple variants which share the highest |
364 |
overall quality, the first variant in the list with this value. |
365 |
|
366 |
The end result of the remote variant selection algorithm is |
367 |
Choice_response if all of the following conditions are met |
368 |
|
369 |
a. the overall quality value of the best variant is greater |
370 |
than 0 |
371 |
|
372 |
b. the overall quality value of the best variant is a definite |
373 |
quality value |
374 |
|
375 |
c. the negotiable resource and the best variant resource are |
376 |
neighbors. This last condition exists for security reasons: |
377 |
it prevents some forms of spoofing, see section 14.2 of [5]. |
378 |
|
379 |
In all other cases, the end result is List_response. |
380 |
|
381 |
The requirement for definiteness above affects the interpretation |
382 |
of Accept headers in a dramatic way. For example, it causes the |
383 |
remote algorithm to interpret the header |
384 |
|
385 |
Accept: image/gif;q=0.9, */*;q=1.0 |
386 |
|
387 |
as |
388 |
|
389 |
`I accept image/gif with a quality of 0.9, and assign quality |
390 |
factors up to 1.0 to other media types. If this information is |
391 |
insufficient to make a choice on my behalf, do not make a choice |
392 |
but send the list of variants'. |
393 |
|
394 |
Without the requirement, the interpretation would have been |
395 |
|
396 |
`I accept image/gif with a quality of 0.9, and all other media |
397 |
types with a quality of 1.0'. |
398 |
|
399 |
|
400 |
4 Use of the algorithm |
401 |
|
402 |
This section discusses how user agents can use the remote algorithm |
403 |
in an optimal way. This section is not normative, it is included |
404 |
for informational purposes only. |
405 |
|
406 |
|
407 |
4.1 Using quality factors to rank preferences |
408 |
|
409 |
Using quality factors, a user agent can not only rank the elements |
410 |
within a particular Accept header, it can also express precedence |
411 |
relations between the different Accept headers. Consider for |
412 |
example the following variant list: |
413 |
|
414 |
{"paper.english" 1.0 {language en} {charset ISO-8859-1}}, |
415 |
{"paper.greek" 1.0 {language el} {charset ISO-8859-7}} |
416 |
|
417 |
and suppose that the user prefers "el" over "en", while the user |
418 |
agent can render "ISO-8859-1" with a higher quality than |
419 |
"ISO-8859-7". If the Accept headers are |
420 |
|
421 |
Accept-Language: gr, en;q=0.8 |
422 |
Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, * |
423 |
|
424 |
then the remote variant selection algorithm would choose the |
425 |
English variant, because this variant has the least overall quality |
426 |
degradation. But if the Accept headers are |
427 |
|
428 |
Accept-Language: gr, en;q=0.8 |
429 |
Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, * |
430 |
|
431 |
then the algorithm would choose the Greek variant. In general, the |
432 |
Accept header with the biggest spread between its quality factors |
433 |
gets the highest precedence. If a user agent allows the user to |
434 |
set the quality factors for some headers, while other factors are |
435 |
hard-coded, it should use a low spread on the hard-coded factors |
436 |
and a high spread on the user-supplied factors, so that the user |
437 |
settings take precedence over the built-in settings. |
438 |
|
439 |
|
440 |
4.2 Construction of short requests |
441 |
|
442 |
In a request on a transparently negotiated resource, a user agent |
443 |
need not send a very long Accept header, which lists all of its |
444 |
capabilities, to get optimal results. For example, instead of |
445 |
sending |
446 |
|
447 |
Accept: image/gif;q=0.9, image/jpeg;q=0.8, image/png;q=1.0, |
448 |
image/tiff;q=0.5, image/ief;q=0.5, image/x-xbitmap;q=0.8, |
449 |
application/plugin1;q=1.0, application/plugin2;q=0.9 |
450 |
|
451 |
the user agent can send |
452 |
|
453 |
Accept: image/gif;q=0.9, */*;q=1.0 |
454 |
|
455 |
It can send this short header without running the risk of getting a |
456 |
choice response with, say, an inferior image/tiff variant. For |
457 |
example, with the variant list |
458 |
|
459 |
{"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}}, |
460 |
|
461 |
the remote algorithm will compute a definite overall quality of 0.9 |
462 |
for x.gif and a speculative overall quality value of 1.0 for |
463 |
x.tiff. As the best variant has a speculative quality value, the |
464 |
algorithm will not choose x.tiff, but return a list response, after |
465 |
which the selection algorithm of the user agent will correctly |
466 |
choose x.gif. The end result is the same as if the long Accept |
467 |
header above had been sent. |
468 |
|
469 |
Thus, user agents can vary the length of the Accept headers to get |
470 |
an optimal tradeoff between the speed with which the first request |
471 |
is transmitted, and the chance that the remote algorithm has enough |
472 |
information to eliminate a second request. |
473 |
|
474 |
4.2.1 Collapsing Accept header elements |
475 |
|
476 |
This section discusses how a long Accept header which lists all |
477 |
capabilities and preferences can be safely made shorter. The |
478 |
remote variant selection algorithm is designed in such a way that |
479 |
it is always safe to shorten an Accept or Accept-Charset header by |
480 |
two taking two header elements `A;q=f' and `B;q=g' and replacing |
481 |
them by a single element `P;q=m' where P is a wildcard pattern that |
482 |
matches both A and B, and m is the maximum of f and g. Some |
483 |
examples are |
484 |
|
485 |
text/html;q=1.0, text/plain;q=0.8 --> text/*;q=1.0 |
486 |
image/*;q=0.8, application/*;q=0.7 --> */*;q=0.8 |
487 |
|
488 |
iso-8859-5;q=1.0, unicode-1-1;q=0.8 --> *;q=1.0 |
489 |
|
490 |
Note that every `;q=1.0' above is optional, and can be omitted: |
491 |
|
492 |
iso-8859-7;q=0.6, * --> * |
493 |
|
494 |
For Accept-Language, it is safe to collapse all language ranges |
495 |
with the same primary tag into a wildcard: |
496 |
|
497 |
en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da --> *;q=0.9, da |
498 |
|
499 |
It is also safe to collapse a language range into a wildcard, or to |
500 |
replace it by a wildcard, if its primary tag appears only once: |
501 |
|
502 |
*;q=0.9, da --> * |
503 |
|
504 |
Finally, in the Accept-Features header, every feature expression |
505 |
can be collapsed into a wildcard, or replaced by a wildcard: |
506 |
|
507 |
colordepth<=5, * --> * |
508 |
|
509 |
4.2.2 Omitting Accept headers |
510 |
|
511 |
According to the HTTP/1.1 specification [1], the complete absence |
512 |
of an Accept header from the request is equivalent to the presence |
513 |
of `Accept: */*'. Thus, if the Accept header is collapsed to |
514 |
`Accept: */*', a user agent may omit it entirely. An |
515 |
Accept-Charset, Accept-Language, or Accept-Features header which |
516 |
only contains `*' may also be omitted. |
517 |
|
518 |
4.2.3 Dynamically lengthening requests |
519 |
|
520 |
In general, a user agent capable of transparent content negotiation |
521 |
can send short requests by default. Some short Accept headers |
522 |
could be included for the benefit of existing servers which use |
523 |
HTTP/1.0 style negotiation (see section 4.2 of [5]). An example is |
524 |
|
525 |
GET /paper HTTP/1.1 |
526 |
Host: x.org |
527 |
User-Agent: WuxtaWeb/2.4 |
528 |
Negotiate: 1.0 |
529 |
Accept-Language: en, *;q=0.9 |
530 |
|
531 |
If the Accept headers included in such a default request are not |
532 |
suitable as input to the remote variant selection algorithm, the |
533 |
user agent can disable the algorithm by sending `Negotiate: trans' |
534 |
instead of `Negotiate: 1.0'. |
535 |
|
536 |
If the user agent discovers, though the receipt of a list or choice |
537 |
response, that a particular origin server contains transparently |
538 |
negotiated resources, it could dynamically lengthen future requests |
539 |
to this server, for example to |
540 |
|
541 |
GET /paper/chapter1 HTTP/1.1 |
542 |
Host: x.org |
543 |
User-Agent: WuxtaWeb/2.4 |
544 |
Negotiate: 1.0 |
545 |
Accept: text/html, application/postscript;q=0.8, */* |
546 |
Accept-Language: en, fr;q=0.5, *;q=0.9 |
547 |
Accept-Features: tables, * |
548 |
|
549 |
This will increase the chance that the remote variant selection |
550 |
algorithm will have sufficient information to choose on behalf of |
551 |
the user agent, thereby optimizing the negotiation process. A good |
552 |
strategy for dynamic extension would be to extend the headers with |
553 |
those media types, languages, charsets, and feature tags mentioned |
554 |
in the variant lists of past responses from the server. |
555 |
|
556 |
|
557 |
4.3 Differences between the local and the remote algorithm |
558 |
|
559 |
A user agent can only optimize content negotiation though the use |
560 |
of a remote algorithm if its local algorithm will generally make |
561 |
the same choice. If a user agent receives a choice response |
562 |
containing a variant X selected by the remote algorithm, while the |
563 |
local algorithm would have selected Y, the user agent has two |
564 |
options: |
565 |
|
566 |
1. Retrieve Y in a subsequent request. This is sub-optimal |
567 |
because it takes time. |
568 |
|
569 |
2. Display X anyway. This is sub-optimal because it makes the |
570 |
end result of the negotiation process dependent on factors |
571 |
that can randomly change. For the next request on the same |
572 |
resource, and intermediate proxy cache could return a list |
573 |
response, which would cause the local algorithm to choose and |
574 |
retrieve Y instead of X. Compared to a stable |
575 |
representation, a representation which randomly switches |
576 |
between X and Y (say, the version with and without frames) has |
577 |
a very low subjective quality for most users. |
578 |
|
579 |
As both alternatives above are unattractive, a user agent should |
580 |
try to avoid the above situation altogether. The sections below |
581 |
discuss how this can be done. |
582 |
|
583 |
4.3.1 Avoiding major differences |
584 |
|
585 |
If the user agent enables the remote algorithm in this |
586 |
specification, it should generally use a local algorithm which |
587 |
closely resembles the remote algorithm. The algorithm should for |
588 |
example also use multiplication to combine quality factors. If the |
589 |
user agent combines quality factors by addition, it would be more |
590 |
advantageous to define a new remote variant selection algorithm, |
591 |
with a new major version number, for use by this agent. |
592 |
|
593 |
4.3.2 Working around minor differences |
594 |
|
595 |
Even if a local algorithm uses multiplication to combine quality |
596 |
factors, it could use an extended quality formulae like |
597 |
|
598 |
Q = ( qs * qt * qc * ql * qf ) * q_adjust |
599 |
|
600 |
in order to account for special interdependencies between |
601 |
dimensions, which are due to limitations of the user agent. For |
602 |
example, if the user agent, for some reason, cannot handle the |
603 |
iso-8859-7 charset when rendering text/plain documents, the |
604 |
q_adjust factor would be 0 when the text/plain - iso-8859-7 |
605 |
combination is present in the variant description, and 1 otherwise. |
606 |
|
607 |
By selectively withholding information from the remote variant |
608 |
selection algorithm, the user agent can ensure that the remote |
609 |
algorithm will never make a choice if the local q_adjust is less |
610 |
than 1. For example, to prevent the remote algorithm from ever |
611 |
returning a text/plain - iso-8859-7 choice response, the user agent |
612 |
should take care to never produce a request which exactly specifies |
613 |
the quality factors of both text/plain and iso-8859-7. The |
614 |
omission of either factor from a request will cause the overall |
615 |
quality value of any text/plain - iso-8859-7 variant to be |
616 |
speculative, and variants with speculative quality values can never |
617 |
be returned in a choice response. |
618 |
|
619 |
In general, if the local q_adjust does not equal 1 for a particular |
620 |
combination X - Y - Z, then a remote choice can be prevented by |
621 |
always omitting at least one of the elements of the combination |
622 |
from the Accept headers, and adding a suitable wildcard pattern to |
623 |
match the omitted element, if such a pattern is not already |
624 |
present. |
625 |
|
626 |
|
627 |
5 Security and privacy considerations |
628 |
|
629 |
This specification introduces no security and privacy |
630 |
considerations not already covered in [5]. See [5] for a |
631 |
discussion of privacy risks connected to the sending of Accept |
632 |
headers. |
633 |
|
634 |
|
635 |
6 Acknowledgments |
636 |
|
637 |
Work on HTTP content negotiation has been done since at least 1993. |
638 |
The authors are unable to trace the origin of many of the ideas |
639 |
incorporated in this document. This specification builds on an |
640 |
earlier incomplete specification of content negotiation recorded in |
641 |
[2]. Many members of the HTTP working group have contributed to |
642 |
the negotiation model in this specification. The authors wish to |
643 |
thank the individuals who have commented on earlier versions of |
644 |
this document, including Brian Behlendorf, Daniel DuBois, Ted |
645 |
Hardie, Larry Masinter, and Roy T. Fielding. |
646 |
|
647 |
|
648 |
7 References |
649 |
|
650 |
[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and |
651 |
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC |
652 |
2068, HTTP Working Group, January, 1997. |
653 |
|
654 |
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. |
655 |
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft |
656 |
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, |
657 |
1996. |
658 |
|
659 |
[3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext |
660 |
Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, |
661 |
May 1996. |
662 |
|
663 |
[4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. |
664 |
Internet-Draft draft-ietf-http-feature-reg-00.txt, HTTP Working |
665 |
Group, October 30, 1996. |
666 |
|
667 |
[5] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. |
668 |
Internet-Draft draft-ietf-http-negotiation-00.txt, HTTP Working |
669 |
Group. |
670 |
|
671 |
|
672 |
8 Authors' addresses |
673 |
|
674 |
Koen Holtman |
675 |
Technische Universiteit Eindhoven |
676 |
Postbus 513 |
677 |
Kamer HG 6.57 |
678 |
5600 MB Eindhoven (The Netherlands) |
679 |
Email: koen@win.tue.nl |
680 |
|
681 |
Andrew H. Mutz |
682 |
Hewlett-Packard Company |
683 |
1501 Page Mill Road 3U-3 |
684 |
Palo Alto CA 94304, USA |
685 |
Fax +1 415 857 4691 |
686 |
Email: mutz@hpl.hp.com |
687 |
|
688 |
|
689 |
Expires: August 5, 1997 |
690 |
|