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