idnits 2.17.1 draft-ietf-http-negotiation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2834 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 26, 1997) is 9771 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2068 (ref. '1') (Obsoleted by RFC 2616) == Outdated reference: A later version (-06) exists of draft-ietf-http-v11-spec-01 ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '3') -- No information found for draft-ietf-http-feature-reg - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-02) exists of draft-ietf-http-rvsa-v10-01 ** Downref: Normative reference to an Historic draft: draft-ietf-http-rvsa-v10 (ref. '5') ** Obsolete normative reference: RFC 2044 (ref. '7') (Obsoleted by RFC 2279) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group Koen Holtman, TUE 2 Internet-Draft Andrew Mutz, Hewlett-Packard 3 Expires: January 26, 1998 July 26, 1997 5 Transparent Content Negotiation in HTTP 7 draft-ietf-http-negotiation-03.txt 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by 19 other documents at any time. It is inappropriate to use 20 Internet-Drafts as reference material or to cite them other 21 than as "work in progress". 23 To learn the current status of any Internet-Draft, please 24 check the "1id-abstracts.txt" listing contained in the 25 Internet-Drafts Shadow Directories on ftp.is.co.za 26 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 27 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 28 West Coast). 30 Distribution of this document is unlimited. Please send 31 comments to the HTTP working group at 32 . Discussions of the working 33 group are archived at 34 . General 35 discussions about HTTP and the applications which use HTTP 36 should take place on the mailing list. 38 HTML and change bar versions of this document, are available 39 at . 41 ABSTRACT 43 HTTP allows web site authors to put multiple versions of the 44 same information under a single URL. Transparent content 45 negotiation is an extensible negotiation mechanism, layered on 46 top of HTTP, for automatically selecting the best version when 47 the URL is accessed. This enables the smooth deployment of 48 new web data formats and markup tags. 50 OVERVIEW OF THE TRANSPARENT CONTENT NEGOTIATION DOCUMENT SET 52 An up-to-date overview of documents related to transparent content 53 negotiation is maintained on the web page 54 . 56 The transparent content negotiation document set currently consists 57 of two series of internet drafts. 59 1. draft-ietf-http-negotiation-XX.txt (this document) 61 `Transparent Content Negotiation in HTTP' 63 Defines the core mechanism. Experimental track. 65 2. draft-ietf-http-rvsa-v10-XX.txt 67 `HTTP Remote Variant Selection Algorithm -- RVSA/1.0' 69 Defines the remote variant selection algorithm version 1.0. 70 Experimental track. 72 Two related series of drafts are 74 3. draft-ietf-http-feature-reg-XX.txt 76 `Feature Tag Registration Procedures' 78 Defines feature tag registration. Best Current Practice 79 track. 81 4. draft-ietf-http-feature-scenarios-XX.txt 83 `Feature Tag Scenarios' 85 Discusses feature tag scenarios. Informational track. 87 An additional document about `the core feature set', which may 88 later become an informational RFC, may also appear. Currently, 89 there are two internet drafts which discuss parts of what could be 90 a core feature set: draft-mutz-http-attributes-XX.txt and 91 draft-goland-http-headers-XX.txt 93 Older versions of the text in documents 1 and 2 may be found in the 94 draft-holtman-http-negotiation-XX.txt series of internet drafts. 96 TABLE OF CONTENTS 98 1 Introduction 99 1.1 Background 100 1.2 Revision history 102 2 Terminology 103 2.1 Terms from HTTP/1.1 104 2.2 New terms 106 3 Notation 108 4 Overview 109 4.1 Content negotiation 110 4.2 HTTP/1.0 style negotiation scheme 111 4.3 Transparent content negotiation scheme 112 4.4 Optimizing the negotiation process 113 4.5 Downwards compatibility with non-negotiating user agents 114 4.6 Retrieving a variant by hand 115 4.7 Dimensions of negotiation 116 4.8 Feature negotiation 117 4.9 Length of variant lists 118 4.10 Relation with other negotiation schemes 120 5 Variant descriptions 121 5.1 Syntax 122 5.2 URI 123 5.3 Source-quality 124 5.4 Type, charset, language, and length 125 5.5 Features 126 5.6 Description 127 5.7 Extension-attribute 129 6 Feature negotiation 130 6.1 Feature tags 131 6.1.1 Feature tag values 132 6.2 Feature sets 133 6.3 Feature predicates 134 6.4 Features attribute 136 7 Remote variant selection algorithms 137 7.1 Version numbers 139 8 Content negotiation status codes and headers 140 8.1 506 Variant Also Negotiates 141 8.2 Accept-Features 142 8.3 Alternates 143 8.4 Negotiate 144 8.5 TCN 145 8.6 Variant-Vary 147 9 Cache validators 148 9.1 Variant list validators 149 9.2 Structured entity tags 150 9.3 Assigning entity tags to variants 152 10 Content negotiation responses 153 10.1 List response 154 10.2 Choice response 155 10.3 Adhoc response 156 10.4 Reusing the Alternates header 157 10.5 Extracting a normal response from a choice response 158 10.6 Elaborate Vary headers 159 10.6.1 Construction of an elaborate Vary header 160 10.6.2 Caching of an elaborate Vary header 161 10.7 Adding an Expires header to ensure HTTP/1.0 compatibility 162 10.8 Negotiation on content encoding 164 11 User agent support for transparent negotiation 165 11.1 Handling of responses 166 11.2 Presentation of a transparently negotiated resource 168 12 Origin server support for transparent negotiation 169 12.1 Requirements 170 12.2 Negotiation on transactions other than GET and HEAD 172 13 Proxy support for transparent negotiation 174 14 Security and privacy considerations 175 14.1 Accept- headers revealing information of a private nature 176 14.2 Spoofing of responses from variant resources 177 14.3 Security holes revealed by negotiation 179 15 Acknowledgments 181 16 References 183 17 Authors' addresses 185 18 Appendix: Example of a local variant selection algorithm 186 18.1 Computing overall quality values 187 18.2 Determining the result 188 18.3 Ranking dimensions 190 19 Appendix: feature negotiation examples 191 19.1 Use of feature tags 192 19.2 Use of numeric feature tags 193 19.3 Feature tag design 195 20 Appendix: origin server implementation considerations 196 20.1 Implementation with a CGI script 197 20.2 Direct support by HTTP servers 198 20.3 Web publishing tools 200 21 Appendix: Example of choice response construction 202 1 Introduction 204 HTTP allows web site authors to put multiple versions of the same 205 information under a single URI. Each of these versions is called a 206 `variant'. Transparent content negotiation is an extensible 207 negotiation mechanism for automatically and efficiently retrieving 208 the best variant when a GET or HEAD request is made. This enables 209 the smooth deployment of new web data formats and markup tags. 211 This specification defines transparent content negotiation as an 212 extension on top of the HTTP/1.1 protocol [1]. However, use of 213 this extension does not require use of HTTP/1.1: transparent 214 content negotiation can also be done if some or all of the parties 215 are HTTP/1.0 [3] systems. 217 Transparent content negotiation is called `transparent' because it 218 makes all variants which exist inside the origin server visible to 219 outside parties. 221 Note: Though this specification is limited to negotiation on 222 HTTP transactions, elements of this specification could also be 223 used in other contexts. For example, feature predicates could 224 be used in conditional HTML, and variant descriptions could be 225 used in multipart mail messages. Such use in other contexts is 226 encouraged. 228 1.1 Background 230 The addition of content negotiation to the web infrastructure has 231 been considered important since the early days of the web. Among 232 the expected benefits of a sufficiently powerful system for content 233 negotiation are 235 * smooth deployment of new data formats and markup tags will 236 allow graceful evolution of the web 238 * eliminating the need to choose between a `state of the art 239 multimedia homepage' and one which can be viewed by all web 240 users 242 * enabling good service to a wider range of browsing 243 platforms (from low-end PDA's to high-end VR setups) 245 * eliminating error-prone and cache-unfriendly 246 User-Agent based negotiation 248 * enabling construction of sites without `click here for the X 249 version' links 251 * internationalization, and the ability to offer multi-lingual 252 content without a bias towards one language. 254 1.2 Revision history 256 There are no major changes in this version. The Content-Features 257 header has been deleted, and some new text on security 258 considerations was added. Some existing text has been improved. 260 2 Terminology 262 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 263 this document are to be interpreted as described in RFC 2119 [6]. 265 This specification used the term `header' as an abbreviation for 266 for `header field in a request or response message'. 268 2.1 Terms from HTTP/1.1 270 This specification mostly uses the terminology of the HTTP/1.1 271 specification [1]. The definitions below were reproduced from [1]. 273 request 274 An HTTP request message. 276 response 277 An HTTP response message. 279 resource 280 A network data object or service that can be identified by a URI. 281 Resources may be available in multiple representations 282 (e.g. multiple languages, data formats, size, resolutions) or 283 vary in other ways. 285 content negotiation 286 The mechanism for selecting the appropriate representation when 287 servicing a request. 289 client 290 A program that establishes connections for the purpose of sending 291 requests. 293 user agent 294 The client which initiates a request. These are often browsers, 295 editors, spiders (web-traversing robots), or other end user 296 tools. 298 server 299 An application program that accepts connections in order to 300 service requests by sending back responses. Any given program may 301 be capable of being both a client and a server; our use of these 302 terms refers only to the role being performed by the program for 303 a particular connection, rather than to the program's 304 capabilities in general. Likewise, any server may act as an 305 origin server, proxy, gateway, or tunnel, switching behavior 306 based on the nature of each request. 308 origin server 309 The server on which a given resource resides or is to be created. 311 proxy 312 An intermediary program which acts as both a server and a client 313 for the purpose of making requests on behalf of other 314 clients. Requests are serviced internally or by passing them on, 315 with possible translation, to other servers. A proxy must 316 implement both the client and server requirements of this 317 specification. 319 age 320 The age of a response is the time since it was sent by, or 321 successfully validated with, the origin server. 323 fresh 324 A response is fresh if its age has not yet exceeded its freshness 325 lifetime. 327 2.2 New terms 329 transparently negotiable resource 330 A resource, identified by a single URI, which has multiple 331 representations (variants) associated with it. When servicing a 332 request on its URI, it allows selection of the best 333 representation using the transparent content negotiation 334 mechanism. A transparently negotiable resource always has a 335 variant list bound to it, which can be represented as an 336 Alternates header (defined in section 8.3). 338 variant list 339 A list containing variant descriptions, which can be bound to a 340 transparently negotiable resource. 342 variant description 343 A machine-readable description of a variant resource, usually 344 found in a variant list. A variant description contains the 345 variant resource URI and various attributes which describe 346 properties of the variant. Variant descriptions are defined in 347 section 5. 349 variant resource 350 A resource from which a variant of a negotiable resource can be 351 retrieved with a normal HTTP/1.x GET request, i.e. a GET request 352 which does not use transparent content negotiation. 354 neighboring variant 355 A variant resource is called a neighboring variant resource of 356 some transparently negotiable HTTP resource if the variant 357 resource has a HTTP URL, and if the absolute URL of the variant 358 resource up to its last slash equals the absolute URL of the 359 negotiable resource up to its last slash, where equality is 360 determined with the URI comparison rules in section 3.2.3 of [1]. 361 The property of being a neighboring variant is important because 362 of security considerations (section 14.2). Not all variants of a 363 negotiable resource need to be neighboring variants. However, 364 access to neighboring variants can be more highly optimized by 365 the use of remote variant selection algorithms (section 7) and 366 choice responses (section 10.2). 368 remote variant selection algorithm 369 A standardized algorithm by which a server can sometimes choose a 370 best variant on behalf of a negotiating user agent. The 371 algorithm typically computes whether the Accept- headers in the 372 request contain sufficient information to allow a choice, and if 373 so, which variant is the best variant. The use of a remote 374 algorithm can speed up the negotiation process. 376 list response 377 A list response returns the variant list of the negotiable 378 resource, but no variant data. It can be generated when the 379 server does not want to, or is not allowed to, return a 380 particular best variant for the request. List responses are 381 defined in section 10.1. 383 choice response 384 A choice response returns a representation of the best variant 385 for the request, and may also return the variant list of the 386 negotiable resource. It can be generated when the server has 387 sufficient information to be able to choose the best variant on 388 behalf the user agent, but may only be generated if this best 389 variant is a neighboring variant. Choice responses are defined 390 in section 10.2. 392 adhoc response 393 An adhoc response can be sent by an origin server as an extreme 394 measure, to achieve compatibility with a non-negotiating or buggy 395 client if this compatibility cannot be achieved by sending a list 396 or choice response. There are very little requirements on the 397 contents of an adhoc response. Adhoc responses are defined in 398 section 10.3. 400 Accept- headers 401 The request headers: Accept, Accept-Charset, Accept-Language, and 402 Accept-Features. 404 supports transparent content negotiation 405 From the viewpoint of an origin server or proxy, a user agent 406 supports transparent content negotiation if and only if it sends 407 a Negotiate header (section 8.4) which indicates such support. 409 server-side override 410 If a request on a transparently negotiated resource is made by a 411 client which supports transparent content negotiation, an origin 412 server is said to perform a server-side override if the server 413 ignores the directives in the Negotiate request header, and 414 instead uses a custom algorithm to choose an appropriate 415 response. A server-side override can sometimes be used to work 416 around known client bugs. It could also be used by protocol 417 extensions on top of transparent content negotiation. 419 3 Notation 421 The version of BNF used in this document is taken from [1], and 422 many of the nonterminals used are defined in [1]. 424 One new BNF construct is added: 426 1%rule 428 stands for one or more instances of "rule", separated by 429 whitespace: 431 1%rule = rule *( 1*LWS rule ) 433 This specification also introduces 435 number = 1*DIGIT 437 short-float = 1*3DIGIT [ "." 0*3DIGIT ] 439 This specification uses the same conventions as in [1] (see section 440 1.2 of [1]) for defining the significance of each particular 441 requirement. 443 4 Overview 445 This section gives an overview of transparent content negotiation. 446 It starts with a more general discussion of negotiation as provided 447 by HTTP. 449 4.1 Content negotiation 451 HTTP/1.1 allows web site authors to put multiple versions of the 452 same information under a single resource URI. Each of these 453 versions is called a `variant'. For example, a resource 454 http://x.org/paper could bind to three different variants of a 455 paper: 457 1. HTML, English 458 2. HTML, French 459 3. Postscript, English 461 Content negotiation is the process by which the best variant is 462 selected if the resource is accessed. The selection is done by 463 matching the properties of the available variants to the 464 capabilities of the user agent and the preferences of the user. 466 It has always been possible under HTTP to have multiple 467 representations available for one resource, and to return the most 468 appropriate representation for each subsequent request. However, 469 HTTP/1.1 is the first version of HTTP which has provisions for 470 doing this in a cache-friendly way. These provisions include the 471 Vary response header, entity tags, and the If-None-Match request 472 header. 474 4.2 HTTP/1.0 style negotiation scheme 476 The HTTP/1.0 protocol elements allow for a negotiation scheme as 477 follows: 479 Server _____ proxy _____ proxy _____ user 480 x.org cache cache agent 482 < ---------------------------------- 483 | GET http://x.org/paper 484 | Accept- headers 485 choose 486 | 487 ---------------------------------- > 488 Best variant 490 When the resource is accessed, the user agent sends (along with its 491 request) various Accept- headers which express the user agent 492 capabilities and the user preferences. Then the origin server uses 493 these Accept- headers to choose the best variant, which is returned 494 in the response. 496 The biggest problem with this scheme is that it does not scale 497 well. For all but the most minimal user agents, Accept- headers 498 expressing all capabilities and preferences would be very large, 499 and sending them in every request would be hugely inefficient, in 500 particular because only a small fraction of the resources on the 501 web have multiple variants. 503 4.3 Transparent content negotiation scheme 505 The transparent content negotiation scheme eliminates the need to 506 send huge Accept- headers, and nevertheless allows for a selection 507 process that always yields either the best variant, or an error 508 message indicating that user agent is not capable of displaying any 509 of the available variants. 511 Under the transparent content negotiation scheme, the server sends 512 a list with the available variants and their properties to the user 513 agent. An example of a list with three variants is 515 {"paper.1" 0.9 {type text/html} {language en}}, 516 {"paper.2" 0.7 {type text/html} {language fr}}, 517 {"paper.3" 1.0 {type application/postscript} {language en}} 519 The syntax and semantics of the variant descriptions in this list 520 are covered in section 5. When the list is received, the user 521 agent can choose the best variant and retrieve it. Graphically, 522 the communication can be represented as follows: 524 Server _____ proxy _____ proxy _____ user 525 x.org cache cache agent 527 < ---------------------------------- 528 | GET http://x.org/paper 529 | 530 ----------------------------------- > [list response] 531 return of list | 532 choose 533 | 534 < ---------------------------------- 535 | GET http://x.org/paper.1 536 | 537 ---------------------------------- > [normal response] 538 return of paper.1 540 The first response returning the list of variants is called a `list 541 response'. The second response is a normal HTTP response: it does 542 not contain special content negotiation related information. Only 543 the user agent needs to know that the second request actually 544 retrieves a variant. For the other parties in the communication, 545 the second transaction is indistinguishable from a normal HTTP 546 transaction. 548 With this scheme, information about capabilities and preferences is 549 only used by the user agent itself. Therefore, sending such 550 information in large Accept- headers is unnecessary. Accept- 551 headers do have a limited use in transparent content negotiation 552 however; the sending of small Accept- headers can often speed up the 553 negotiation process. This is covered in section 4.4. 555 List responses are covered in section 10.1. As an example, the 556 list response in the above picture could be: 558 HTTP/1.1 300 Multiple Choices 559 Date: Tue, 11 Jun 1996 20:02:21 GMT 560 TCN: list 561 Alternates: {"paper.1" 0.9 {type text/html} {language en}}, 562 {"paper.2" 0.7 {type text/html} {language fr}}, 563 {"paper.3" 1.0 {type application/postscript} 564 {language en}} 565 Vary: negotiate, accept, accept-language 566 ETag: "blah;1234" 567 Cache-control: max-age=86400 568 Content-Type: text/html 569 Content-Length: 227 571

Multiple Choices:

572 578 The Alternates header in the response contains the variant list. 579 The Vary header is included to ensure correct caching by plain 580 HTTP/1.1 caches (see section 10.6). The ETag header allows the 581 response to be revalidated by caches, the Cache-Control header 582 controls this revalidation. The HTML entity included in the 583 response allows the user to select the best variant by hand if 584 desired. 586 4.4 Optimizing the negotiation process 588 The basic transparent negotiation scheme involves two HTTP 589 transactions: one to retrieve the list, and a second one to retrieve 590 the chosen variant. There are however several ways to `cut corners' 591 in the data flow path of the basic scheme. 593 First, caching proxies can cache both variant lists and variants. 594 Such caching can reduce the communication overhead, as shown in the 595 following example: 597 Server _____ proxy _____ proxy __________ user 598 x.org cache cache agent 600 < -------------- 601 | GET ../paper 602 | 603 has the list 604 in cache 605 | 606 ------------- > [list response] 607 list | 608 | 609 choose 610 | 611 < -------------------------- 612 | GET ../paper.1 613 | 614 has the variant 615 in cache 616 | 617 -------------------------- > [normal response] 618 return of paper.1 620 Second, the user agent can send small Accept- headers, which may 621 contain enough information to allow the server to choose the best 622 variant and return it directly. 624 Server _____ proxy _____ proxy _____ user 625 x.org cache cache agent 627 < ---------------------------------- 628 | GET http://x.org/paper 629 | small Accept- headers 630 | 631 able to choose on 632 behalf of user agent 633 | 634 ---------------------------------- > [choice response] 635 return of paper.1 and list 637 This choosing based on small Accept- headers is done with a `remote 638 variant selection algorithm'. Such an algorithm takes the variant 639 list and the Accept- headers as input. It then computes whether the 640 Accept- headers contain sufficient information to choose on behalf 641 of the user agent, and if so, which variant is the best variant. 642 If the best variant is a neighboring variant, it may be returned, 643 together with the variant list, in a choice response. 645 A server may only choose on behalf of a user agent supporting 646 transparent content negotiation if the user agent explicitly allows 647 the use of a particular remote variant selection algorithm in the 648 Negotiate request header. User agents with sophisticated internal 649 variant selection algorithms may want to disallow a remote choice, 650 or may want to allow it only when retrieving inline images. If the 651 local algorithm of the user agent is superior in only some 652 difficult areas of negotiation, it is possible to enable the remote 653 algorithm for the easy areas only. More information about the use 654 of a remote variant selection algorithm can be found in [5]. 656 Choice responses are covered in section 10.2. For example, the 657 choice response in the above picture could be: 659 HTTP/1.1 200 OK 660 Date: Tue, 11 Jun 1996 20:05:31 GMT 661 TCN: choice 662 Content-Type: text/html 663 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 664 Content-Length: 5327 665 Cache-control: max-age=604800 666 Content-Location: paper.html.en 667 Alternates: {"paper.1" 0.9 {type text/html} {language en}}, 668 {"paper.2" 0.7 {type text/html} {language fr}}, 669 {"paper.3" 1.0 {type application/postscript} 670 {language en}} 671 Etag: "gonkyyyy;1234" 672 Vary: negotiate, accept, accept-language 673 Expires: Thu, 01 Jan 1980 00:00:00 GMT 675 A paper about .... 677 Finally, the above two kinds of optimization can be combined; a 678 caching proxy which has the list will sometimes be able to choose on 679 behalf of the user agent. This could lead to the following 680 communication pattern: 682 Server _____ proxy _____ proxy __________ user 683 x.org cache cache agent 685 < --------------- 686 | GET ../paper 687 | small Accept 688 | 689 able to choose 690 on behalf 691 | 692 < ---------- 693 | GET ../paper.1 694 | 695 ---------- > [normal response] 696 html.en | 697 ---------------- > [choice response] 698 paper.1 and list 700 Note that this cutting of corners not only saves bandwidth, it also 701 eliminates delays due to packet round trip times, and reduces the 702 load on the origin server. 704 4.5 Downwards compatibility with non-negotiating user agents 706 To handle requests from user agents which do not support 707 transparent content negotiation, this specification allows the 708 origin server to revert to a HTTP/1.0 style negotiation scheme. 709 The specification of heuristics for such schemes is beyond the 710 scope of this document. 712 4.6 Retrieving a variant by hand 714 It is always possible for a user agent to retrieve the variant list 715 which is bound to a negotiable resource. The user agent can use 716 this list to make available a menu of all variants and their 717 characteristics to the user. Such a menu allows the user to 718 randomly browse other variants, and makes it possible to manually 719 correct any sub-optimal choice made by the automatic negotiation 720 process. 722 4.7 Dimensions of negotiation 724 Transparent content negotiation defines four dimensions of 725 negotiation: 727 1. Media type (MIME type) 728 2. Charset 729 3. Language 730 4. Features 732 The first three dimensions have traditionally been present in HTTP. 733 The fourth dimension is added by this specification. Additional 734 dimensions, beyond the four mentioned above, could be added by 735 future specifications. 737 Negotiation on the content encoding of a response (gzipped, 738 compressed, etc.) is left outside of the realm of transparent 739 negotiation. See section 10.8 for more information. 741 4.8 Feature negotiation 743 Feature negotiation intends to provide for all areas of negotiation 744 not covered by the type, charset, and language dimensions. 745 Examples are negotiation on 747 * HTML extensions 748 * Extensions of other media types 749 * Color capabilities of the user agent 750 * Screen size 751 * Output medium (screen, paper, ...) 752 * Preference for speed vs. preference for graphical detail 754 The feature negotiation framework (section 6) is the principal 755 means by which transparent negotiation offers extensibility; a new 756 dimension of negotiation (really a sub-dimension of the feature 757 dimension) can be added without the need for a new standards effort 758 by the simple registration of a `feature tag'. Feature tag 759 registration is discussed in [4]. 761 4.9 Length of variant lists 763 As a general rule, variant lists should be short: it is expected 764 that a typical transparently negotiable resource will have 2 to 10 765 variants, depending on its purpose. Variant lists should be short 766 for a number of reasons: 768 1. The user must be able to pick a variant by hand to correct a 769 bad automatic choice, and this is more difficult with a long 770 variant list. 772 2. A large number of variants will decrease the efficiency of 773 internet proxy caches. 775 3. Long variant lists will make some transparently negotiated 776 responses longer. 778 In general, it is not desirable to create a transparently 779 negotiable resource with hundreds of variants in order to fine-tune 780 the graphical presentation of a resource. Any graphical 781 fine-tuning should be done, as much as possible, by using 782 constructs which act at the user agent side, for example 784 <center><img src=titlebanner.gif width=100% 785 alt="MegaBozo Corp"></center> 787 In order to promote user agent side fine tuning, which is more 788 scalable than fine tuning over the network, user agents which 789 implement a scripting language for content rendering are encouraged 790 to make the availability of this language visible for transparent 791 content negotiation, and to allow rendering scripts to access the 792 capabilities and preferences data used for content negotiation, as 793 far as privacy considerations permit this. 795 4.10 Relation with other negotiation schemes 797 The HTTP/1.x protocol suite allows for many different negotiation 798 mechanisms. Transparent content negotiation specializes in 799 scalable, interoperable negotiation of content representations at 800 the HTTP level. It is intended that transparent negotiation will 801 co-exist with other negotiation schemes, both open and proprietary, 802 which cover different application domains or work at different 803 points in the author-to-user chain. Ultimately, it will be up to 804 the resource author to decide which negotiation mechanism, or 805 combination of negotiation mechanisms, is most appropriate for the 806 task at hand. 808 This specification explicitly encourages future negotiation 809 mechanisms to re-use parts of this specification when appropriate. 810 With respect to re-use, two parts of this specification are 811 particularly important: 813 1. the syntax and semantics of variant descriptions (section 5-6) 815 2. the transport and caching protocol for negotiated data (section 816 8-10) 818 5 Variant descriptions 820 5.1 Syntax 822 A variant can be described in a machine-readable way with a variant 823 description. 825 variant-description = 826 "{" <"> URI <"> source-quality *variant-attribute"}" 828 source-quality = qvalue 830 variant-attribute = "{" "type" media-type "}" 831 | "{" "charset" charset "}" 832 | "{" "language" 1#language-tag "}" 833 | "{" "length" 1*DIGIT "}" 834 | "{" "features" feature-list "}" 835 | "{" "description" quoted-string "}" 836 | extension-attribute 838 extension-attribute = "{" extension-name extension-value "}" 839 extension-name = token 840 extension-value = *( token | quoted-string | LWS 841 | extension-specials ) 843 extension-specials = 844 <any element of tspecials except <"> and "}"> 846 The feature-list syntax is defined in section 6.4. 848 Examples are 850 {"paper.2" 0.7 {type text/html} {language fr}} 852 {"paper.5" 0.9 {type text/html} {features tables}} 854 {"paper.1" 0.001} 856 The various attributes which can be present in a variant 857 description are covered in the subsections below. Each attribute 858 may appear only once in a variant description. 860 5.2 URI 862 The URI attribute gives the URI of the resource from which the 863 variant can be retrieved with a GET request. It can be absolute or 864 relative to the Request-URI. The variant resource may vary (on the 865 Cookie request header, for example), but MUST NOT engage in 866 transparent content negotiation itself. 868 5.3 Source-quality 870 The source-quality attribute gives the quality of the variant, as a 871 representation of the negotiable resource, when this variant is 872 rendered with a perfect rendering engine on the best possible 873 output medium. 875 If the source-quality is less than 1, it often expresses a quality 876 degradation caused by a lossy conversion to a particular data 877 format. For example, a picture originally in JPEG form would have 878 a lower source quality when translated to the XBM format, and a 879 much lower source quality when translated to an ASCII-art variant. 880 Note however, that degradation is a function of the source; an 881 original piece of ASCII-art may degrade in quality if it is 882 captured in JPEG form. 884 The source-quality could also represent a level of quality caused 885 by skill of language translation, or ability of the used media type 886 to capture the intended artistic expression. 888 It is important that content providers do not assign very low 889 source quality values without good reason, as this would limit the 890 ability of users to influence the negotiation process with their 891 own preference settings. The following table SHOULD be used as a 892 guide when assigning source quality values: 894 1.000 perfect representation 895 0.900 threshold of noticeable loss of quality 896 0.800 noticeable, but acceptable quality reduction 897 0.500 barely acceptable quality 898 0.300 severely degraded quality 899 0.000 completely degraded quality 901 Note that most meaningful values in this table are close to 1. 902 This is due to the fact that quality factors are generally combined 903 by multiplying them, not by adding them. 905 When assigning source-quality values, content providers MUST NOT 906 account for the size of the variant and its impact on transmission 907 and rendering delays. Any constant rendering delay for a 908 particular media type (for example due to the startup time of a 909 helper application) SHOULD be accounted for by the user agent, when 910 assigning a quality factor to that media type. 912 5.4 Type, charset, language, and length 914 The type attribute of a variant description carries the same 915 information as its Content-Type response header counterpart defined 916 in [1], except for any charset information, which MUST be carried 917 in the charset attribute. For, example, the header 919 Content-Type: text/html; charset=ISO-8859-4 921 has the counterpart attributes 923 {type text/html} {charset ISO-8859-4} 925 The language and length attributes carry the same information as 926 their Content-* response header counterparts in [1]. The length 927 attribute, if present, MUST thus reflect the length of the variant 928 alone, and not the total size of the variant and any objects 929 inlined or embedded by the variant. 931 Though all of these attributes are optional, it is often desirable 932 to include as many attributes as possible, as this will increase 933 the quality of the negotiation process. 935 Note: A server is not required to maintain a one-to-one 936 correspondence between the attributes in the variant description 937 and the Content-* headers in the variant response. For example, 938 if the variant description contains a language attribute, the 939 response does not necessarily have to contain a Content-Language 940 header. If a Content-Language header is present, it does not 941 have to contain an exact copy of the information in the language 942 attribute. 944 5.5 Features 946 The features attribute specifies how the presence or absence of 947 particular feature tags in the user agent affects the overall 948 quality of the variant. This attribute is covered in section 6.4. 950 5.6 Description 952 The description attribute gives a textual description of the 953 variant. It can be included if the URI and normal attributes of a 954 variant are considered too opaque to allow interpretation by the 955 user. If a user agent is showing a menu of available variants 956 compiled from a variant list, and if a variant has a description 957 attribute, the user agent SHOULD show the description attribute of 958 the variant instead of showing the normal attributes of the 959 variant. The description field uses the UTF-8 character encoding 960 scheme [7], which is a superset of US-ASCII, with ""%" HEX HEX" 961 encoding. 963 5.7 Extension-attribute 965 The extension-attribute allows future specifications to 966 incrementally define dimensions of negotiation which cannot be 967 created by using the feature negotiation framework, and eases 968 content negotiation experiments. In experimental situations, 969 servers MUST ONLY generate extension-attributes whose names start 970 with "x-". User agents SHOULD ignore all extension attributes they 971 do not recognize. Proxies MUST NOT run a remote variant selection 972 algorithm if an unknown extension attribute is present in the 973 variant list. 975 6 Feature negotiation 977 This section defines the feature negotiation mechanism. Feature 978 negotiation has been introduced in section 4.8. Appendix 19 979 contains examples of feature negotiation. 981 6.1 Feature tags 983 A feature tag (ftag) identifies something which can be negotiated 984 on, for example a property (feature) of a representation, a 985 capability (feature) of a user agent, or the preference of a user 986 for a particular type of representation. The use of feature tags 987 need not be limited to transparent content negotiation, and not 988 every feature tag needs to be usable in the HTTP transparent 989 content negotiation framework. 991 ftag = 1*( ALPHA | DIGIT | "." | "-" ) 993 Feature tags are used in feature sets (section 6.2) and in feature 994 predicates (section 6.3). Feature predicates are in turn used in 995 features attributes (section 6.4), which are used in variant 996 descriptions (section 5). Variant descriptions can be transmitted 997 in Alternates headers (section 8.3). 999 Feature tag comparison is case-insensitive. Examples are 1001 tables, fonts, blebber, wolx, screenwidth, colordepth 1003 An example of the use of feature tags in a variant description is: 1005 {"index.html" 1.0 {type text/html} {features tables frames}} 1007 This specification follows general computing practice in that it 1008 places no restrictions on what may be called a feature. Feature 1009 tag definitions SHOULD describe the tag from the viewpoint of the 1010 variant author. For example, a definition could start with `the X 1011 feature tag labels variants which are intended for...'. 1013 At the protocol level, this specification does not distinguish 1014 between different uses of feature tags: a tag will be processed in 1015 the same way, no matter whether it identifies a property, 1016 capability, or preference. For some tags, it may be fluid whether 1017 the tag represents a property, preference, or capability. For 1018 example, in content negotiation on web pages, a "textonly" tag 1019 would identify a capability of a text-only user agent, but the user 1020 of a graphical user agent may use this tag to specify that 1021 text-only content is preferred over graphical content. 1023 While the usage of some tags may be fluid, it is expected that 1024 other tag definitions will strictly limit the usage of a tag to 1025 expressing a property, capability, or preference only. However, 1026 the protocol does not contain any facilities which could enforce 1027 such limitations. 1029 6.1.1 Feature tag values 1031 The definition of a feature tag may state that a feature tag can 1032 have zero, one, or more values associated with it. These values 1033 specialize the meaning of the tag. For example, a feature tag 1034 `paper' could be associated with the values `A4' and `A5'. 1036 tag-value = token | quoted-string 1038 Equality comparison for tag values MUST be done with a 1039 case-sensitive, octet-by-octet comparison, where any ""%" HEX HEX" 1040 encodings MUST be processed as in [1]. A token value XYZ is equal 1041 to a quoted-string value "XYZ". 1043 6.2 Feature sets 1045 The feature set of a user agent is a data structure which records 1046 the capabilities of the user agent and the preferences of the user. 1048 Feature sets are used by local variant selection algorithms (see 1049 appendix 18 for an example). A user agent can use the 1050 Accept-Features header (section 8.2) to make some of the contents 1051 of its feature set known to remote variant selection algorithms. 1053 Structurally, a feature set is a possibly empty set, containing 1054 records of the form 1056 ( feature tag , set of feature tag values ) 1058 If a record with a feature tag is present in the set, this means 1059 that the user agent implements the corresponding capability, or 1060 that the user has expressed the corresponding preference. 1062 Each record in a feature set has a, possibly empty, set of tag 1063 values. For feature tags which cannot have values associated with 1064 it, this set is always empty. For feature tags which can have 1065 zero, one, or more values associated with it, this set contains 1066 those values currently associated with the tag. If the set of a 1067 featue tag T has the value V in it, it is said that `the tag T is 1068 present with the value V'. 1070 This specification does not define a standard notation for feature 1071 sets. An example of a very small feature set, in a mathematical 1072 notation, is 1074 { ( "frames" , { } ) , 1075 ( "paper" , { "A4" , "A5" } ) 1076 } 1078 As feature registration [4] will be an ongoing process, it is 1079 generally not possible for a user agent to know the meaning of all 1080 feature tags it can possibly encounter in a variant description. A 1081 user agent SHOULD treat all features tags unknown to it as absent 1082 from its feature set. 1084 A user agent may change the contents of its feature set depending 1085 on the type of request, and may also update it to reflect changing 1086 conditions, for example a change in the window size. Therefore, 1087 when considering feature negotiation, one usually talks about `the 1088 feature set of the current request'. 1090 6.3 Feature predicates 1092 Feature predicates are predicates on the contents of feature sets. 1093 They appear in the features attribute of a variant description. 1095 fpred = [ "!" ] ftag 1096 | ftag [ "!" ] "=" tag-value 1097 | ftag "=" "[" numeric-range "]" 1099 numeric-range = [ number ] "-" [ number ] 1101 Feature predicates are used in features attributes (section 6.4), 1102 which are used in variant descriptions (section 5). Variant 1103 descriptions can be transmitted in Alternates headers (section 1104 8.3). 1106 Examples of feature predicates are 1108 blebber, !blebber, paper=a4, colordepth=5, blex!=54, 1109 dpi=[300-599], colordepth=[24-] 1111 Using the feature set of the current request, a user agent SHOULD 1112 compute the truth value of the different feature predicates as 1113 follows. 1115 ftag true if the feature is present, false otherwise 1117 !ftag true if the feature is absent, false otherwise 1119 ftag=V true if the feature is present with the value V, 1120 false otherwise, 1122 ftag!=V true if the feature is not present with the value V, 1123 false otherwise, 1125 ftag=[N-M] true if the feature is present with at least one 1126 numeric value, while the highest value with which it 1127 is present in the range N-M, false otherwise. If N 1128 is missing, the lower bound is 0. If M is missing, 1129 the upper bound is infinity. 1131 As an example, with the feature set 1133 { ( "blex" , { } ), 1134 ( "colordepth" , { "5" } ), 1135 ( "UA-media" , { "stationary" } ), 1136 ( "paper" , { "A4", "A3" } ) , 1137 ( "x-version" , { "104", "200" } ) 1138 } 1140 the following predicates are true: 1142 blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, 1143 UA-media=stationary, UA-media!=screen, paper=A4, paper =!A0, 1144 colordepth=[ 4 - 6 ], x-version=[100-300], x-version=[200-300] 1146 and the following predicates are false: 1148 !blex, blebber, colordepth=6, colordepth=foo, !colordepth, 1149 screenwidth, screenwidth=640, screenwidth!=640, x-version=99, 1150 UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta 1152 6.4 Features attribute 1154 The features attribute, for which section 5.1 defines the syntax 1156 "{" "features" feature-list "}" 1158 is used in a variant description to specify how the presence or 1159 absence of particular feature tags in the user agent affects the 1160 overall quality of the variant. 1162 feature-list = 1%feature-list-element 1164 feature-list-element = ( fpred | fpred-bag ) 1165 [ ":" true-improvement ] 1166 [ "/" false-degradation ] 1168 fpred-bag = "[" 1%fpred "]" 1170 true-improvement = short-float 1171 false-degradation = short-float 1173 Features attributes are used in variant descriptions (section 5). 1174 Variant descriptions can be transmitted in Alternates headers 1175 (section 8.3). 1177 Examples are: 1179 {features !textonly [blebber !wolx] colordepth=3:0.7} 1181 {features !blink/0.5 background:1.5 [blebber !wolx]:1.4/0.8} 1183 The default value for the true-improvement is 1. The default value 1184 for the false-degradation is 0, or 1 if a true-improvement value is 1185 given. 1187 A user agent SHOULD, and a remote variant selection algorithm MUST 1188 compute the quality degradation factor associated with the features 1189 attribute by multiplying all quality degradation factors of the 1190 elements of the feature-list. Note that the result can be a factor 1191 greater than 1. 1193 A feature list element yields its true-improvement factor if the 1194 corresponding feature predicate is true, or if at least one element 1195 of the corresponding fpred-bag is true. The element yields its 1196 false-degradation factor otherwise. 1198 7 Remote variant selection algorithms 1200 A remote variant selection algorithm is a standardized algorithm 1201 by which a server can choose a best variant on behalf of a 1202 negotiating user agent. The use of a remote algorithm can speed up 1203 the negotiation process by eliminating a request-response round 1204 trip. 1206 A remote algorithm typically computes whether the Accept- headers in 1207 the request contain sufficient information to allow a choice, and 1208 if so, which variant is the best variant. This specification does 1209 not define any remote algorithms, but does define a mechanism to 1210 negotiate on the use of such algorithms. 1212 7.1 Version numbers 1214 A version numbering scheme is used to distinguish between different 1215 remote variant selection algorithms. 1217 rvsa-version = major "." minor 1219 major = 1*4DIGIT 1220 minor = 1*4DIGIT 1222 An algorithm with the version number X.Y, with Y>0, MUST be 1223 downwards compatible with all algorithms from X.0 up to X.Y. 1224 Downwards compatibility means that, if supplied with the same 1225 information, the newer algorithm MUST make the same choice, or a 1226 better choice, as the old algorithm. There are no compatibility 1227 requirements between algorithms with different major version 1228 numbers. 1230 8 Content negotiation status codes and headers 1232 This specification adds one new HTTP status code, and introduces 1233 six new HTTP headers. It also extends the semantics of an existing 1234 HTTP/1.1 header. 1236 8.1 506 Variant Also Negotiates 1238 The 506 status code indicates that the server has an internal 1239 configuration error: the chosen variant resource is configured to 1240 engage in transparent content negotiation itself, and is therefore 1241 not a proper end point in the negotiation process. 1243 8.2 Accept-Features 1245 The Accept-Features request header can be used by a user agent to 1246 give information about the presence or absence of certain features 1247 in the feature set of the current request. Servers can use this 1248 information when running a remote variant selection algorithm. 1250 Note: the name `Accept-Features' for this header was chosen 1251 because of symmetry considerations with other Accept- headers, 1252 even though the Accept-Features header will generally not 1253 contain an exhaustive list of features which are somehow 1254 `accepted'. A more accurate name of this header would have been 1255 `Feature-Set-Info'. 1257 Accept-Features = "Accept-Features" ":" 1258 #( feature-expr *( ";" feature-extension ) ) 1260 feature-expr = [ "!" ] ftag 1261 | ftag [ "!" ] "=" tag-value 1262 | ftag "=" "{" tag-value "}" 1263 | "*" 1265 feature-extension = token [ "=" ( token | quoted-string ) ] 1267 No feature extensions are defined in this specification. An 1268 example is: 1270 Accept-Features: blex, !blebber, colordepth={5}, !screenwidth, 1271 paper = A4, paper!="A2", x-version=104, * 1273 The different feature expressions have the following meaning: 1275 ftag ftag is present 1277 !ftag ftag is absent 1279 ftag=V ftag is present with the value V 1281 ftag!=V ftag is present, but not with the value V 1283 ftag={V} ftag is present with the value V, and not with any 1284 other values 1286 * the expressions in this header do not fully describe 1287 the feature set: feature tags not mentioned in this 1288 header may also be present, and, except for the case 1289 ftag={V}, tags may be present with more values than 1290 mentioned. 1292 Absence of the Accept-Features header in a request is equivalent to 1293 the inclusion of 1295 Accept-Features: * 1297 By using the Accept-Features header, a remote variant selection 1298 algorithm can sometimes determine the truth value of a feature 1299 predicate on behalf of the user agent. For example, with the 1300 header 1302 Accept-Features: blex, !blebber, colordepth={5}, !screenwidth, 1303 paper = A4, paper!="A2", x-version=104, * 1305 the algorithm can determine that the following predicates are true: 1307 blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, 1308 paper=A4, colordepth=[4-6] 1310 and that the following predicates are false: 1312 !blex, blebber, colordepth=6, colordepth=foo, !colordepth, 1313 screenwidth, screenwidth=640, screenwidth!=640, 1315 but the truth value of the following predicates cannot be 1316 determined: 1318 UA-media=stationary, UA-media!=screen, paper!=a0, 1319 x-version=[100-300], x-version=[200-300], x-version=99, 1320 UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta 1322 8.3 Alternates 1324 The Alternates response header is used to convey the list of 1325 variants bound to a negotiable resource. This list can also 1326 include directives for any content negotiation process. If a 1327 response from a transparently negotiable resource includes an 1328 Alternates header, this header MUST contain the complete variant 1329 list bound to the negotiable resource. Responses from resources 1330 which do not support transparent content negotiation MAY also use 1331 Alternates headers. 1333 Alternates = "Alternates" ":" variant-list 1335 variant-list = 1#( variant-description 1336 | fallback-variant 1337 | list-directive ) 1339 fallback-variant = "{" <"> URI <"> "}" 1341 list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> ) 1342 | extension-list-directive 1344 extension-list-directive = token [ "=" ( token | quoted-string ) ] 1346 An example is 1348 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 1349 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 1350 {"paper.ps.en" 1.0 {type application/postscript} 1351 {language en}}, 1352 proxy-rvsa="1.0, 2.5" 1354 Any relative URI specified in a variant-description or 1355 fallback-variant field is relative to the request-URI. Only one 1356 fallback-variant field may be present. If the variant selection 1357 algorithm of the user agent finds that all described variants are 1358 unacceptable, then it SHOULD choose the fallback variant, if 1359 present, as the best variant. If the user agent computes the 1360 overall quality values of the described variants, and finds that 1361 several variants share the highest value, then the first variant 1362 with this value in the list SHOULD be chosen as the best variant. 1364 The proxy-rvsa directive restricts the use of remote variant 1365 selection algorithms by proxies. If present, a proxy MUST ONLY use 1366 algorithms which have one of the version numbers listed, or have 1367 the same major version number and a higher minor version number as 1368 one of the versions listed. Any restrictions set by proxy-rvsa 1369 come on top of the restrictions set by the user agent in the 1370 Negotiate request header. The directive proxy-rvsa="" will disable 1371 variant selection by proxies entirely. Clients SHOULD ignore all 1372 extension-list-directives they do not understand. 1374 A variant list may contain multiple differing descriptions of the 1375 same variant. This can be convenient if the variant uses 1376 conditional rendering constructs, or if the variant resource 1377 returns multiple representations using a multipart media type. 1379 8.4 Negotiate 1381 The Negotiate request header can contain directives for any content 1382 negotiation process initiated by the request. 1384 Negotiate = "Negotiate" ":" 1#negotiate-directive 1386 negotiate-directive = "trans" 1387 | "vlist" 1388 | "guess-small" 1389 | rvsa-version 1390 | "*" 1391 | negotiate-extension 1393 negotiate-extension = token [ "=" token ] 1395 Examples are 1397 Negotiate: 1.0, 2.5 1398 Negotiate: * 1400 The negotiate directives have the following meaning 1402 "trans" 1403 The user agent supports transparent content negotiation for 1404 the current request. 1406 "vlist" 1407 The user agent requests that any transparently negotiated 1408 response for the current request includes an Alternates 1409 header with the variant list bound to the negotiable resource. 1410 Implies "trans". 1412 "guess-small" 1413 The user agent allows origin servers to run a custom algorithm 1414 which guesses the best variant for the request, and to return 1415 this variant in a choice response, if the resulting choice 1416 response is smaller than or not much larger than a list 1417 response. The definition of `not much larger' is left to 1418 origin server heuristics. Implies "vlist" and "trans". 1420 rvsa-version 1421 The user agent allows origin servers and proxies to run the 1422 remote variant selection algorithm with the indicated version 1423 number, or with the same major version number and a higher 1424 minor version number. If the algorithm has sufficient 1425 information to choose a best, neighboring variant, the origin 1426 server or proxy MAY return a choice response with this 1427 variant. Implies "trans". 1429 "*" 1430 The user agent allows origin servers and proxies to run any 1431 remote variant selection algorithm. The origin server may 1432 even run algorithms which have not been standardized. If the 1433 algorithm has sufficient information to choose a best, 1434 neighboring variant, the origin server or proxy MAY return a 1435 choice response with this variant. Implies "trans". 1437 Servers SHOULD ignore all negotiate-directives they do not 1438 understand. If the Negotiate header allows a choice between 1439 multiple remote variant selection algorithms which are all 1440 supported by the server, the server SHOULD use some internal 1441 precedence heuristics to select the best algorithm. 1443 8.5 TCN 1445 The TCN response header is used by a server to signal that the 1446 resource is transparently negotiated. 1448 TCN = "TCN" ":" #( response-type 1449 | server-side-override-directive 1450 | tcn-extension ) 1452 response-type = "list" | "choice" | "adhoc" 1454 server-side-override-directive = "re-choose" | "keep" 1456 tcn-extension = token [ "=" ( token | quoted-string ) ] 1458 If the resource is not transparently negotiated, a TCN header MUST 1459 NOT be included in any response. If the resource is transparently 1460 negotiated, a TCN header, which includes the response-type value of 1461 the response, MUST be included in every response with a 2xx status 1462 code or any 3xx status code, except 304, in which it MAY be 1463 included. A TCN header MAY also be included, without a 1464 response-type value, in other responses from transparently 1465 negotiated resources. 1467 A server-side override directive MUST be included if the origin 1468 server performed a server-side override when choosing the response. 1469 If the directive is "re-choose", the server MUST include an 1470 Alternates header with the variant bound to the negotiable resource 1471 in the response, and user agent SHOULD use its internal variant 1472 selection algorithm to choose, retrieve, and display the best 1473 variant from this list. If the directive is "keep" the user agent 1474 SHOULD NOT renegotiate on the response, but display it directly, or 1475 act on it directly if it is a redirection response. 1477 Clients SHOULD ignore all tcn-extensions they do not understand. 1479 8.6 Variant-Vary 1481 The Variant-Vary response header can be used in a choice response 1482 to record any vary information which applies to the variant data 1483 (the entity body combined with some of the entity headers) 1484 contained in the response, rather than to the response as a whole. 1486 Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name ) 1488 Use of the Variant-Vary header is discussed in section 10.2. 1490 9 Cache validators 1492 To allow for correct and efficient caching and revalidation of 1493 negotiated responses, this specification extends the caching model 1494 of HTTP/1.1 [1] in various ways. 1496 This specification does not introduce a `variant-list-max-age' 1497 directive which explicitly bounds the freshness lifetime of a 1498 cached variant list, like the `max-age' Cache-Control directive 1499 bounds the freshness lifetime of a cached response. However, this 1500 specification does ensure that a variant list which is sent at a 1501 time T by the origin server will never be re-used without 1502 revalidation by semantically transparent caches after the time T+M. 1503 This M is the maximum of all freshness lifetimes assigned (using 1504 max-age directives or Expires headers) by the origin server to 1506 a. the responses from the negotiable resource itself, and 1508 b. the responses from its neighboring variant resources 1510 If no freshness lifetimes are assigned by the origin server, M is 1511 the maximum of the freshness lifetimes which were heuristically 1512 assigned by all caches which can re-use the variant list. 1514 9.1 Variant list validators 1516 A variant list validator is an opaque value which acts as the cache 1517 validator of a variant list bound to a negotiable resource. 1519 variant-list-validator = <quoted-string not containing any ";"> 1521 If two responses contain the same variant list validator, a cache 1522 can treat the Alternates headers in these responses as equivalent 1523 (though the headers themselves need not be identical). 1525 9.2 Structured entity tags 1527 A structured entity tag consists of a normal entity tag of which 1528 the opaque string is extended with a semicolon followed by the text 1529 (without the surrounding quotes) of a variant list validator: 1531 normal | variant list | structured 1532 entity tag | validator | entity tag 1533 -------------+----------------+----------------- 1534 "etag" | "vlv" | "etag;vlv" 1535 W/"etag" | "vlv" | W/"etag;vlv" 1537 Note that a structured entity tag is itself also an entity tag. 1538 The structured nature of the tag allows caching proxies capable of 1539 transparent content negotiation to perform some optimizations 1540 defined in section 10. When not performing such optimizations, a 1541 structured tag SHOULD be treated as a single opaque value, 1542 according to the general rules in HTTP/1.1. Examples of structured 1543 entity tags are: 1545 "xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234" 1547 In the last example, the normal entity tag is "a;b;c;" and the 1548 variant list validator is "1234". 1550 If a transparently negotiated response includes an entity tag, it 1551 MUST be a structured entity tag. The variant list validator in the 1552 structured tag MUST act as a validator for the variant list 1553 contained in the Alternates header. The normal entity tag in the 1554 structured tag MUST act as a validator of the entity body in the 1555 response and of all entity headers except Alternates. 1557 9.3 Assigning entity tags to variants 1559 To allow for correct revalidation of transparently negotiated 1560 responses by clients, origin servers SHOULD generate all normal 1561 entity tags for the neighboring variant resources of the negotiable 1562 resource in such a way that 1564 1. the same tag is never used by two different variants, 1565 unless this tag labels exactly the same entity on all 1566 occasions, 1568 2. if one normal tag "X" is a prefix of another normal tag "XY", 1569 then "Y" must never be a semicolon followed by a variant list 1570 validator. 1572 10 Content negotiation responses 1574 If a request on a transparently negotiated resource yields a 1575 response with a 2xx status code or any 3xx status code except 304, 1576 this response MUST always be either a list response, a choice 1577 response, or an adhoc response. These responses MUST always 1578 include a TCN header which specifies their type. Transparently 1579 negotiated responses with other status codes MAY also include a TCN 1580 header. 1582 The conditions under which the different content negotiation 1583 responses may be sent are defined in section 12.1 for origin 1584 servers and in section 13 for proxies. 1586 After having constructed a list, choice, or adhoc response, a 1587 server MAY process any If-No-Match or If-Range headers in the 1588 request message and shorten the response to a 304 (Not Modified) or 1589 206 (Partial Content) response, following the rules in the HTTP/1.1 1590 specification [1]. In this case, the entity tag of the shortened 1591 response will identify it indirectly as a list, choice, or adhoc 1592 response. 1594 10.1 List response 1596 A list response returns the variant list of the negotiable 1597 resource, but no variant data. It can be generated when the server 1598 does not want to, or is not allowed to, return a particular best 1599 variant for the request. If the user agent supports transparent 1600 content negotiation, the list response will cause it to select a 1601 best variant and retrieve it. 1603 A list response MUST contain (besides the normal headers required 1604 by HTTP) a TCN header which specifies the "list" response-type, the 1605 Alternates header bound to the negotiable resource, a Vary header 1606 and (unless it was a HEAD request) an entity body which allows the 1607 user to manually select the best variant. 1609 An example of a list response is 1611 HTTP/1.1 300 Multiple Choices 1612 Date: Tue, 11 Jun 1996 20:02:21 GMT 1613 TCN: list 1614 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 1615 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 1616 {"paper.ps.en" 1.0 {type application/postscript} 1617 {language en}} 1618 Vary: negotiate, accept, accept-language 1619 ETag: "blah;1234" 1620 Cache-control: max-age=86400 1621 Content-Type: text/html 1622 Content-Length: 227 1624 <h2>Multiple Choices:</h2> 1625 <ul> 1626 <li><a href=paper.1>HTML, English version</a> 1627 <li><a href=paper.2>HTML, French version</a> 1628 <li><a href=paper.3>Postscript, English version</a> 1629 </ul> 1631 Note: A list response can have any status code, but the 300 1632 (Multiple Choices) code is the most appropriate one for HTTP/1.1 1633 clients. Some existing versions of HTTP/1.0 clients are known 1634 to silently ignore 300 responses, instead of handling them 1635 according to the HTTP/1.0 specification [3]. Servers should 1636 therefore be careful in sending 300 responses to non-negotiating 1637 HTTP/1.0 user agents, and in making these responses cacheable. 1638 The 200 (OK) status code can be used instead. 1640 The Vary header in the response SHOULD ensure correct handling by 1641 plain HTTP/1.1 caching proxies. This header can either be 1643 Vary: * 1645 or a more elaborate header; see section 10.6.1. 1647 Only the origin server may construct list responses. Depending on 1648 the status code, a list response is cacheable unless indicated 1649 otherwise. 1651 According to the HTTP/1.1 specification [1], a user agent which 1652 does not support transparent content negotiation will, when 1653 receiving a list response with the 300 status code, display the 1654 entity body included in the response. If the response contains a 1655 Location header, however, the user agent MAY automatically redirect 1656 to this location. 1658 The handling of list responses by clients supporting transparent 1659 content negotiation is described in sections 11.1 and 13. 1661 10.2 Choice response 1663 A choice response returns a representation of the best variant for 1664 the request, and may also return the variant list of the negotiable 1665 resource. It can be generated when the server has sufficient 1666 information to be able to choose the best variant on behalf the 1667 user agent, but may only be generated if this best variant is a 1668 neighboring variant. For request from user agents which do not 1669 support transparent content negotiation, a server may always 1670 generate a choice response, provided that the variant returned is a 1671 neighboring variant. The variant returned in a choice response 1672 need not necessarily be listed in the variant list bound to the 1673 negotiable resource. 1675 A choice response merges a normal HTTP response from the chosen 1676 variant, a TCN header which specifies the "choice" response-type, 1677 and a Content-Location header giving the location of the variant. 1678 Depending on the status code, a choice response is cacheable unless 1679 indicated otherwise. 1681 Origin servers and proxy caches MUST construct choice responses 1682 with the following algorithm (or any other algorithm which gives 1683 equal end results for the client). 1685 In this algorithm, `the current Alternates header' refers to the 1686 Alternates header containing the variant list which was used to 1687 choose the best variant, and `the current variant list validator' 1688 refers to the validator of this list. Section 10.4 specifies how 1689 these two items can be obtained by a proxy cache. 1691 The algorithm consists of four steps. 1693 1. Construct a HTTP request message on the best variant resource 1694 by rewriting the request-URI and Host header (if appropriate) 1695 of the received request message on the negotiable resource. 1697 2. Generate a valid HTTP response message, but not one with the 1698 304 (Not Modified) code, for the request message constructed 1699 in step 1. 1701 In a proxy cache, the response can be obtained from cache 1702 memory, or by passing the constructed HTTP request towards the 1703 origin server. If the request is passed on, the proxy MAY 1704 add, modify, or delete If-None-Match and If-Range headers to 1705 optimize the transaction with the upstream server. 1707 Note: the proxy should be careful not to add entity tags of 1708 non-neighboring variants to If-* (conditional) headers of 1709 the request, as there are no global uniqueness requirements 1710 for these tags. 1712 3. Only in origin servers: check for an origin server 1713 configuration error. If the HTTP response message generated in 1714 step 2 contains a TCN header, then the best variant resource 1715 is not a proper end point in the transparent negotiation 1716 process, and a 506 (Variant Also Negotiates) error response 1717 message SHOULD be generated instead of going to step 4. 1719 4. Add a number of headers to the HTTP response message generated 1720 in step 2. 1722 a. Add a TCN header which specifies the "choice" 1723 response-type. 1725 b. Add a Content-Location header giving the location of the 1726 chosen variant. Delete any Content-Location header which 1727 was already present. 1729 Note: According to the HTTP/1.1 specification [1], if 1730 the Content-Location header contains a relative URI, 1731 this URI is relative to the URI in the Content-Base 1732 header, if present, and relative to the request-URI if 1733 no Content-Base header is present. 1735 c. If any Vary headers are present in the response message 1736 from step 2, add, for every Vary header, a Variant-Vary 1737 header with a copy of the contents of this Vary header. 1739 d. Delete any Alternates headers which are present in in the 1740 response. Now, the current Alternates header MUST be added 1741 if this is required by the Negotiate request header, or if 1742 the server returns "re-choose" in the TCN response header. 1743 Otherwise, the current Alternates header MAY be added. 1745 Note: It is usually a good strategy to always add the 1746 current Alternates header, unless it is very large 1747 compared to the rest of the response. 1749 e. Add a Vary header to ensure correct handling by plain 1750 HTTP/1.1 caching proxies. This header can either be 1752 Vary: * 1754 or a more elaborate header, see section 10.6. 1756 f. To ensure compatibility with HTTP/1.0 caching proxies which 1757 do not recognize the Vary header, an Expires header with a 1758 date in the past MAY be added. See section 10.7 for more 1759 information. 1761 g. If an ETag header is present in the response message from 1762 step 2, then extend the entity tag in that header with the 1763 current variant list validator, as specified in section 1764 9.2. 1766 Note: Step g. is required even if the variant list 1767 itself is not added in step d. 1769 h. Only in proxy caches: set the Age header of the response to 1771 max( variant_age , alternates_age ) 1773 where variant_age is the age of the variant response 1774 obtained in step 2, calculated according to the rules in 1775 the HTTP/1.1 specification [1], and alternates_age is the 1776 age of the Alternates header added in step d, calculated 1777 according to the rules in section 10.4. 1779 Note that a server can shorten the response produced by the above 1780 algorithm to a 304 (Not Modified) response if an If-None-Match 1781 header in the original request allows it. If this is the case, an 1782 implementation of the above algorithm can avoid the unnecessary 1783 internal construction of full response message in step 2, it need 1784 only construct the parts which end up in the final 304 response. A 1785 proxy cache which implements this optimization can sometimes 1786 generate a legal 304 response even if it has not cached the variant 1787 data itself. 1789 An example of a choice response is: 1791 HTTP/1.1 200 OK 1792 Date: Tue, 11 Jun 1996 20:05:31 GMT 1793 TCN: choice 1794 Content-Type: text/html 1795 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 1796 Content-Length: 5327 1797 Cache-control: max-age=604800 1798 Content-Location: paper.1 1799 Alternates: {"paper.1" 0.9 {type text/html} {language en}}, 1800 {"paper.2" 0.7 {type text/html} {language fr}}, 1801 {"paper.3" 1.0 {type application/postscript} 1802 {language en}} 1803 Etag: "gonkyyyy;1234" 1804 Vary: negotiate, accept, accept-language 1805 Expires: Thu, 01 Jan 1980 00:00:00 GMT 1807 <title>A paper about .... 1809 10.3 Adhoc response 1811 An adhoc response can be sent by an origin server as an extreme 1812 measure, to achieve compatibility with a non-negotiating or buggy 1813 client if this compatibility cannot be achieved by sending a list 1814 or choice response. There are very little requirements on the 1815 contents of an adhoc response. An adhoc response MUST have a TCN 1816 header which specifies the "adhoc" response-type, and a Vary header 1817 if the response is cacheable. It MAY contain the Alternates header 1818 bound to the negotiable resource. 1820 Any Vary header in the response SHOULD ensure correct handling by 1821 plain HTTP/1.1 caching proxies. This header can either be 1823 Vary: * 1825 or a more elaborate header, see section 10.6.1. Depending on the 1826 status code, an adhoc response is cacheable unless indicated 1827 otherwise. 1829 As an example of the use of an adhoc response, suppose that the 1830 variant resource "redirect-to-blah" yields redirection (302) 1831 responses. A choice response with this variant could look as 1832 follows: 1834 HTTP/1.1 302 Moved Temporarily 1835 Date: Tue, 11 Jun 1996 20:02:28 GMT 1836 TCN: choice 1837 Content-location: redirect-to-blah 1838 Location: http://blah.org/ 1839 Content-Type: text/html 1840 Content-Length: 62 1842 This document is available <a href=http://blah.org/>here</a>. 1844 Suppose that the server knows that the receiving user agent has a 1845 bug, which causes it to crash on responses which contain both a 1846 Content-Location and a Location header. The server could then work 1847 around this bug by performing a server-side override and sending 1848 the following adhoc response instead: 1850 HTTP/1.1 302 Moved Temporarily 1851 Date: Tue, 11 Jun 1996 20:02:28 GMT 1852 TCN: adhoc, keep 1853 Location: http://blah.org/ 1854 Content-Type: text/html 1855 Content-Length: 62 1857 This document is available <a href=http://blah.org/>here</a>. 1859 10.4 Reusing the Alternates header 1861 If a proxy cache has available a negotiated response which is 1862 cacheable, fresh, and has ETag and Alternates headers, then it MAY 1863 extract the Alternates header and associated variant list validator 1864 from the response, and reuse them (without unnecessary delay) to 1865 negotiate on behalf of the user agent (section 13) or to construct 1866 a choice response (section 10.2). The age of the extracted 1867 Alternates header is the age of the response from which it is 1868 extracted, calculated according to the rules in the HTTP/1.1 1869 specification [1]. 1871 10.5 Extracting a normal response from a choice response 1873 If a proxy receives a choice response, it MAY extract and cache the 1874 normal HTTP response contained therein. The normal response can be 1875 extracted by taking a copy of the choice response and then deleting 1876 any Content-Location, Alternates, and Vary headers, renaming any 1877 Variant-Vary headers to Vary headers, and shortening the structured 1878 entity tag in any ETag header to a normal entity tag. 1880 This normal response MAY be cached (as a HTTP response to the 1881 variant request as constructed in step 1. of section 10.2) and 1882 reused to answer future direct requests on the variant resource, 1883 according to the rules in the HTTP/1.1 specification [1]. 1885 Note: The caching of extracted responses can decrease the 1886 upstream bandwidth usage with up to a factor 2, because two 1887 independent HTTP/1.1 cache entries, one associated with the 1888 negotiable resource URI and one with the variant URI, are 1889 created in the same transaction. Without this optimization, 1890 both HTTP/1.1 cache entries can only be created by transmitting 1891 the variant data twice. 1893 For security reasons (see section 14.2), an extracted normal 1894 response MUST NEVER be cached if belongs to a non-neighboring 1895 variant resource. If the choice response claims to contain data 1896 for a non-neighboring variant resource, the proxy SHOULD reject the 1897 choice response as a probable spoofing attempt. 1899 10.6 Elaborate Vary headers 1901 If a HTTP/1.1 [1] server can generate varying responses for a 1902 request on some resource, then the server MUST include a Vary 1903 header in these responses if they are cacheable. This Vary header 1904 is a signal to HTTP/1.1 caches that something special is going on. 1905 It prevents the caches from returning the currently chosen response 1906 for every future request on the resource. 1908 Servers engaging in transparent content negotiation will generate 1909 varying responses. Therefore, cacheable list, choice, and adhoc 1910 responses MUST always include a Vary header. 1912 The most simple Vary header which can be included is 1914 Vary: * 1916 This header leaves the way in which the response is selected by the 1917 server completely unspecified. 1919 A more elaborate Vary header MAY be used to allow for certain 1920 optimizations in HTTP/1.1 caches which do not have specific 1921 optimizations for transparent content negotiation, but which do 1922 cache multiple variant responses for one resource. Such a more 1923 elaborate Vary header lists all request headers which can be used 1924 by the server when selecting a response for a request on the 1925 resource. 1927 10.6.1 Construction of an elaborate Vary header 1929 Origin servers can construct a more elaborate Vary header in the 1930 following way. First, start with the header 1932 Vary: negotiate 1934 `negotiate' is always included because servers use the information 1935 in the Negotiate header when choosing between a list, choice, or 1936 adhoc response. 1938 Then, if any of the following attributes is present in any variant 1939 description in the Alternates header, add the corresponding header 1940 name to the Vary header 1942 attribute | header name to add 1943 -----------+--------------------- 1944 type | accept 1945 charset | accept-charset 1946 language | accept-language 1947 features | accept-features 1949 The Vary header constructed in this way specifies the response 1950 variation which can be caused by the use of a variant selection 1951 algorithm in proxies. If the origin server will in some cases, for 1952 example if contacted by a non-negotiating user agent, use a custom 1953 negotiation algorithm which takes additional headers into account, 1954 these names of these headers SHOULD also be added to the Vary 1955 header. 1957 10.6.2 Caching of an elaborate Vary header 1959 A proxy cache cannot construct an elaborate vary header using the 1960 method above, because this method requires exact knowledge of any 1961 custom algorithms present in the origin server. However, when 1962 extracting an Alternates header from a response (section 10.4) 1963 caches MAY also extract the Vary header in the response, and reuse 1964 it along with the Alternates header. A clean Vary header can 1965 however only be extracted if the variant does not vary itself, 1966 i.e. if a Variant-Vary header is absent. 1968 10.7 Adding an Expires header to ensure HTTP/1.0 compatibility 1970 To ensure compatibility with HTTP/1.0 caching proxies which do not 1971 recognize the Vary header, an Expires header with a date in the 1972 past can be added to the response, for example 1974 Expires: Thu, 01 Jan 1980 00:00:00 GMT 1976 If this is done by an origin server, the server SHOULD usually also 1977 include a Cache-Control header for the benefit of HTTP/1.1 caches, 1978 for example 1980 Cache-Control: max-age=604800 1982 which overrides the freshness lifetime of zero seconds specified by 1983 the included Expires header. 1985 Note: This specification only claims downwards compatibility 1986 with the HTTP/1.0 proxy caches which implement the HTTP/1.0 1987 specification [3]. Some legacy proxy caches which return the 1988 HTTP/1.0 protocol version number do not honor the HTTP/1.0 1989 Expires header as specified in [3]. Methods for achieving 1990 compatibility with such proxy caches are beyond the scope of 1991 this specification. 1993 10.8 Negotiation on content encoding 1995 Negotiation on the content encoding of a response is orthogonal to 1996 transparent content negotiation. The rules for when a content 1997 encoding may be applied are the same as in HTTP/1.1: servers MAY 1998 content-encode responses that are the result of transparent content 1999 negotiation whenever an Accept-Encoding header in the request 2000 allows it. When negotiating on the content encoding of a cacheable 2001 response, servers MUST add the accept-encoding header name to the 2002 Vary header of the response, or add `Vary: *'. 2004 Servers SHOULD always be able to provide unencoded versions of 2005 every transparently negotiated response. This means in particular 2006 that every variant in the variant list SHOULD at least be available 2007 in an unencoded form. 2009 Like HTTP/1.1, this specification allows proxies to encode or 2010 decode relayed or cached responses on the fly, unless explicitly 2011 forbidden by a Cache-Control directive. The encoded or decoded 2012 response still contains the same variant as far as transparent 2013 content negotiation is concerned. Note that HTTP/1.1 requires 2014 proxies to add a Warning header if the encoding of a response is 2015 changed. 2017 11 User agent support for transparent negotiation 2019 This section specifies the requirements a user agent needs to 2020 satisfy in order to support transparent negotiation. If the user 2021 agent contains an internal cache, this cache MUST conform to the 2022 rules for proxy caches in section 13. 2024 11.1 Handling of responses 2026 If a list response is received when a resource is accessed, the 2027 user agent MUST be able to automatically choose, retrieve, and 2028 display the best variant, or display an error message if none of 2029 the variants are acceptable. 2031 If a choice response is received when a resource is accessed, the 2032 usual action is to automatically display the enclosed entity. 2033 However, if a remote variant selection algorithm which was enabled 2034 could have made a choice different from the choice the local 2035 algorithm would make, the user agent MAY apply its local algorithm 2036 to any variant list in the response, and automatically retrieve and 2037 display another variant if the local algorithm makes an other 2038 choice. 2040 When receiving a choice response, a user agent SHOULD check if 2041 variant resource is a neighboring variant resource of the 2042 negotiable resource. If this is not the case, the user agent 2043 SHOULD reject the choice response as a probable spoofing attempt 2044 and display an error message, for example by internally replacing 2045 the choice response with a 502 (bad gateway) response. 2047 11.2 Presentation of a transparently negotiated resource 2049 If the user agent is displaying a variant which is not an embedded 2050 or inlined object and which is the result of transparent content 2051 negotiation, the following requirements apply. 2053 1. The user agent SHOULD allow the user to review a list of all 2054 variants bound to the negotiable resource, and to manually 2055 retrieve another variant if desired. There are two general 2056 ways of providing such a list. First, the information in the 2057 Alternates header of the negotiable resource could be used to 2058 make an annotated menu of variants. Second, the entity 2059 included in a list response of the negotiable resource could be 2060 displayed. Note that a list response can be obtained by doing 2061 a GET request which only has the "trans" directive in the 2062 Negotiate header. 2064 2. The user agent SHOULD make available though its user interface 2065 some indication that the resource being displayed is a 2066 negotiated resource instead of a plain resource. It SHOULD 2067 also allow the user to examine the variant list included in the 2068 Alternates header. Such a notification and review mechanism is 2069 needed because of privacy considerations, see section 14.1. 2071 3. If the user agent shows the URI of the displayed information to 2072 the user, it SHOULD be the negotiable resource URI, not the 2073 variant URI that is shown. This encourages third parties, who 2074 want to refer to the displayed information in their own 2075 documents, to make a hyperlink to the negotiable resource as a 2076 whole, rather than to the variant resource which happens to be 2077 shown. Such correct linking is vital for the interoperability 2078 of content across sites. The user agent SHOULD however also 2079 provide a means for reviewing the URI of the particular variant 2080 which is currently being displayed. 2082 4. Similarly, if the user agent stores a reference to the 2083 displayed information for future use, for example in a hotlist, 2084 it SHOULD store the negotiable resource URI, not the 2085 variant URI. 2087 It is encouraged, but not required, that some of the above 2088 functionality is also made available for inlined or embedded 2089 objects, and when a variant which was selected manually is being 2090 displayed. 2092 12 Origin server support for transparent negotiation 2094 12.1 Requirements 2096 To implement transparent negotiation on a resource, the origin 2097 server MUST be able to send a list response when getting a GET 2098 request on the resource. It SHOULD also be able to send 2099 appropriate list responses for HEAD requests. When getting a 2100 request on a transparently negotiable resource, the origin server 2101 MUST NEVER return a response with a 2xx status code or any 3xx 2102 status code, except 304, which is not a list, choice, or adhoc 2103 response. 2105 If the request includes a Negotiate header with a "vlist" or 2106 "trans" directive, but without any directive which allows the 2107 server to select a best variant, a list response MUST ALWAYS be 2108 sent, except when the server is performing a server-side override 2109 for bug compatibility. If the request includes a Negotiate header 2110 with a "vlist" or "guess-small" directive, an Alternates header 2111 with the variant list bound to the negotiable resource MUST ALWAYS 2112 be sent in any list, choice, or adhoc response, except when the 2113 server is performing a server-side override for bug compatibility. 2115 If the Negotiate header allows it, the origin server MAY run a 2116 remote variant selection algorithm. If the algorithm has 2117 sufficient information to choose a best variant, and if the best 2118 variant is a neighboring variant, the origin server MAY return a 2119 choice response with this variant. 2121 When getting a request on a transparently negotiable resource from 2122 a user agent which does not support transparent content 2123 negotiation, the origin server MAY use a custom algorithm to select 2124 between sending a list, choice, or adhoc response. 2126 The following table summarizes the rules above. 2128 |Req on |Usr agnt|server- | Response may be: | 2129 |trans neg|capable |side +------+------+------+------+------+ 2130 |resource?|of TCN? |override?|list |choice|adhoc |normal|error | 2131 +---------+--------+---------+------+------+------+------+------+ 2132 | Yes | Yes | No |always|smt(*)|never |never |always| 2133 | Yes | Yes | Yes |always|always|always|never |always| 2134 +---------+--------+---------+------+------+------+------+------+ 2135 | Yes | No | - |always|always|always|never |always| 2136 +---------+--------+---------+------+------+------+------+------+ 2137 | No | - | - |never |never |never |always|always| 2138 +---------+--------+---------+------+------+------+------+------+ 2139 (*) sometimes, when allowed by the Negotiate request header 2141 Negotiability is a binary property: a resource is either 2142 transparently negotiated, or it is not. Origin servers SHOULD NOT 2143 vary the negotiability of a resource, or the variant list bound to 2144 that resource, based on the request headers which are received. 2145 The variant list and the property of being negotiated MAY however 2146 change through time. The Cache-Control header can be used to 2147 control the propagation of such time-dependent changes through 2148 caches. 2150 It is the responsibility of the author of the negotiable resource 2151 to ensure that all resources in the variant list serve the intended 2152 content, and that the variant resources do not engage in 2153 transparent content negotiation themselves. 2155 12.2 Negotiation on transactions other than GET and HEAD 2157 If a resource is transparently negotiable, this only has an impact 2158 on the GET and HEAD transactions on the resource. It is not 2159 possible (under this specification) to do transparent content 2160 negotiation on the direct result of a POST request. 2162 However, a POST request can return an unnegotiated 303 (See Other) 2163 response which causes the user agent to do a GET request on a 2164 second resource. This second resource could then use transparent 2165 content negotiation to return an appropriate final response. The 2166 figure below illustrates this. 2168 Server ______ proxy ______ proxy ______ user 2169 x.org cache cache agent 2171 < ------------------------------------- 2172 | POST http://x.org/cgi/submit 2173 | <form contents in request body> 2174 | 2175 -------------------------------------- > 2176 303 See Other | 2177 Location: http://x.org/result/OK | 2178 | 2179 < ------------------------------------- 2180 | GET http://x.org/result/OK 2181 | small Accept- headers 2182 | 2183 able to choose on 2184 behalf of user agent 2185 | 2186 ------------------------------------- > 2187 choice response with | 2188 ..result/OK.nl variant | 2189 displays OK.nl 2191 See the HTTP/1.1 specification [1] for details on the 303 (See 2192 Other) status code. Note that this status code is not understood 2193 by some HTTP/1.0 clients. 2195 13 Proxy support for transparent negotiation 2197 Transparent content negotiation is an extension on top of HTTP/1.x. 2198 It is designed to work through any proxy which only implements the 2199 HTTP/1.1 specification [1]. If Expires headers are added as 2200 discussed in section 10.7, negotiation will also work though 2201 proxies which implement HTTP/1.0 [3]. Thus, every HTTP/1.0 or 2202 HTTP/1.1 proxy provides support for transparent content 2203 negotiation. However, if it is to be claimed that a HTTP/1.x proxy 2204 offers transparent content negotiation services, at least one of 2205 the specific optimizations below MUST be implemented. 2207 An HTTP/1.x proxy MUST ONLY optimize (change) the HTTP traffic 2208 flowing through it in ways which are explicitly allowed by the 2209 specification(s) it conforms to. A proxy which supports 2210 transparent content negotiation on top of HTTP/1.x MAY perform the 2211 optimizations allowed for by HTTP/1.x. In addition, it MAY perform 2212 three additional optimizations, defined below, on the HTTP traffic 2213 for transparently negotiated resources and their neighboring 2214 variant resources. 2216 First, when getting a request on a transparently negotiable 2217 resource from a user agent which supports transparent content 2218 negotiation, the proxy MAY return any cached, fresh list response 2219 from that resource, even if the selecting request headers, as 2220 specified by the Vary header, do not match. 2222 Second, when allowed by the user agent and origin server, a proxy 2223 MAY reuse an Alternates header taken from a previous response 2224 (section 10.4) to run a remote variant selection algorithm. If the 2225 algorithm has sufficient information to choose a best variant, and 2226 if the best variant is a neighboring variant, the proxy MAY return 2227 a choice response with this variant. 2229 Third, if a proxy receives a choice response, it MAY extract and 2230 cache the normal response embedded therein, as described in section 2231 10.5. 2233 14 Security and privacy considerations 2235 14.1 Accept- headers revealing information of a private nature 2237 Accept- headers, in particular Accept-Language headers, may reveal 2238 information which the user would rather keep private unless it will 2239 directly improve the quality of service. For example, a user may 2240 not want to send language preferences to sites which do not offer 2241 multi-lingual content. The transparent content negotiation 2242 mechanism allows user agents to omit sending of the Accept-Language 2243 header by default, without adversely affecting the outcome of the 2244 negotiation process if transparently negotiated multi-lingual 2245 content is accessed. 2247 However, even if Accept- headers are never sent, the automatic 2248 selection and retrieval of a variant by a user agent will reveal a 2249 preference for this variant to the server. A malicious service 2250 author could provide a page with `fake' negotiability on 2251 (ethnicity-correlated) languages, with all variants actually being 2252 the same English document, as a means of obtaining 2253 privacy-sensitive information. Such a plot would however be 2254 visible to an alert victim if the list of available variants and 2255 their properties is reviewed. 2257 Some additional privacy considerations connected to Accept- headers 2258 are discussed in [1]. 2260 14.2 Spoofing of responses from variant resources 2262 The caching optimization in section 10.5 gives the implementer of a 2263 negotiable resource control over the responses cached for all 2264 neighboring variant resources. This is a security problem if a 2265 neighboring variant resource belongs to another author. To provide 2266 security in this case, the HTTP server will have to filter the 2267 Content-Location headers in the choice responses generated by the 2268 negotiable resource implementation. 2270 14.3 Security holes revealed by negotiation 2272 Malicious servers could use transparent content negotiation as a 2273 means of obtaining information about security holes which may be 2274 present in user agents. This is a risk in particular for 2275 negotiation on the availability of scripting languages and 2276 libraries. 2278 15 Acknowledgments 2280 Work on HTTP content negotiation has been done since at least 1993. 2281 The authors are unable to trace the origin of many of the ideas 2282 incorporated in this document. This specification builds on an 2283 earlier incomplete specification of content negotiation recorded in 2284 [2]. Many members of the HTTP working group have contributed to 2285 the negotiation model in this specification. The authors wish to 2286 thank the individuals who have commented on earlier versions of 2287 this document, including Brian Behlendorf, Daniel DuBois, Martin 2288 J. Duerst, Roy T. Fielding, Jim Gettys, Yaron Goland, Dirk van 2289 Gulik, Ted Hardie, Graham Klyne, Scott Lawrence, Larry Masinter, 2290 Jeffrey Mogul, Henrik Frystyk Nielsen, Frederick G.M. Roeber, Paul 2291 Sutton, and Klaus Weide. 2293 16 References 2295 [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 2296 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 2297 2068, HTTP Working Group, January, 1997. 2299 [2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. 2300 Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft 2301 draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, 2302 1996. 2304 [3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext 2305 Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, 2306 May 1996. 2308 [4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. 2309 Internet-Draft draft-ietf-http-feature-reg-01.txt, HTTP Working 2310 Group, July 7, 1997. 2312 [5] K. Holtman, A. Mutz. HTTP Remote Variant Selection Algorithm 2313 -- RVSA/1.0. Internet-Draft draft-ietf-http-rvsa-v10-01.txt, 2314 HTTP Working Group. March 23, 1997. 2316 [6] S. Bradner. Key words for use in RFCs to Indicate Requirement 2317 Levels. RFC 2119. Harvard University, March 1997. 2319 [7] F. Yergeau. UTF-8, a transformation format of Unicode and ISO 2320 10646. RFC 2044. Alis Technologies, October 1996. 2322 17 Authors' addresses 2324 Koen Holtman 2325 Technische Universiteit Eindhoven 2326 Postbus 513 2327 Kamer HG 6.57 2328 5600 MB Eindhoven (The Netherlands) 2329 Email: koen@win.tue.nl 2331 Andrew H. Mutz 2332 Hewlett-Packard Company 2333 1501 Page Mill Road 3U-3 2334 Palo Alto CA 94304, USA 2335 Fax +1 415 857 4691 2336 Email: mutz@hpl.hp.com 2338 18 Appendix: Example of a local variant selection algorithm 2340 A negotiating user agent will choose the best variant from a 2341 variant list with a local variant selection algorithm. This 2342 section contains an example of such an algorithm. 2344 The inputs of the algorithm are a variant list from an Alternates 2345 header, and an agent-side configuration database, which contains 2347 - the feature set of the current request, 2349 - a collection of quality values assigned to media types, 2350 languages, and charsets for the current request, following the 2351 model of the corresponding HTTP/1.1 [1] Accept* headers, 2353 - a table which lists `forbidden' combinations of media types and 2354 charsets, i.e. combinations which cannot be displayed because 2355 of some internal user agent limitation. 2357 The output of the algorithm is either the best variant, or the 2358 conclusion that none of the variants are acceptable. 2360 18.1 Computing overall quality values 2362 As a first step in the local variant selection algorithm, the 2363 overall qualities associated with all variant descriptions in the 2364 list are computed. 2366 The overall quality Q of a variant description is the value 2368 Q = round5( qs * qt * qc * ql * qf * qa ) 2370 where rounds5 is a function which rounds a floating point value to 2371 5 decimal places after the point. It is assumed that the user 2372 agent can run on multiple platforms: the rounding function makes 2373 the algorithm independent of the exact characteristics of the 2374 underlying floating point hardware. 2376 The factors qs, qt, qc, ql, qf, and qa are determined as follows. 2378 qs Is the source quality factor in the variant description. 2380 qt The media type quality factor is 1 if there is no type 2381 attribute in the variant description. Otherwise, it is the 2382 quality value assigned to this type by the configuration 2383 database. If the database does not assign a value, then the 2384 factor is 0. 2386 qc The charset quality factor is 1 if there is no charset 2387 attribute in the variant description. Otherwise, it is the 2388 quality value assigned to this charset by the configuration 2389 database. If the database does not assign a value, then the 2390 factor is 0. 2392 ql The language quality factor is 1 if there is no language 2393 attribute in the variant description. Otherwise, it is the 2394 highest quality value the configuration database assigns to 2395 any of the languages listed in the language attribute. If 2396 the database does not assign a value to any of the languages 2397 listed, then the factor is 0. 2399 qf The features quality factor is 1 if there is no features 2400 attribute in the variant description. Otherwise, it is the 2401 quality degradation factor computed for the features 2402 attribute using the feature set of the current request. 2404 qa The quality adjustment factor is 0 if the variant description 2405 lists a media type - charset combination which is `forbidden' 2406 by the table, and 1 otherwise. 2408 As an example, if a variant list contains the variant description 2410 {"paper.2" 0.7 {type text/html} {language fr}} 2412 and if the configuration database contains the quality value 2413 assignments 2415 types: text/html;q=1.0, type application/postscript;q=0.8 2416 languages: en;q=1.0, fr;q=0.5 2418 then the local variant selection algorithm will compute the overall 2419 quality for the variant description as follows: 2421 {"paper.2" 0.7 {type text/html} {language fr}} 2422 | | | 2423 | | | 2424 V V V 2425 round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000 2427 With same configuration database, the variant list 2429 {"paper.1" 0.9 {type text/html} {language en}}, 2430 {"paper.2" 0.7 {type text/html} {language fr}}, 2431 {"paper.3" 1.0 {type application/postscript} {language en}} 2433 would yield the following computations: 2435 round5 ( qs * qt * qc * ql * qf * qa ) = Q 2436 --- --- --- --- --- --- 2437 paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000 2438 paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 * 1.0 = 0.35000 2439 paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 * 1.0 = 0.80000 2441 18.2 Determining the result 2443 Using all computed overall quality values, the end result of the 2444 local variant selection algorithm is determined as follows. 2446 If all overall quality values are 0, then the best variant is 2447 the fallback variant, if there is one in the list, else the 2448 result is the conclusion that none of the variants are 2449 acceptable. 2451 If at least one overall quality value is greater than 0, then the 2452 best variant is the variant which has the description with the 2453 highest overall quality value, or, if there are multiple variant 2454 descriptions which share the highest overall quality value, the 2455 variant of the first variant description in the list which has this 2456 highest overall quality value. 2458 18.3 Ranking dimensions 2460 Consider the following variant list: 2462 {"paper.greek" 1.0 {language el} {charset ISO-8859-7}}, 2463 {"paper.english" 1.0 {language en} {charset ISO-8859-1}} 2465 It could be the case that the user prefers the language "el" over 2466 "en", while the user agent can render "ISO-8859-1" better than 2467 "ISO-8859-7". The result is that in the language dimension, the 2468 first variant is best, while the second variant is best in the 2469 charset dimension. In this situation, it would be preferable to 2470 choose the first variant as the best variant: the user settings in 2471 the language dimension should take precedence over the hard-coded 2472 values in the charset dimension. 2474 To express this ranking between dimensions, the user agent 2475 configuration database should have a higher spread in the quality 2476 values for the language dimension than for the charset dimension. 2477 For example, with 2479 languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ... 2481 charsets: ISO-8859-1;q=1.0, ISO-8859-7;q=0.95, 2482 ISO-8859-5;q=0.97, unicode-1-1;q=0, ... 2484 the first variant will have an overall quality of 0.95000, while 2485 the second variant will have an overall quality 0.70000. This 2486 makes the first variant the best variant. 2488 19 Appendix: feature negotiation examples 2490 This appendix contains examples of the use of feature tags in 2491 variant descriptions. The tag names used here are examples only, 2492 they do not in general reflect the tag naming scheme proposed in 2493 [4]. 2495 19.1 Use of feature tags 2497 Feature tags can be used in variant lists to express the quality 2498 degradation associated with the presence or absence of certain 2499 features. One example is 2501 {"index.html.plain" 0.7 }, 2502 {"index.html" 1.0 {features tables frames}} 2504 Here, the "{features tables frames}" part expresses that index.html 2505 uses the features tagged as tables and frames. If these features 2506 are absent, the overall quality of index.html degrades to 0. 2507 Another example is 2509 {"home.graphics" 1.0 {features !textonly}}, 2510 {"home.textonly" 0.7 } 2512 where the "{features !textonly}" part expresses that home.graphics 2513 requires the absence of the textonly feature. If the feature is 2514 present, the overall quality of home.graphics degrades to 0. 2516 The absence of a feature need not always degrade the overall quality 2517 to 0. In the example 2519 {"x.html.1" 1.0 {features fonts/0.7}} 2521 the absence of the fonts feature degrades the quality with a factor 2522 of 0.7. "fonts/0.7" can be pronounced as "fonts, or a degradation 2523 of 0.7". Finally, in the example 2525 {"y.html" 1.0 {features [blebber wolx] }} 2527 The "[blebber wolx]" expresses that y.html requires the presence of 2528 the blebber feature or the wolx feature. This construct can be 2529 used in a number of cases: 2531 1. blebber and wolx actually tag the same feature, but they were 2532 registered by different people, and some user agents say they 2533 support blebber while others say they support wolx. 2535 2. blebber and wolx are HTML tags of different vendors which 2536 implement the same functionality, and which are used 2537 together in y.html without interference. 2539 3. blebber and wolx are HTML tags of different vendors which 2540 implement the same functionality, and y.html uses the tags in 2541 a conditional HTML construct. 2543 4. blebber is a complicated HTML tag with only a sketchy 2544 definition, implemented by one user agent vendor, and wolx 2545 indicates implementation of a well-defined subset of the 2546 blebber tag by some other vendor(s). y.html uses only this 2547 well-defined subset. 2549 19.2 Use of numeric feature tags 2551 As an example of negotiation in a numeric area, the following 2552 variant list describes four variants with title graphics designed 2553 for increasing screen widths: 2555 {"home.pda" 1.0 {features screenwidth=[-199] }}, 2556 {"home.narrow" 1.0 {features screenwidth=[200-599] }}, 2557 {"home.normal" 1.0 {features screenwidth=[600-999] }}, 2558 {"home.wide" 1.0 {features screenwidth=[1000-] }}, 2559 {"home.normal"} 2561 The last element of the list specifies a safe default for user 2562 agents which do not implement screen width negotiation. Such user 2563 agents will reject the first four variants as unusable, as they 2564 seem to rely on a feature which they do not understand. 2566 19.3 Feature tag design 2568 When designing a new feature tag, it is important to take into 2569 account that existing user agents, which do not recognize the new 2570 tag will treat the feature as absent. In general, a new feature 2571 tag needs to be designed in such a way that absence of the tag is 2572 the default case which reflects current practice. If this design 2573 principle is ignored, the resulting feature tag will generally be 2574 unusable. 2576 As an example, one could try to support negotiation between 2577 monochrome and color content by introducing a `color' feature tag, 2578 the presence of which would indicate the capability to display 2579 color graphics. However, if this new tag is used in a variant 2580 list, for example 2582 {"rainbow.gif" 1.0 {features color} } 2583 {"rainbow.mono.gif" 0.6 {features !color}} 2585 then existing user agents, which would not recognize the color tag, 2586 would all display the monochrome rainbow. The color tag is 2587 therefore unusable in situations where optimal results for existing 2588 user agents are desired. To provide for negotiation in this area, 2589 one must introduce a `monochrome' feature tag; its presence 2590 indicates that the user agent can only render (or the user prefers 2591 to view) monochrome graphics. 2593 20 Appendix: origin server implementation considerations 2595 20.1 Implementation with a CGI script 2597 Transparent content negotiation has been designed to allow a broad 2598 range of implementation options at the origin server side. A very 2599 minimal implementation can be done using the CGI interface. The 2600 CGI script below is an example. 2602 #!/bin/sh 2604 cat - <<'blex' 2605 TCN: list 2606 Alternates: {"stats.tables.html" 1.0 {type text/html} {features 2607 tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95 2608 {type application/postscript}} 2609 Vary: * 2610 Content-Type: text/html 2612 <title>Multiple Choices for Web Statistics 2613

Multiple Choices for Web Statistics:

2614 2621 blex 2623 The Alternates header in the above script must be read as a single 2624 line. The script always generates a list response with the 200 2625 (OK) code, which ensures compatibility with non-negotiating 2626 HTTP/1.0 agents. 2628 20.2 Direct support by HTTP servers 2630 Sophisticated HTTP servers could make a transparent negotiation 2631 module available to content authors. Such a module could 2632 incorporate a remote variant selection algorithm and an 2633 implementation of the algorithm for generating choice responses 2634 (section 10.2). The definition of interfaces to such modules is 2635 beyond the scope of this specification. 2637 20.3 Web publishing tools 2639 Web publishing tools could automatically generate several variants 2640 of a document (for example the original TeX version, a HTML version 2641 with tables, a HTML version without tables, and a Postscript 2642 version), together with an appropriate variant list in the 2643 interface format of a HTTP server transparent negotiation module. 2644 This would allow documents to be published as transparently 2645 negotiable resources. 2647 21 Appendix: Example of choice response construction 2649 The following is an example of the construction of a choice 2650 response by a proxy cache which supports HTTP/1.1 and transparent 2651 content negotiation. The use of the HTTP/1.1 conditional request 2652 mechanisms is also shown. 2654 Assume that a user agent has cached a variant list with the 2655 validator "1234" for the negotiable resource http://x.org/paper. 2656 Also assume that it has cached responses from two neighboring 2657 variants, with the entity tags "gonkyyyy" and W/"a;b". Assume that 2658 all three user agent cache entries are stale: they would need to be 2659 revalidated before the user agent can use them. If 2660 http://x.org/paper accessed in this situation, the user agent could 2661 send the following request to its proxy cache: 2663 GET /paper HTTP/1.1 2664 Host: x.org 2665 User-Agent: WuxtaWeb/2.4 2666 Negotiate: 1.0 2667 Accept: text/html, application/postscript;q=0.4, */* 2668 Accept-Language: en 2669 If-None-Match: "gonkyyyy;1234", W/"a;b;1234" 2671 Assume that the proxy cache has cached the same three items as the 2672 user agent, but that it has revalidated the variant list 8000 2673 seconds ago, so that the list is still fresh for the proxy. This 2674 means that the proxy can run a remote variant selection algorithm 2675 on the list and the incoming request. 2677 Assume that the remote algorithm is able to choose paper.en.html as 2678 the best variant. The proxy can now construct a choice response, 2679 using the algorithm in section 10.2. In steps 1 and 2 of the 2680 algorithm, the proxy can construct the following conditional 2681 request on the best variant, and send it to the origin server: 2683 GET /paper.html.en HTTP/1.1 2684 Host: x.org 2685 User-Agent: WuxtaWeb/2.4 2686 Negotiate: 1.0 2687 Accept: text/html, application/postscript;q=0.4, */* 2688 Accept-Language: en 2689 If-None-Match: "gonkyyyy", W/"a;b" 2690 Via: 1.1 fred 2692 On receipt of the response 2694 HTTP/1.1 304 Not Modified 2695 Date: Tue, 11 Jun 1996 20:05:31 GMT 2696 Etag: "gonkyyyy" 2698 from the origin server, the proxy can use its freshly revalidated 2699 paper.html.en cache entry to expand the response to a non-304 2700 response: 2702 HTTP/1.1 200 OK 2703 Date: Tue, 11 Jun 1996 20:05:31 GMT 2704 Content-Type: text/html 2705 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 2706 Content-Length: 5327 2707 Cache-control: max-age=604800 2708 Etag: "gonkyyyy" 2709 Via: 1.1 fred 2710 Age: 0 2712 A paper about .... 2714 Using this 200 response, the proxy can construct a choice response 2715 in step 4 of the algorithm: 2717 HTTP/1.1 200 OK 2718 Date: Tue, 11 Jun 1996 20:05:31 GMT 2719 TCN: choice 2720 Content-Type: text/html 2721 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 2722 Content-Length: 5327 2723 Cache-control: max-age=604800 2724 Content-Location: paper.html.en 2725 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 2726 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 2727 {"paper.ps.en" 1.0 {type application/postscript} 2728 {language en}} 2729 Etag: "gonkyyyy;1234" 2730 Vary: negotiate, accept, accept-language 2731 Expires: Thu, 01 Jan 1980 00:00:00 GMT 2732 Via: 1.1 fred 2733 Age: 8000 2735 <title>A paper about .... 2737 The choice response can subsequently be shortened to a 304 2738 response, because of the If-None-Match header in the original 2739 request from the user agent. Thus, the proxy can finally return 2741 HTTP/1.1 304 Not Modified 2742 Date: Tue, 11 Jun 1996 20:05:31 GMT 2743 Etag: "gonkyyyy;1234" 2744 Content-Location: paper.html.en 2745 Vary: negotiate, accept, accept-language 2746 Expires: Thu, 01 Jan 1980 00:00:00 GMT 2747 Via: 1.1 fred 2748 Age: 8000 2750 to the user agent. 2752 Expires: January 26, 1998