idnits 2.17.1 draft-ietf-http-negotiation-01.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 2450 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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 787: '..., for example), but MUST NOT engage in...' RFC 2119 keyword, line 813: '...he following table SHOULD be used as a...' RFC 2119 keyword, line 827: '...ity values, content providers MUST NOT...' RFC 2119 keyword, line 831: '...per application) SHOULD be accounted f...' RFC 2119 keyword, line 838: '... in [1], except for any charset information, which MUST be carried...' (85 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 9, 1997) is 9910 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-00 ** Downref: Normative reference to an Historic draft: draft-ietf-http-rvsa-v10 (ref. '5') Summary: 13 errors (**), 0 flaws (~~), 5 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: September 9, 1997 March 9, 1997 5 Transparent Content Negotiation in HTTP 7 draft-ietf-http-negotiation-01.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 a mechanism, layered on top of HTTP, for 46 automatically selecting the best version when the URL is 47 accessed. This enables the smooth deployment of new web data 48 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 three 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. Standards 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 Standards track. 72 3. draft-ietf-http-feature-reg-XX.txt 74 `Feature Tag Registration Procedures' 76 Defines feature tag registration. Best Current Practice track. 78 An additional document about `the core feature set', which may 79 later become an informational RFC, may also appear. Currently, 80 there are two internet drafts which discuss parts of what could be 81 a core feature set: draft-mutz-http-attributes-XX.txt and 82 draft-goland-http-headers-XX.txt 84 Older versions of the text in documents 1 and 2 may be found in the 85 draft-holtman-http-negotiation-XX.txt series of internet drafts. 87 TABLE OF CONTENTS 89 1 Introduction 90 1.1 Background 91 1.2 Revision history 93 2 Terminology 94 2.1 Terms from HTTP/1.1 95 2.2 New terms 97 3 Notation 99 4 Overview 100 4.1 Content negotiation 101 4.2 HTTP/1.0 style negotiation scheme 102 4.3 Transparent content negotiation scheme 103 4.4 Optimizing the negotiation process 104 4.5 Downwards compatibility with non-negotiating user agents 105 4.6 Retrieving a variant by hand 106 4.7 Dimensions of negotiation 107 4.8 Feature negotiation 109 5 Variant descriptions 110 5.1 Syntax 111 5.2 URI 112 5.3 Source-quality 113 5.4 Type, charset, language, and length 114 5.5 Features 115 5.6 Description 116 5.7 Extension-attribute 118 6 Feature negotiation 119 6.1 Feature tags 120 6.2 Accept-Features header 121 6.3 Feature predicates 122 6.4 Features attribute 124 7 Remote variant selection algorithms 125 7.1 Version numbers 127 8 Content negotiation status codes and headers 128 8.1 506 Variant Also Negotiates 129 8.2 Accept-Charset 130 8.3 Accept-Features 131 8.4 Alternates 132 8.5 Content-Features 133 8.6 Negotiate 134 8.7 TCN 135 8.8 Variant-Vary 137 9 Cache validators 138 9.1 Variant list validators 139 9.2 Structured entity tags 140 9.3 Assigning entity tags to variants 142 10 Content negotiation responses 143 10.1 List response 144 10.2 Choice response 145 10.3 Ad hoc response 146 10.4 Reusing the Alternates header 147 10.5 Extracting a normal response from a choice response 148 10.6 Elaborate Vary headers 149 10.6.1 Construction of an elaborate Vary header 150 10.6.2 Caching of an elaborate Vary header 151 10.7 Adding an Expires header to ensure HTTP/1.0 compatibility 152 10.8 Negotiation on content encoding 154 11 User agent support for transparent negotiation 155 11.1 Handling of responses 156 11.2 Presentation of a transparently negotiated resource 158 12 Origin server support for transparent negotiation 159 12.1 Requirements 160 12.2 Negotiation on transactions other than GET and HEAD 162 13 Proxy support for transparent negotiation 164 14 Security and privacy considerations 165 14.1 Accept- headers revealing information of a private nature 166 14.2 Spoofing of responses from variant resources 168 15 Acknowledgments 170 16 References 172 17 Authors' addresses 174 18 Appendix: feature negotiation examples 175 18.1 Use of feature tags 176 18.2 Use of numeric feature tags 177 18.3 Feature tag design 179 19 Appendix: origin server implementation considerations 180 19.1 Implementation with a CGI script 181 19.2 Direct support by HTTP servers 182 19.3 Web publishing tools 184 20 Appendix: Example of choice response construction 186 1 Introduction 188 HTTP allows web site authors to put multiple versions of the same 189 information under a single URI. Each of these versions is called a 190 `variant'. Transparent content negotiation is a mechanism for 191 automatically and efficiently retrieving the best variant when a 192 GET or HEAD request is made. This enables the smooth deployment of 193 new web data formats and markup tags. 195 This specification defines transparent content negotiation as an 196 extension on top of the HTTP/1.1 protocol [1]. However, use of 197 this extension does not require use of HTTP/1.1: transparent 198 content negotiation can also be done if some or all of the parties 199 are HTTP/1.0 [3] systems. 201 Transparent content negotiation is called `transparent' because it 202 makes all variants which exist inside the origin server visible to 203 outside parties. 205 Note: Though this specification is limited to negotiation on 206 HTTP transactions, elements of this specification could also be 207 used in other contexts. For example, feature predicates could 208 be used in conditional HTML, and variant descriptions could be 209 used in multipart mail messages. Such use in other contexts is 210 encouraged. 212 1.1 Background 214 The addition of content negotiation to the web infrastructure has 215 been considered important since the early days of the web. Among 216 the expected benefits of a sufficiently powerful system for content 217 negotiation are 219 * smooth deployment of new data formats and markup tags will 220 allow graceful evolution of the web 222 * eliminating the need to choose between a `state of the art 223 multimedia homepage' and one which can be viewed by all web 224 users 226 * enabling good service to a wider range of browsing 227 platforms (from low-end PDA's to high-end VR setups) 229 * eliminating error-prone and cache-unfriendly 230 User-Agent based negotiation 232 * enabling construction of sites without `click here for the X 233 version' links 235 * internationalization, and the ability to offer multi-lingual 236 content without a bias towards one language. 238 1.2 Revision history 240 Major semantical changes are: 242 - The TCN header has been introduced to reduce the requirements 243 in section 10 on the use of existing HTTP/1.1 headers and the 244 Alternates header. This reduction in requirements should make 245 it easier to use these headers in other negotiation schemes. 247 - The requirement that proxies filter out illegal choice 248 responses has been removed. 250 Many small errors have been corrected, and some existing text has 251 been improved. 253 2 Terminology 255 2.1 Terms from HTTP/1.1 257 This specification mostly uses the terminology of the HTTP/1.1 258 specification [1]. The definitions below were reproduced from [1]. 260 request 261 An HTTP request message. 263 response 264 An HTTP response message. 266 resource 267 A network data object or service that can be identified by a URI. 268 Resources may be available in multiple representations 269 (e.g. multiple languages, data formats, size, resolutions) or 270 vary in other ways. 272 content negotiation 273 The mechanism for selecting the appropriate representation when 274 servicing a request. 276 variant 277 A resource may have one, or more than one, representation(s) 278 associated with it at any given instant. Each of these 279 representations is termed a `variant.' Use of the term `variant' 280 does not necessarily imply that the resource is subject to 281 content negotiation. 283 client 284 A program that establishes connections for the purpose of sending 285 requests. 287 user agent 288 The client which initiates a request. These are often browsers, 289 editors, spiders (web-traversing robots), or other end user 290 tools. 292 server 293 An application program that accepts connections in order to 294 service requests by sending back responses. Any given program may 295 be capable of being both a client and a server; our use of these 296 terms refers only to the role being performed by the program for 297 a particular connection, rather than to the program's 298 capabilities in general. Likewise, any server may act as an 299 origin server, proxy, gateway, or tunnel, switching behavior 300 based on the nature of each request. 302 origin server 303 The server on which a given resource resides or is to be created. 305 proxy 306 An intermediary program which acts as both a server and a client 307 for the purpose of making requests on behalf of other 308 clients. Requests are serviced internally or by passing them on, 309 with possible translation, to other servers. A proxy must 310 implement both the client and server requirements of this 311 specification. 313 age 314 The age of a response is the time since it was sent by, or 315 successfully validated with, the origin server. 317 fresh 318 A response is fresh if its age has not yet exceeded its freshness 319 lifetime. 321 2.2 New terms 323 transparently negotiable resource 324 A resource, identified by a single URI, which has multiple 325 representations (variants) associated with it. When servicing a 326 request on its URI, it allows selection of the best 327 representation using the transparent content negotiation 328 mechanism. A transparently negotiable resource always has a 329 variant list bound to it, which can be represented as an 330 Alternates header. 332 variant list 333 A list containing variant descriptions, which can be bound to a 334 transparently negotiable resource. 336 variant description 337 A machine-readable description of a variant resource, usually 338 found in a variant list. A variant description contains the 339 variant resource URI and various attributes which describe 340 properties of the variant. Variant descriptions are defined in 341 section 5. 343 variant resource 344 A resource from which a variant of a negotiable resource can be 345 retrieved with a simple GET request. 347 neighboring variant 348 A variant resource is called a neighboring variant resource of 349 some transparently negotiable HTTP resource if the variant 350 resource has a HTTP URL, and if the absolute URL of the variant 351 resource up to its last slash equals the absolute URL of the 352 negotiable resource up to its last slash, where equality is 353 determined with the URI comparison rules in section 3.2.3 of [1]. 354 The property of being a neighboring variant is important because 355 of security considerations (section 14.2). Not all variants of a 356 negotiable resource need to be neighboring variants. However, 357 access to neighboring variants can be more highly optimized by 358 the use of remote variant selection algorithms (section 7) and 359 choice responses (section 10.2). 361 remote variant selection algorithm 362 A standardized algorithm by which a server can sometimes choose a 363 best variant on behalf of a negotiating user agent. The 364 algorithm typically computes whether the Accept- headers in the 365 request contain sufficient information to allow a choice, and if 366 so, which variant is the best variant. The use of a remote 367 algorithm can speed up the negotiation process. 369 list response 370 A list response contains the variant list of the negotiable 371 resource, but no variant data. It is generated when the server 372 does not (perhaps cannot) choose a particular best variant for the 373 request. List responses are defined in section 10.1. 375 choice response 376 A choice response contains both the variant list of the 377 negotiable resource and a representation of the best variant for 378 the request. It can be generated when the server has sufficient 379 information to be able to choose the best variant on behalf the 380 user agent, but may only be generated if this best variant is a 381 neighboring variant. Choice responses are defined in section 382 10.2. 384 ad hoc response 385 An ad hoc response contains the variant list of the negotiable 386 resource, and any other data the origin server wants to send. It 387 can be generated as a response to a non-negotiating user agent if 388 the server does not (perhaps cannot) choose any particular 389 variant. Ad hoc responses are defined in section 10.3. 391 Accept- headers 392 The request headers: Accept, Accept-Charset, Accept-Language, and 393 Accept-Features. 395 supports transparent content negotiation 396 From the viewpoint of an origin server or proxy, a user agent 397 supports transparent content negotiation if and only if it sends 398 a Negotiate header (section 8.6) which indicates such support. 400 3 Notation 402 The version of BNF used in this document is taken from [1], and 403 many of the nonterminals used are defined in [1]. 405 One new BNF construct is added: 407 1%rule 409 stands for one or more instances of "rule", separated by 410 whitespace: 412 1%rule = rule *( 1*LWS rule ) 414 This specification also introduces 416 number = 1*DIGIT 418 short-float = 1*3DIGIT [ "." 0*3DIGIT ] 420 This specification uses the same conventions as in [1] (see section 421 1.2 of [1]) for defining the significance of each particular 422 requirement. 424 4 Overview 426 This section gives an overview of transparent content negotiation. 427 It starts with a more general discussion of negotiation as provided 428 by HTTP. 430 4.1 Content negotiation 432 HTTP/1.1 allows web site authors to put multiple versions of the 433 same information under a single resource URI. Each of these 434 versions is called a `variant'. For example, a resource 435 http://x.org/paper could bind to three different variants of a 436 paper: 438 1. HTML, English 439 2. HTML, French 440 3. Postscript, English 442 Content negotiation is the process by which the best variant is 443 selected if the resource is accessed. The selection is done by 444 matching the properties of the available variants to the 445 capabilities of the user agent and the preferences of the user. 447 It has always been possible under HTTP to have multiple 448 representations available for one resource, and to return the most 449 appropriate representation for each subsequent request. However, 450 HTTP/1.1 is the first version of HTTP which has provisions for 451 doing this in a cache-friendly way. These provisions include the 452 Vary response header, entity tags, and the If-None-Match request 453 header. 455 4.2 HTTP/1.0 style negotiation scheme 457 The HTTP/1.0 protocol elements allow for a negotiation scheme as 458 follows: 460 Server _____ proxy _____ proxy _____ user 461 x.org cache cache agent 463 < ---------------------------------- 464 | GET http://x.org/paper 465 | Accept- headers 466 choose 467 | 468 ---------------------------------- > 469 Best variant 471 When the resource is accessed, the user agent sends (along with its 472 request) various Accept- headers which express the user agent 473 capabilities and the user preferences. Then the origin server uses 474 these Accept- headers to choose the best variant, which is returned 475 in the response. 477 The biggest problem with this scheme is that it does not scale 478 well. For all but the most minimal user agents, Accept- headers 479 expressing all capabilities and preferences would be very large, 480 and sending them in every request would be hugely inefficient, in 481 particular because only a small fraction of the resources on the 482 web have multiple variants. 484 4.3 Transparent content negotiation scheme 486 The transparent content negotiation scheme eliminates the need to 487 send huge Accept- headers, and nevertheless allows for a selection 488 process that always yields either the best variant, or an error 489 message indicating that user agent is not capable of displaying any 490 of the available variants. 492 Under the transparent content negotiation scheme, the server sends 493 a list with the available variants and their properties to the user 494 agent. An example of a list with three variants is 496 {"paper.html.en" 0.9 {type text/html} {language en}}, 497 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 498 {"paper.ps.en" 1.0 {type application/postscript} {language en}} 500 The syntax and semantics of the variant descriptions in this list 501 are covered in section 5. When the list is received, the user 502 agent can choose the best variant and retrieve it. Graphically, 503 the communication can be represented as follows: 505 Server _____ proxy _____ proxy _____ user 506 x.org cache cache agent 508 < ---------------------------------- 509 | GET http://x.org/paper 510 | 511 ----------------------------------- > [list response] 512 return of list | 513 choose 514 | 515 < ---------------------------------- 516 | GET http://x.org/paper.html.en 517 | 518 ---------------------------------- > [normal response] 519 return of html.en 521 The first response returning the list of variants is called a `list 522 response'. The second response is a normal HTTP response: it does 523 not contain special content negotiation related information. Only 524 the user agent needs to know that the second request actually 525 retrieves a variant. For the other parties in the communication, 526 the second transaction is indistinguishable from a normal HTTP 527 transaction. 529 With this scheme, information about capabilities and preferences is 530 only used by the user agent itself. Therefore, sending such 531 information in large Accept- headers is unnecessary. Accept- 532 headers do have a limited use in transparent content negotiation 533 however; the sending of small Accept- headers can often speed up the 534 negotiation process. This is covered in section 4.4. 536 List responses are covered in section 10.1. As an example, the 537 list response in the above picture could be: 539 HTTP/1.1 300 Multiple Choices 540 Date: Tue, 11 Jun 1996 20:02:21 GMT 541 TCN: list 542 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 543 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 544 {"paper.ps.en" 1.0 {type application/postscript} 545 {language en}} 546 Vary: negotiate, accept, accept-language 547 ETag: "blah;1234" 548 Cache-control: max-age=86400 549 Content-Type: text/html 550 Content-Length: 227 552

Multiple Choices:

553 559 The Alternates header in the response contains the variant list. 560 The Vary header is included to ensure correct caching by plain 561 HTTP/1.1 caches (see section 10.6). The ETag header allows the 562 response to be revalidated by caches, the Cache-Control header 563 controls this revalidation. The HTML entity included in the 564 response allows the user to select the best variant by hand if 565 desired. 567 4.4 Optimizing the negotiation process 569 The basic transparent negotiation scheme involves two HTTP 570 transactions: one to retrieve the list, and a second one to retrieve 571 the chosen variant. There are however several ways to `cut corners' 572 in the data flow path of the basic scheme. 574 First, caching proxies can cache both variant lists and variants. 575 Such caching can reduce the communication overhead, as shown in the 576 following example: 578 Server _____ proxy _____ proxy __________ user 579 x.org cache cache agent 581 < -------------- 582 | GET ../paper 583 | 584 has the list 585 in cache 586 | 587 ------------- > [list response] 588 list | 589 | 590 choose 591 | 592 < -------------------------- 593 | GET ../paper.html.en 594 | 595 has the variant 596 in cache 597 | 598 -------------------------- > [normal response] 599 return of html.en 601 Second, the user agent can send small Accept- headers, which may 602 contain enough information to allow the server to choose the best 603 variant and return it directly. 605 Server _____ proxy _____ proxy _____ user 606 x.org cache cache agent 608 < ---------------------------------- 609 | GET http://x.org/paper 610 | small Accept- headers 611 | 612 able to choose on 613 behalf of user agent 614 | 615 ---------------------------------- > [choice response] 616 return of html.en and list 618 This choosing based on small Accept- headers is done with a `remote 619 variant selection algorithm'. Such an algorithm takes the variant 620 list and the Accept- headers as input. It then computes whether the 621 Accept- headers contain sufficient information to choose on behalf 622 of the user agent, and if so, which variant is the best variant. 623 If the best variant is a neighboring variant, it may be returned, 624 together with the variant list, in a choice response. 626 A server may only choose on behalf of a user agent supporting 627 transparent content negotiation if the user agent explicitly allows 628 the use of a particular remote variant selection algorithm in the 629 Negotiate request header. User agents with sophisticated internal 630 variant selection algorithms may want to disallow a remote choice, 631 or may want to allow it only when retrieving inline images. If the 632 local algorithm of the user agent is superior in only some 633 difficult areas of negotiation, it is possible to enable the remote 634 algorithm for the easy areas only. More information about the use 635 of a remote variant selection algorithm can be found in [5]. 637 Choice responses are covered in section 10.2. For example, the 638 choice response in the above picture could be: 640 HTTP/1.1 200 OK 641 Date: Tue, 11 Jun 1996 20:05:31 GMT 642 TCN: choice 643 Content-Type: text/html 644 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 645 Content-Length: 5327 646 Cache-control: max-age=604800 647 Content-Location: paper.html.en 648 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 649 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 650 {"paper.ps.en" 1.0 {type application/postscript} 651 {language en}} 652 Etag: "gonkyyyy;1234" 653 Vary: negotiate, accept, accept-language 654 Expires: Thu, 01 Jan 1980 00:00:00 GMT 656 A paper about .... 658 Finally, the above two kinds of optimization can be combined; a 659 caching proxy which has the list will sometimes be able to choose on 660 behalf of the user agent. This could lead to the following 661 communication pattern: 663 Server _____ proxy _____ proxy __________ user 664 x.org cache cache agent 666 < --------------- 667 | GET ../paper 668 | small Accept 669 | 670 able to choose 671 on behalf 672 | 673 < ---------- 674 | GET ../paper.html.en 675 | 676 ---------- > [normal response] 677 html.en | 678 ---------------- > [choice response] 679 html.en and list 681 Note that this cutting of corners not only saves bandwidth, it also 682 eliminates delays due to packet round trip times, and reduces the 683 load on the origin server. 685 4.5 Downwards compatibility with non-negotiating user agents 687 To handle requests from user agents which do not support 688 transparent content negotiation, this specification allows the 689 origin server to revert to a HTTP/1.0 style negotiation scheme. 690 The specification of heuristics for such schemes is beyond the 691 scope of this document. 693 4.6 Retrieving a variant by hand 695 If a transparently negotiated resource is accessed, the user agent 696 will always at some point receive the list of available variants. 697 The user agent can use this list to make available a menu of all 698 variants and their characteristics to the user. Such a menu allows 699 the user to randomly browse other variants, and makes it possible 700 to manually correct any sub-optimal choice made by the automatic 701 negotiation process. 703 4.7 Dimensions of negotiation 705 Transparent content negotiation defines four dimensions of 706 negotiation: 708 1. Media type (MIME type) 709 2. Charset 710 3. Language 711 4. Features 713 The first three dimensions have traditionally been present in HTTP. 714 The fourth dimension is added by this specification. Additional 715 dimensions, beyond the four mentioned above, could be added by 716 future specifications. 718 Negotiation on the content encoding of a response (gzipped, 719 compressed, etc.) is left outside of the realm of transparent 720 negotiation. See section 10.8 for more information. 722 4.8 Feature negotiation 724 Feature negotiation intends to provide for all areas of negotiation 725 not covered by the type, charset, and language dimensions. 726 Examples are negotiation on 728 * HTML extensions 729 * Extensions of other media types 730 * Color capabilities of the user agent 731 * Screen size 732 * Output medium (screen, paper, ...) 733 * Preference for speed vs. preference for graphical detail 735 The feature negotiation framework (section 6) is the principal 736 means by which transparent negotiation offers extensibility; a new 737 dimension of negotiation (really a sub-dimension of the feature 738 dimension) can be added without the need for a new standards effort 739 by the simple registration of a `feature tag'. Feature tag 740 registration is discussed in [4]. 742 5 Variant descriptions 744 5.1 Syntax 746 A variant can be described in a machine-readable way with a variant 747 description. 749 variant-description = 750 "{" <"> URI <"> source-quality *variant-attribute"}" 752 source-quality = qvalue 754 variant-attribute = "{" "type" media-type "}" 755 | "{" "charset" charset "}" 756 | "{" "language" 1#language-tag "}" 757 | "{" "length" 1*DIGIT "}" 758 | "{" "features" feature-list "}" 759 | "{" "description" quoted-string "}" 760 | extension-attribute 762 extension-attribute = "{" extension-name extension-value "}" 763 extension-name = token 764 extension-value = *( token | quoted-string | LWS 765 | extension-specials ) 767 extension-specials = 768 <any element of tspecials except <"> and "}"> 770 Examples are 772 {"paper.html.fr" 0.7 {type text/html} {language fr}} 774 {"paper.html.tables" 0.9 {type text/html} {features tables}} 776 {"paper.html.en"} 778 The various attributes which can be present in a variant 779 description are covered in the subsections below. Each attribute 780 may appear only once in a variant description. 782 5.2 URI 784 The URI attribute gives the URI of the resource from which the 785 variant can be retrieved with a GET request. It can be absolute or 786 relative to the Request-URI. The variant resource may vary (on the 787 Cookie request header, for example), but MUST NOT engage in 788 transparent content negotiation itself. 790 5.3 Source-quality 792 The source-quality attribute gives the quality of the variant, as a 793 representation of the negotiable resource, when this variant is 794 rendered with a perfect rendering engine on the best possible 795 output medium. 797 If the source-quality is less than 1, it often expresses a quality 798 degradation caused by a lossy conversion to a particular data 799 format. For example, a picture originally in JPEG form would have 800 a lower source quality when translated to the XBM format, and a 801 much lower source quality when translated to an ASCII-art variant. 802 Note however, that degradation is a function of the source; an 803 original piece of ASCII-art may degrade in quality if it is 804 captured in JPEG form. 806 The source-quality could also represent a level of quality caused 807 by skill of language translation, or ability of the used media type 808 to capture the intended artistic expression. 810 It is important that content providers do not assign very low 811 source quality values without good reason, as this would limit the 812 ability of users to influence the negotiation process with their 813 own preference settings. The following table SHOULD be used as a 814 guide when assigning source quality values: 816 1.000 perfect representation 817 0.900 threshold of noticeable loss of quality 818 0.800 noticeable, but acceptable quality reduction 819 0.500 barely acceptable quality 820 0.300 severely degraded quality 821 0.000 completely degraded quality 823 Note that most meaningful values in this table are close to 1. 824 This is due to the fact that quality factors are generally combined 825 by multiplying them, not by adding them. 827 When assigning source-quality values, content providers MUST NOT 828 account for the size of the variant and its impact on transmission 829 and rendering delays. Any constant rendering delay for a 830 particular media type (for example due to the startup time of a 831 helper application) SHOULD be accounted for by the user agent, when 832 assigning a quality factor to that media type. 834 5.4 Type, charset, language, and length 836 The type attribute of a variant description carries the same 837 information as its Content-Type response header counterpart defined 838 in [1], except for any charset information, which MUST be carried 839 in the charset attribute. For, example, the header 841 Content-Type: text/html; charset=ISO-8859-4 843 has the counterpart attributes 845 {type text/html} {charset ISO-8859-4} 847 The language and length attributes carry the same information as 848 their Content-* response header counterparts in [1]. The length 849 attribute, if present, MUST thus reflect the length of the variant 850 alone, and not the total size of the variant and any objects 851 inlined or embedded by the variant. 853 Though all of these attributes are optional, it is often desirable 854 to include as many attributes as possible, as this will increase 855 the quality of the negotiation process. 857 Note: A server is not required to maintain a one-to-one 858 correspondence between the attributes in the variant description 859 and the Content-* headers in the variant response. For example, 860 if the variant description contains a language attribute, the 861 response does not necessarily have to contain a Content-Language 862 header. If a Content-Language header is present, it does not 863 have to contain an exact copy of the information in the language 864 attribute. 866 5.5 Features 868 The features attribute specifies how the presence or absence of 869 particular feature tags in the user agent affects the overall 870 quality of the variant. This attribute is covered in section 6.4. 872 5.6 Description 874 The description attribute gives a textual description of the 875 variant. It can be included if the URI and normal attributes of a 876 variant are considered too opaque to allow interpretation by the 877 user. If a user agent is showing a menu of available variants 878 compiled from a variant list, and if a variant has a description 879 attribute, the user agent SHOULD show the description attribute of 880 the variant instead of showing the normal attributes of the 881 variant. 883 5.7 Extension-attribute 885 The extension-attribute allows future specifications to 886 incrementally define new dimensions of negotiation, and eases 887 content negotiation experiments. In experimental situations, 888 servers MUST ONLY generate extension-attributes whose names start 889 with "x-". User agents SHOULD ignore all extension attributes they 890 do not recognize. Proxies MUST NOT run a remote variant selection 891 algorithm if an unknown extension attribute is present in the 892 variant list. 894 6 Feature negotiation 896 This section defines the feature negotiation mechanism. Feature 897 negotiation has been introduced in section 4.8. Appendix 18 898 contains examples of feature negotiation. 900 6.1 Feature tags 902 A feature tag (ftag) identifies a capability of a user agent or a 903 preference of a user. A feature is said to be `present' in a user 904 agent if the corresponding capability is implemented, or if the 905 user has expressed corresponding preference. 907 ftag = 1*<any CHAR except CTLs or tspecials or "!"> 909 tspecials = "(" | ")" | "<" | ">" | "@" 910 | "," | ";" | ":" | "\" | <"> 911 | "/" | "[" | "]" | "?" | "=" 912 | "{" | "}" | SP | HT 914 (tspecials definition reproduced from [1]) 916 Examples are 918 tables, fonts, blebber, wolx, screenwidth, colordepth 920 An example of the use of feature tags in a variant description is: 922 {"index.html" 1.0 {type text/html} {features tables frames}} 924 Feature tags are case-insensitive. The definition of a feature tag 925 may state that a feature tag, if present, can have associated with 926 it one or more values which reflect a particular capability or 927 preference. For example, a feature tag `paper' could be present 928 with the values `A4' and `A5'. 930 Note that context may determine whether a feature tag expresses a 931 capability or a preference. The `textonly' tag is naturally 932 present for a text-only user agent, but the user of a graphical 933 user agent could set the tag to be present if text-only content is 934 preferred to graphical content. 936 As feature registration [4] will be an ongoing process, it is 937 generally not possible for a user agent to know the meaning of all 938 feature tags it can possibly encounter in a variant description. A 939 user agent SHOULD treat all features with tags unknown to it as 940 absent. 942 6.2 Accept-Features header 944 The Accept-Features request header can be used by a client to give 945 information about the presence or absence of certain features. 947 Accept-Features = "Accept-Features" ":" 948 #( feature-expr *( ";" feature-extension ) ) 950 feature-expr = [ "!" ] ftag 951 | ftag [ "!" ] "=" tag-value 952 | ftag "=" "{" tag-value "}" 953 | ftag "<=" number 954 | ftag "=" "<" numeric-range ">" 955 | "*" 957 tag-value = token | quoted-string 959 numeric-range = [ number ] "-" [ number ] 961 feature-extension = token [ "=" ( token | quoted-string ) ] 963 Tag values MUST be compared case-insensitively, and a token value 964 XYZ is equal to a quoted-string value "XYZ". No feature extensions 965 are defined in this specification. An example is: 967 Accept-Features: blex, !blebber, colordepth<=5, !screenwidth, 968 UA-media={stationary}, paper = a4, paper!="a0", 969 x_version=<100-205>, * 971 The different feature expressions have the following meaning: 973 ftag ftag is present 975 !ftag ftag is absent 977 ftag=V ftag is present with the value V (it may also be 978 present with other values) 980 ftag!=V ftag is present, but not with the value V 982 ftag={V} ftag is present with the value V, and not with any 983 other values 985 ftag<=N ftag is present with the numeric values from 0 up to 986 and including N, and not with any other values 988 ftag=<N-M> ftag is present with the numeric values from N up to 989 and including M, and not with any other values. If N 990 is missing, the lower bound is 0. If M is missing, 991 the upper bound is infinity. 993 * makes true all feature predicates (section 6.3) which 994 were not assigned truth values by other elements of 995 the header 997 Absence of the Accept-Features header in a request is equivalent to 998 the inclusion of 1000 Accept-Features: * 1002 6.3 Feature predicates 1004 Feature predicates are used in the features attribute of a variant 1005 description. 1007 fpred = [ "!" ] ftag 1008 | ftag [ "!" ] "=" tag-value 1009 | ftag "=" "<" numeric-range ">" 1011 Examples of feature predicates are 1013 blebber, !blebber, paper=a4, colordepth=5, blex!=54, 1014 dpi=<300-599>, colordepth=<24-> 1016 A server can compute the truth value of a feature predicate by 1017 using the knowledge gained from the Accept-Features header in the 1018 current request. The truth value MUST be assigned as follows, 1019 depending on the form of the predicate: 1021 ftag true if the feature is known to be present 1023 false if the feature is known to be absent 1025 !ftag true if the feature is known to be absent 1027 false if the feature is known to be present 1029 ftag=V true if the feature is known to be present with 1030 the value V, 1032 false if the feature is known not to be present with 1033 the value V 1035 ftag!=V true if the feature is known to be present, but known 1036 not to be present with the value V, 1038 false if the feature is known to be absent or present 1039 with the value V 1041 ftag=<N-M> true if the feature is known to be present with some 1042 numeric values, while the highest value with which it 1043 is present is known and in the range N-M, 1045 false if the feature is known to be absent, or if it 1046 is known to be present with some numeric values, 1047 while the highest value with which it is present is 1048 known and not in the range N-M. 1050 If N is missing, the lower bound is 0. If M is 1051 missing, the upper bound is infinity. 1053 If the information in the Accept-Features header does not provide 1054 sufficient knowledge to assign a value to a predicate using the 1055 above rules, then the value is true if there is a "*" in the 1056 Accept-Features header, false otherwise. 1058 As an example, the header 1060 Accept-Features: blex, !blebber, colordepth<=5, !screenwidth, 1061 UA-media={stationary}, paper = a4, paper!="a0", 1062 x_version=<100-205>, * 1064 makes the following predicates true: 1066 blex, colordepth=4, colordepth!=6, colordepth, !screenwidth, 1067 UA-media=stationary, !UA-media=screen, paper=a4, paper =!a0, 1068 colordepth=< 4 - 6 >, x_version="101" 1070 The * in the header makes all of the following predicates true: 1072 blex=wox, blex!=wox, paper=a5, 1073 frtnbf, !frtnbf, frtnbf=4, frtnbf!=4, frtnbf=<1-42> 1075 The header makes the following predicates false: 1077 !blex, blebber, colordepth=6, colordepth=foo, !colordepth, 1078 screenwidth, screenwidth=640, screenwidth!=640, x_version=99, 1079 UA-media=screen, paper=a0 1081 6.4 Features attribute 1083 The features attribute 1085 "{" "features" feature-list "}" 1087 is used in a variant description to specify how the presence or 1088 absence of particular feature tags in the user agent affects the 1089 overall quality of the variant. 1091 feature-list = 1%feature-list-element 1093 feature-list-element = ( fpred | fpred-bag ) 1094 [ ":" true-improvement ] 1095 [ "/" false-degradation ] 1097 fpred-bag = "[" 1%fpred "]" 1099 true-improvement = short-float 1100 false-degradation = short-float 1102 Examples are: 1104 {features !textonly [blebber !wolx] colordepth=3:0.7} 1106 {features !blink/0.5 background:1.5 [blebber !wolx]:1.4/0.8} 1108 The default value for the true-improvement is 1. The default value 1109 for the false-degradation is 0, or 1 if a true-improvement value is 1110 given. 1112 A remote variant selection algorithm MUST compute the quality 1113 degradation factor associated with the features attribute by 1114 multiplying all quality degradation factors of the elements of the 1115 feature-list. Note that the result can be a factor greater than 1. 1117 A feature list element yields its true-improvement factor if the 1118 corresponding feature predicate is true, or if at least one element 1119 of the corresponding fpred-bag is true. The element yields its 1120 false-degradation factor otherwise. 1122 7 Remote variant selection algorithms 1124 A remote variant selection algorithms is a standardized algorithm 1125 by which a server can choose a best variant on behalf of a 1126 negotiating user agent. The use of a remote algorithm can speed up 1127 the negotiation process by eliminating a request-response round 1128 trip. 1130 A remote algorithm typically computes whether the Accept- headers in 1131 the request contain sufficient information to allow a choice, and 1132 if so, which variant is the best variant. This specification does 1133 not define any remote algorithms, but does define a mechanism to 1134 negotiate on the use of such algorithms. 1136 7.1 Version numbers 1138 A version numbering scheme is used to distinguish between different 1139 remote variant selection algorithms. 1141 rvsa-version = major "." minor 1143 major = 1*4DIGIT 1144 minor = 1*4DIGIT 1146 An algorithm with the version number X.Y, with Y>0, MUST be 1147 downwards compatible with all algorithms from X.0 up to X.Y. 1148 Downwards compatibility means that, if supplied with the same 1149 information, the newer algorithm MUST make the same choice, or a 1150 better choice, as the old algorithm. There are no compatibility 1151 requirements between algorithms with different major version 1152 numbers. 1154 8 Content negotiation status codes and headers 1156 This specification adds one new HTTP status code, and introduces 1157 six new HTTP headers. It also extends the semantics of an existing 1158 HTTP/1.1 header. 1160 8.1 506 Variant Also Negotiates 1162 The 506 status code indicates that the server has an internal 1163 configuration error: the chosen variant resource is configured to 1164 engage in transparent content negotiation itself, and is therefore 1165 not a proper end point in the negotiation process. 1167 8.2 Accept-Charset 1169 The Accept-Charset header is defined in the HTTP/1.1 specification 1170 [1]. HTTP/1.1 allows the following Accept-Charset header to be 1171 sent: 1173 Accept-Charset: iso-8859-5;q=0.8, *;q=0.9 1175 but HTTP/1.1 does not assign any special meaning to the charset 1176 "*". 1178 This specification does assign a special meaning: servers and 1179 clients which support transparent content negotiation MUST take "*" 1180 as a wildcard matching every character set not explicitly mentioned 1181 elsewhere in the Accept-Charset header. As an example, the above 1182 header assigns a quality value of 0.9 to the iso-8859-2 charset. 1184 If no "*" is present in an Accept-Charset header, then all 1185 character sets not explicitly mentioned get a quality factor of 0, 1186 except for ISO-8859-1, which gets a quality factor of 1 if not 1187 explicitly mentioned. 1189 Note: The omission of a wildcard from the Accept-Charset 1190 header in [1] is believed to be due to an oversight during the 1191 design of HTTP/1.1. A future revision of [1] may correct this 1192 oversight, and make this section redundant. 1194 8.3 Accept-Features 1196 This request header was defined in section 6.2. 1198 8.4 Alternates 1200 The Alternates response header is used to convey the list of 1201 variants bound to a negotiable resource. This list can also 1202 include directives for any content negotiation process. 1204 Alternates = "Alternates" ":" variant-list 1206 variant-list = 1#( variant-description 1207 | fallback-variant 1208 | list-directive ) 1210 fallback-variant = "{" <"> URI <"> "}" 1212 list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> ) 1213 | extension-list-directive 1215 extension-list-directive = token [ "=" ( token | quoted-string ) ] 1217 An example is 1219 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 1220 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 1221 {"paper.ps.en" 1.0 {type application/postscript} 1222 {language en}}, 1223 proxy-rvsa="1.0, 2.5" 1225 Any relative URI specified in a variant-description or 1226 fallback-variant field is relative to the request-URI. Only one 1227 fallback-variant field may be present. If the variant selection 1228 algorithm of the user agent finds that all described variants are 1229 unacceptable, then it SHOULD choose the fallback variant, if 1230 present, as the best variant. If the user agent computes the 1231 overall quality values of the described variants, and finds that 1232 several variants share the highest value, then the first variant 1233 with this value in the list SHOULD be chosen as the best variant. 1235 The proxy-rvsa directive restricts the use of remote variant 1236 selection algorithms by proxies. If present, a proxy MUST ONLY use 1237 algorithms which have one of the version numbers listed, or have 1238 the same major version number and a higher minor version number as 1239 one of the versions listed. Any restrictions set by proxy-rvsa 1240 come on top of the restrictions set by the user agent in the 1241 Negotiate request header. The directive proxy-rvsa="" will disable 1242 variant selection by proxies entirely. Clients SHOULD ignore all 1243 extension-list-directives they do not understand. 1245 A variant list may contain multiple differing descriptions of the 1246 same variant. This can be convenient if the variant uses 1247 conditional rendering constructs, or if the variant resource 1248 returns multiple representations using a multipart media type. 1250 8.5 Content-Features 1252 The Content-Features response header can be used by a server to 1253 indicate how the presence or absence of particular feature tags in 1254 the user agent affects the overall quality of the response. 1256 Content-Features = "Content-Features" ":" feature-list 1258 Note: This header mainly exists because of symmetry 1259 considerations. It is the counterpart of the features attribute 1260 which can be present in variant descriptions. If present in a 1261 response, the header will therefore not in general specify all 1262 user agent capabilities used by the response. 1264 8.6 Negotiate 1266 The Negotiate request header can contain directives for any content 1267 negotiation process initiated by the request. 1269 Negotiate = "Negotiate" ":" 1#negotiate-directive 1271 negotiate-directive = "trans" | rvsa-version | "*" 1272 | negotiate-extension 1274 negotiate-extension = token [ "=" token ] 1276 Examples are 1278 Negotiate: 1.0, 2.5 1279 Negotiate: * 1281 The negotiate directives have the following meaning 1283 "trans" 1284 The user agent supports transparent content negotiation for 1285 the current request. 1287 rvsa-version 1288 The user agent allows origin servers and proxies to run the 1289 remote variant selection algorithm with the indicated version 1290 number, or with the same major version number and a higher 1291 minor version number. If the algorithm has sufficient 1292 information to choose a best, neighboring variant, the origin 1293 server or proxy MAY return a choice response with this 1294 variant. Implies "trans". 1296 "*" 1297 The user agent allows origin servers and proxies to run any 1298 remote variant selection algorithm. The origin server may 1299 even run algorithms which have not been standardized. If the 1300 algorithm has sufficient information to choose a best, 1301 neighboring variant, the origin server or proxy MAY return a 1302 choice response with this variant. Implies "trans". 1304 Servers SHOULD ignore all negotiate-directives they do not 1305 understand. If the Negotiate header allows a choice between 1306 multiple remote variant selection algorithms which are all 1307 supported by the server, the server SHOULD use some internal 1308 precedence heuristics to select the best algorithm. 1310 8.7 TCN 1312 The TCN response header is used by a server to signal that the 1313 resource is transparently negotiated. 1315 TCN = "TCN" ":" #( response-type | tcn-extension ) 1317 response-type = "list" | "choice" | "adhoc" 1319 tcn-extension = token [ "=" ( token | quoted-string ) ] 1321 If the resource is not transparently negotiated, a TCN header MUST 1322 NEVER be included in any response. If the resource is 1323 transparently negotiated, a TCN header, which includes the 1324 response-type value of the response, MUST be included in every 1325 response with a 2xx status code or any 3xx status code, except 304, 1326 in which it MAY be included. A TCN header MAY also be included, 1327 without a response-type value, in other responses from 1328 transparently negotiated resources. 1330 Clients SHOULD ignore all tcn-extensions they do not understand. 1332 8.8 Variant-Vary 1334 The Variant-Vary response header can be used in a choice response 1335 to record any vary information which applies to the variant data 1336 (the entity body combined with some of the entity headers) 1337 contained in the response, rather than to the response as a whole. 1339 Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name ) 1341 Use of the Variant-Vary header is discussed in section 10.2. 1343 9 Cache validators 1345 To allow for correct and efficient caching and revalidation of 1346 negotiated responses, this specification extends the caching model 1347 of HTTP/1.1 [1] in various ways. 1349 This specification does not introduce a `variant-list-max-age' 1350 directive which explicitly bounds the freshness lifetime of a 1351 cached variant list, like the `max-age' Cache-Control directive 1352 bounds the freshness lifetime of a cached response. However, this 1353 specification does ensure that a variant list which is sent at a 1354 time T by the origin server will never be re-used without 1355 revalidation by semantically transparent caches after the time T+M. 1356 This M is the maximum of all freshness lifetimes assigned (using 1357 max-age directives or Expires headers) by the origin server to 1359 a. the responses from the negotiable resource itself, and 1361 b. the responses from its neighboring variant resources 1363 If no freshness lifetimes are assigned by the origin server, M is 1364 the maximum of the freshness lifetimes which were heuristically 1365 assigned by all caches which can re-use the variant list. 1367 9.1 Variant list validators 1369 A variant list validator is an opaque value which acts as the cache 1370 validator of a variant list bound to a negotiable resource. 1372 variant-list-validator = <quoted-string not containing any ";"> 1374 If two responses contain the same variant list validator, a cache 1375 can treat the Alternates headers in these responses as equivalent 1376 (though the headers themselves need not be identical). 1378 9.2 Structured entity tags 1380 A structured entity tag consists of a normal entity tag of which 1381 the opaque string is extended with a semicolon followed by the text 1382 (without the surrounding quotes) of a variant list validator: 1384 normal | variant list | structured 1385 entity tag | validator | entity tag 1386 -------------+----------------+----------------- 1387 "etag" | "vlv" | "etag;vlv" 1388 W/"etag" | "vlv" | W/"etag;vlv" 1390 Note that a structured entity tag is itself also an entity tag. 1391 The structured nature of the tag allows caching proxies capable of 1392 transparent content negotiation to perform some optimizations 1393 defined in section 10. When not performing such optimizations, a 1394 structured tag SHOULD be treated as a single opaque value, 1395 according to the general rules in HTTP/1.1. Examples of structured 1396 entity tags are: 1398 "xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234" 1400 In the last example, the normal entity tag is "a;b;c;" and the 1401 variant list validator is "1234". 1403 If a transparently negotiated response includes an entity tag, it 1404 MUST be a structured entity tag. The variant list validator in the 1405 structured tag MUST act as a validator for the variant list 1406 contained in the Alternates header. The normal entity tag in the 1407 structured tag MUST act as a validator of the entity body in the 1408 response and of all entity headers except Alternates. 1410 9.3 Assigning entity tags to variants 1412 To allow for correct revalidation of transparently negotiated 1413 responses by clients, origin servers SHOULD generate all normal 1414 entity tags for the neighboring variant resources of the negotiable 1415 resource in such a way that 1417 1. the same tag is never used by two different variants, 1418 unless this tag labels exactly the same entity on all 1419 occasions, 1421 2. if one normal tag "X" is a prefix of another normal tag "XY", 1422 then "Y" must never be a semicolon followed by a variant list 1423 validator. 1425 10 Content negotiation responses 1427 If a request on a transparently negotiated resource yields a 1428 response with a 2xx status code or any 3xx status code except 304, 1429 this response MUST always be either a list response, a choice 1430 response, or an ad hoc response. These responses always include 1431 the Alternates header bound to the negotiable resource, and a TCN 1432 header which specifies their type. Transparently negotiated 1433 responses with other status codes MAY also include an Alternates 1434 header. 1436 After having constructed a list, choice, or ad hoc response, a 1437 server MAY process any If-No-Match or If-Range headers in the 1438 request message and shorten the response to a 304 (Not Modified) or 1439 206 (Partial Content) response, following the rules in the HTTP/1.1 1440 specification [1]. In this case, the entity tag of the shortened 1441 response will identify it indirectly as a list, choice, or ad-hoc 1442 response. 1444 10.1 List response 1446 A list response MUST contain (besides the normal headers required 1447 by HTTP) a TCN header which specifies the "list" response-type, the 1448 Alternates header bound to the negotiable resource, a Vary header 1449 and (unless it was a HEAD request) an entity body which allows the 1450 user to manually select the best variant. It is generated as a 1451 response to a user agent which supports transparent content 1452 negotiation if the server does not, cannot, or is not allowed to 1453 choose a particular best variant for the request. 1455 An example of a list response is 1457 HTTP/1.1 300 Multiple Choices 1458 Date: Tue, 11 Jun 1996 20:02:21 GMT 1459 TCN: list 1460 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 1461 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 1462 {"paper.ps.en" 1.0 {type application/postscript} 1463 {language en}} 1464 Vary: negotiate, accept, accept-language 1465 ETag: "blah;1234" 1466 Cache-control: max-age=86400 1467 Content-Type: text/html 1468 Content-Length: 227 1470 <h2>Multiple Choices:</h2> 1471 <ul> 1472 <li><a href=paper.html.en>HTML, English version</a> 1473 <li><a href=paper.html.fr>HTML, French version</a> 1474 <li><a href=paper.ps.en>Postscript, English version</a> 1475 </ul> 1477 Note: A list response can have any status code, but the 300 1478 (Multiple Choices) code is the most appropriate one for HTTP/1.1 1479 clients. Some existing versions of HTTP/1.0 clients are known 1480 to silently ignore 300 responses, instead of handling them 1481 according to the HTTP/1.0 specification [3]. Servers should 1482 therefore be careful in sending 300 responses to non-negotiating 1483 HTTP/1.0 user agents, and in making these responses cacheable. 1484 The 200 (OK) status code can be used instead. 1486 The Vary header in the response SHOULD ensure correct handling by 1487 plain HTTP/1.1 caching proxies. This header can either be 1489 Vary: * 1491 or a more elaborate header; see section 10.6.1. 1493 Only the origin server may construct list responses. Depending on 1494 the status code, a list response is cacheable unless indicated 1495 otherwise. 1497 According to the HTTP/1.1 specification [1], a user agent which 1498 does not support transparent content negotiation will, when 1499 receiving a list response, display the entity body included in the 1500 response. If the response contains a Location header, however, the 1501 user agent MAY automatically redirect to this location. 1503 The handling of list responses by clients supporting transparent 1504 content negotiation is described in sections 11.1 and 13. 1506 10.2 Choice response 1508 A choice response merges a normal HTTP response from the chosen 1509 variant, a TCN header which specifies the "choice" response-type, a 1510 Content-Location header giving the location of the variant, and the 1511 Alternates headers bound to the negotiable resource. It can be 1512 generated when the server has sufficient information to be able to 1513 choose the best variant on behalf the user agent, but may only be 1514 generated if this best variant is a neighboring variant. Depending 1515 on the status code, a choice response is cacheable unless indicated 1516 otherwise. 1518 Origin servers and proxy caches MUST construct choice responses 1519 with the following algorithm (or any other algorithm which gives 1520 equal end results for the client). 1522 In this algorithm, `the current Alternates header' refers to the 1523 Alternates header containing the variant list which was used to 1524 choose the best variant, and `the current variant list validator' 1525 refers to the validator of this list. Section 10.4 specifies how 1526 these two items can be obtained by a proxy cache. 1528 The algorithm consists of four steps. 1530 1. Construct a HTTP request message on the best variant resource 1531 by rewriting the request-URI and Host header (if appropriate) 1532 of the received request message on the negotiable resource. 1534 2. Generate a valid HTTP response message, but not one with the 1535 304 (Not Modified) code, for the request message constructed 1536 in step 1. 1538 In a proxy cache, the response can be obtained from cache 1539 memory, or by passing the constructed HTTP request towards the 1540 origin server. If the request is passed on, the proxy MAY 1541 add, modify, or delete If-None-Match and If-Range headers to 1542 optimize the transaction with the upstream server. 1544 Note: the proxy should be careful not to add entity tags of 1545 non-neighboring variants to If-* (conditional) headers of 1546 the request, as there are no global uniqueness requirements 1547 for these tags. 1549 3. Only in origin servers: check for an origin server 1550 configuration error. If the HTTP response message generated in 1551 step 2 contains a TCN header, then the best variant resource 1552 is not a proper end point in the transparent negotiation 1553 process, and a 506 (Variant Also Negotiates) error response 1554 message SHOULD be generated instead of going to step 4. 1556 4. Add a number of headers to the HTTP response message generated 1557 in step 2. 1559 a. Add a TCN header which specifies the "choice" 1560 response-type. 1562 b. Add a Content-Location header giving the location of the 1563 chosen variant. Delete any Content-Location header which 1564 was already present. 1566 Note: According to the HTTP/1.1 specification [1], if 1567 the Content-Location header contains a relative URI, 1568 this URI is relative to the URI in the Content-Base 1569 header, if present, and relative to the request-URI if 1570 no Content-Base header is present. 1572 c. If any Vary headers are present in the response message 1573 from step 2, add, for every Vary header, a Variant-Vary 1574 header with a copy of the contents of this Vary header. 1576 d. Add the current Alternates header. Delete any 1577 Alternates header which was already present. 1579 e. Add a Vary header to ensure correct handling by plain 1580 HTTP/1.1 caching proxies. This header can either be 1582 Vary: * 1584 or a more elaborate header, see section 10.6. 1586 f. To ensure compatibility with HTTP/1.0 caching proxies which 1587 do not recognize the Vary header, an Expires header with a 1588 date in the past MAY be added. See section 10.7 for more 1589 information. 1591 g. If an ETag header is present in the response message from 1592 step 2, then extend the entity tag in that header with the 1593 current variant list validator, as specified in section 1594 9.2. 1596 f. Only in proxy caches: set the Age header of the response to 1598 max( variant_age , alternates_age ) 1600 where variant_age is the age of the variant response 1601 obtained in step 2, calculated according to the rules in 1602 the HTTP/1.1 specification [1], and alternates_age is the 1603 age of the Alternates header added in step d, calculated 1604 according to the rules in section 10.4. 1606 Note that a server can shorten the response produced by the above 1607 algorithm to a 304 (Not Modified) response if an If-None-Match 1608 header in the original request allows it. If this is the case, an 1609 implementation of the above algorithm can avoid the unnecessary 1610 internal construction of full response message in step 2, it need 1611 only construct the parts which end up in the final 304 response. A 1612 proxy cache which implements this optimization can sometimes 1613 generate a legal 304 response even if it has not cached the variant 1614 data itself. 1616 An example of a choice response is: 1618 HTTP/1.1 200 OK 1619 Date: Tue, 11 Jun 1996 20:05:31 GMT 1620 TCN: choice 1621 Content-Type: text/html 1622 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 1623 Content-Length: 5327 1624 Cache-control: max-age=604800 1625 Content-Location: paper.html.en 1626 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 1627 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 1628 {"paper.ps.en" 1.0 {type application/postscript} 1629 {language en}} 1630 Etag: "gonkyyyy;1234" 1631 Vary: negotiate, accept, accept-language 1632 Expires: Thu, 01 Jan 1980 00:00:00 GMT 1634 <title>A paper about .... 1636 10.3 Ad hoc response 1638 An ad hoc response has a TCN header which specifies the "adhoc" 1639 response-type. It MUST contain the Alternates header bound to the 1640 negotiable resource, and a Vary header if the response is 1641 cacheable. It MAY be generated by an origin server as a response 1642 to a non-negotiating user agent, if the server cannot or does not 1643 want to send a list or choice response. 1645 The Vary header in the response SHOULD ensure correct handling by 1646 plain HTTP/1.1 caching proxies. This header can either be 1648 Vary: * 1650 or a more elaborate header, see section 10.6.1. Depending on the 1651 status code, an ad hoc response is cacheable unless indicated 1652 otherwise. 1654 An example of an ad hoc response is: 1656 HTTP/1.1 302 Moved Temporarily 1657 Date: Tue, 11 Jun 1996 20:02:28 GMT 1658 TCN: adhoc 1659 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 1660 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 1661 {"paper.ps.en" 1.0 {type application/postscript} 1662 {language en}} 1663 Location: paper.html.en 1664 Content-Type: text/html 1665 Content-Length: 59 1667 This document is available <a href=paper.html.en>here</a>. 1669 10.4 Reusing the Alternates header 1671 If a proxy cache has available a negotiated response which is 1672 cacheable, fresh, and has an ETag header, then it MAY extract the 1673 Alternates header and associated variant list validator from the 1674 response, and reuse them (without unnecessary delay) to negotiate 1675 on behalf of the user agent (section 13) or to construct a choice 1676 response (section 10.2). The age of the extracted Alternates 1677 header is the age of the response from which it is extracted, 1678 calculated according to the rules in the HTTP/1.1 specification 1679 [1]. 1681 10.5 Extracting a normal response from a choice response 1683 If a proxy receives a choice response, it MAY extract and cache the 1684 normal HTTP response contained therein. The normal response can be 1685 extracted by taking a copy of the choice response and then deleting 1686 the Content-Location, Alternates, and Vary headers, renaming any 1687 Variant-Vary headers to Vary headers, and shortening the structured 1688 entity tag in any ETag header to a normal entity tag. 1690 This normal response MAY be cached (as a HTTP response to the 1691 variant request as constructed in step 1. of section 10.2) and 1692 reused to answer future direct requests on the variant resource, 1693 according to the rules in the HTTP/1.1 specification [1]. 1695 Note: The caching of extracted responses can decrease the 1696 upstream bandwidth usage with up to a factor 2, because two 1697 independent HTTP/1.1 cache entries, one associated with the 1698 negotiable resource URI and one with the variant URI, are 1699 created in the same transaction. Without this optimization, 1700 both HTTP/1.1 cache entries can only be created by transmitting 1701 the variant data twice. 1703 For security reasons (see section 14.2), an extracted normal 1704 response MUST NEVER be cached if belongs to a non-neighboring 1705 variant resource. If the choice response claims to contain data 1706 for a non-neighboring variant resource, the proxy SHOULD reject the 1707 choice response as a probable spoofing attempt. 1709 10.6 Elaborate Vary headers 1711 If a HTTP/1.1 [1] server can generate varying responses for a 1712 request on some resource, then the server MUST include a Vary 1713 header in these responses if they are cacheable. This Vary header 1714 is a signal to HTTP/1.1 caches that something special is going on. 1715 It prevents the caches from returning the currently chosen response 1716 for every future request on the resource. 1718 Servers engaging in transparent content negotiation will generate 1719 varying responses. Therefore, cacheable list, choice, and ad hoc 1720 responses MUST always include a Vary header. 1722 The most simple Vary header which can be included is 1724 Vary: * 1726 This header leaves the way in which the response is selected by the 1727 server completely unspecified. 1729 A more elaborate Vary header MAY be used to allow for certain 1730 optimizations in HTTP/1.1 caches which do not have specific 1731 optimizations for transparent content negotiation, but which do 1732 cache multiple variant responses for one resource. Such a more 1733 elaborate Vary header lists all request headers which can be used 1734 by the server when selecting a response for a request on the 1735 resource. 1737 10.6.1 Construction of an elaborate Vary header 1739 Origin servers can construct a more elaborate Vary header in the 1740 following way. First, start with the header 1742 Vary: negotiate 1744 `negotiate' is always included because servers use the information 1745 in the Negotiate header when choosing between a list, choice, or 1746 ad-hoc response. 1748 Then, if any of the following attributes is present in any variant 1749 description in the Alternates header, add the corresponding header 1750 name to the Vary header 1752 attribute | header name to add 1753 -----------+--------------------- 1754 type | accept 1755 charset | accept-charset 1756 language | accept-language 1757 features | accept-features 1759 The Vary header constructed in this way specifies the response 1760 variation which can be caused by the use of a variant selection 1761 algorithm in proxies. If the origin server will in some cases, for 1762 example if contacted by a non-negotiating user agent, use a custom 1763 negotiation algorithm which takes additional headers into account, 1764 these names of these headers SHOULD also be added to the Vary 1765 header. 1767 10.6.2 Caching of an elaborate Vary header 1769 A proxy cache cannot construct an elaborate vary header using the 1770 method above, because this method requires exact knowledge of any 1771 custom algorithms present in the origin server. However, when 1772 extracting an Alternates header from a response (section 10.4) 1773 caches MAY also extract the Vary header in the response, and reuse 1774 it along with the Alternates header. A clean Vary header can 1775 however only be extracted if the variant does not vary itself, 1776 i.e. if a Variant-Vary header is absent. 1778 10.7 Adding an Expires header to ensure HTTP/1.0 compatibility 1780 To ensure compatibility with HTTP/1.0 caching proxies which do not 1781 recognize the Vary header, an Expires header with a date in the 1782 past can be added to the response, for example 1784 Expires: Thu, 01 Jan 1980 00:00:00 GMT 1786 If this is done by an origin server, the server SHOULD usually also 1787 include a Cache-Control header for the benefit of HTTP/1.1 caches, 1788 for example 1790 Cache-Control: max-age=604800 1792 which overrides the freshness lifetime of zero seconds specified by 1793 the included Expires header. 1795 Note: This specification only claims downwards compatibility 1796 with the HTTP/1.0 proxy caches which implement the HTTP/1.0 1797 specification [3]. Some legacy proxy caches which return the 1798 HTTP/1.0 protocol version number do not honor the HTTP/1.0 1799 Expires header as specified in [3]. Methods for achieving 1800 compatibility with such proxy caches are beyond the scope of 1801 this specification. 1803 10.8 Negotiation on content encoding 1805 Negotiation on the content encoding of a response is orthogonal to 1806 transparent content negotiation. The rules for when a content 1807 encoding may be applied are the same as in HTTP/1.1: servers MAY 1808 content-encode responses that are the result of transparent content 1809 negotiation whenever an Accept-Encoding header in the request 1810 allows it. When negotiating on the content encoding of a cacheable 1811 response, servers MUST add the accept-encoding header name to the 1812 Vary header of the response, or add `Vary: *'. 1814 Servers SHOULD always be able to provide unencoded versions of 1815 every transparently negotiated response. This means in particular 1816 that every variant in the variant list SHOULD at least be available 1817 in an unencoded form. 1819 Like HTTP/1.1, this specification allows proxies to encode or 1820 decode relayed or cached responses on the fly, unless explicitly 1821 forbidden by a Cache-Control directive. The encoded or decoded 1822 response still contains the same variant as far as transparent 1823 content negotiation is concerned. Note that HTTP/1.1 requires 1824 proxies to add a Warning header if the encoding of a response is 1825 changed. 1827 11 User agent support for transparent negotiation 1829 This section specifies the requirements a user agent needs to 1830 satisfy in order to support transparent negotiation. If the user 1831 agent contains an internal cache, this cache MUST conform to the 1832 rules for proxy caches in section 13. 1834 11.1 Handling of responses 1836 If a list response is received when a resource is accessed, the 1837 user agent MUST be able to automatically choose, retrieve, and 1838 display the best variant, or display an error message if none of 1839 the variants are acceptable. 1841 If a choice response is received when a resource is accessed, the 1842 usual action is to automatically display the enclosed entity. 1843 However, if a remote variant selection algorithm which was enabled 1844 could have made a choice different from the choice the local 1845 algorithm would make, the user agent MAY apply its local algorithm 1846 to the variant list in the response, and automatically retrieve and 1847 display another variant if the local algorithm makes an other 1848 choice. 1850 When receiving a choice response, a user agent SHOULD check if 1851 variant resource is a neighboring variant resource of the 1852 negotiable resource. If this is not the case, the user agent 1853 SHOULD reject the choice response as a probable spoofing attempt 1854 and display an error message, for example by internally replacing 1855 the choice response with a 502 (bad gateway) response. 1857 11.2 Presentation of a transparently negotiated resource 1859 If the user agent is displaying a variant which is not an embedded 1860 or inlined object and which is the result of transparent 1861 negotiation, the following requirements apply. 1863 1. The user agent SHOULD allow the user to review a list of all 1864 variants bound to the negotiable resource, and to manually 1865 retrieve another variant if desired. There are two general 1866 ways of providing such a list. First, the information in the 1867 Alternates header of the negotiable resource could be used to 1868 make an annotated menu of variants. Second, the entity 1869 included in a list response of the negotiable resource could be 1870 displayed. Note that a list response can be obtained by doing 1871 a GET request which only has the "trans" directive in the 1872 Negotiate header. 1874 2. The user agent SHOULD make available though its user interface 1875 some indication that the resource being displayed is a 1876 negotiated resource instead of a plain resource. It SHOULD 1877 also allow the user to examine the variant list included in the 1878 Alternates header. Such a notification and review mechanism is 1879 needed because of privacy considerations, see section 14.1. 1881 3. If the user agent shows the URI of the displayed information to 1882 the user, it SHOULD be the negotiable resource URI, not the 1883 variant URI that is shown. This encourages third parties, who 1884 want to refer to the displayed information in their own 1885 documents, to make a hyperlink to the negotiable resource as a 1886 whole, rather than to the variant resource which happens to be 1887 shown. Such correct linking is vital for the interoperability 1888 of content across sites. The user agent SHOULD however also 1889 provide a means for reviewing the URI of the particular variant 1890 which is currently being displayed. 1892 4. Similarly, if the user agent stores a reference to the 1893 displayed information for future use, for example in a hotlist, 1894 it SHOULD store the negotiable resource URI, not the 1895 variant URI. 1897 It is encouraged, but not required, that some of the above 1898 functionality is also made available for inlined or embedded 1899 objects, and when a variant which was selected manually is being 1900 displayed. 1902 12 Origin server support for transparent negotiation 1904 12.1 Requirements 1906 To implement transparent negotiation on a resource, the origin 1907 server MUST be able to send a list response when getting a GET 1908 request on the resource. It SHOULD also be able to send 1909 appropriate list responses for HEAD requests. A list response MUST 1910 ALWAYS be sent if the request includes a Negotiate header with only 1911 a "trans" directive. If the Negotiate header allows it, the origin 1912 server MAY run a remote variant selection algorithm. If the 1913 algorithm has sufficient information to choose a best variant, and 1914 if the best variant is a neighboring variant, the origin server MAY 1915 return a choice response with this variant. 1917 When getting a request on a transparently negotiable resource from 1918 a user agent which does not support transparent content 1919 negotiation, the origin server MAY use a custom algorithm to select 1920 between sending a list, choice, or ad hoc response. When getting a 1921 request on a transparently negotiable resource, the origin server 1922 MUST NEVER return a response with a 2xx status code or any 3xx 1923 status code, except 304, which is not a list, choice, or ad hoc 1924 response. 1926 Negotiability is a binary property: a resource is either 1927 transparently negotiated, or it is not. Origin servers SHOULD NOT 1928 vary the negotiability of a resource, or the variant list bound to 1929 that resource, based on the request headers which are received. 1930 The variant list and the property of being negotiated MAY however 1931 change through time. The Cache-Control header can be used to 1932 control the propagation of such time-dependent changes through 1933 caches. 1935 It is the responsibility of the author of the negotiable resource 1936 to ensure that all resources in the variant list serve the intended 1937 content, and that the variant resources do not engage in 1938 transparent content negotiation themselves. 1940 12.2 Negotiation on transactions other than GET and HEAD 1942 If a resource is transparently negotiable, this only has an impact 1943 on the GET and HEAD transactions on the resource. It is not 1944 possible (under this specification) to do transparent content 1945 negotiation on the direct result of a POST request. 1947 However, a POST request can return an unnegotiated 303 (See Other) 1948 response which causes the user agent to do a GET request on a 1949 second resource. This second resource could then use transparent 1950 content negotiation to return an appropriate final response. The 1951 figure below illustrates this. 1953 Server ______ proxy ______ proxy ______ user 1954 x.org cache cache agent 1956 < ------------------------------------- 1957 | POST http://x.org/cgi/submit 1958 | <form contents in request body> 1959 | 1960 -------------------------------------- > 1961 303 See Other | 1962 Location: http://x.org/result/OK | 1963 | 1964 < ------------------------------------- 1965 | GET http://x.org/result/OK 1966 | small Accept- headers 1967 | 1968 able to choose on 1969 behalf of user agent 1970 | 1971 ------------------------------------- > 1972 choice response with | 1973 ..result/OK.nl variant | 1974 displays OK.nl 1976 See the HTTP/1.1 specification [1] for details on the 303 (See 1977 Other) status code. Note that this status code is not understood 1978 by some HTTP/1.0 clients. 1980 13 Proxy support for transparent negotiation 1982 Transparent content negotiation is an extension on top of HTTP/1.x. 1983 It is designed to work through any proxy which only implements the 1984 HTTP/1.1 specification [1]. If Expires headers are added as 1985 discussed in section 10.7, negotiation will also work though 1986 proxies which implement HTTP/1.0 [3]. Thus, every HTTP/1.0 or 1987 HTTP/1.1 proxy provides support for transparent content 1988 negotiation. However, if it is to be claimed that a HTTP/1.x proxy 1989 offers transparent content negotiation services, at least one of 1990 the specific optimizations below MUST be implemented. 1992 An HTTP/1.x proxy MUST ONLY optimize (change) the HTTP traffic 1993 flowing through it in ways which are explicitly allowed by the 1994 specification(s) it conforms to. A proxy which supports 1995 transparent content negotiation on top of HTTP/1.x MAY perform the 1996 optimizations allowed for by HTTP/1.x. In addition, it MAY perform 1997 three additional optimizations, defined below, on the HTTP traffic 1998 for transparently negotiated resources and their neighboring 1999 variant resources. 2001 First, when getting a request on a transparently negotiable 2002 resource from a user agent which supports transparent content 2003 negotiation, the proxy MAY return any cached, fresh list response 2004 from that resource, even if the selecting request headers, as 2005 specified by the Vary header, do not match. 2007 Second, when allowed by the user agent and origin server, a proxy 2008 MAY reuse an Alternates header taken from a previous response 2009 (section 10.4) to run a remote variant selection algorithm. If the 2010 algorithm has sufficient information to choose a best variant, and 2011 if the best variant is a neighboring variant, the proxy MAY return 2012 a choice response with this variant. 2014 Third, if a proxy receives a choice response, it MAY extract and 2015 cache the normal response embedded therein, as described in section 2016 10.5. 2018 14 Security and privacy considerations 2020 14.1 Accept- headers revealing information of a private nature 2022 Accept- headers, in particular Accept-Language headers, may reveal 2023 information which the user would rather keep private unless it will 2024 directly improve the quality of service. For example, a user may 2025 not want to send language preferences to sites which do not offer 2026 multi-lingual content. The transparent content negotiation 2027 mechanism allows user agents to omit sending of the Accept-Language 2028 header by default, without adversely affecting the outcome of the 2029 negotiation process if transparently negotiated multi-lingual 2030 content is accessed. 2032 However, even if Accept- headers are never sent, the automatic 2033 selection and retrieval of a variant by a user agent will reveal a 2034 preference for this variant to the server. A malicious service 2035 author could provide a page with `fake' negotiability on 2036 (ethnicity-correlated) languages, with all variants actually being 2037 the same English document, as a means of obtaining 2038 privacy-sensitive information. Such a plot would however be 2039 visible to an alert victim if the list of available variants and 2040 their properties is reviewed. 2042 Some additional privacy considerations connected to Accept- headers 2043 are discussed in [1]. 2045 14.2 Spoofing of responses from variant resources 2047 The caching optimization in section 10.5 gives the implementer of a 2048 negotiable resource control over the responses cached for all 2049 neighboring variant resources. This is a security problem if a 2050 neighboring variant resource belongs to another author. To provide 2051 security in this case, the HTTP server will have to filter the 2052 Content-Location headers in the choice responses generated by the 2053 negotiable resource implementation. 2055 15 Acknowledgments 2057 Work on HTTP content negotiation has been done since at least 1993. 2058 The authors are unable to trace the origin of many of the ideas 2059 incorporated in this document. This specification builds on an 2060 earlier incomplete specification of content negotiation recorded in 2061 [2]. Many members of the HTTP working group have contributed to 2062 the negotiation model in this specification. The authors wish to 2063 thank the individuals who have commented on earlier versions of 2064 this document, including Brian Behlendorf, Daniel DuBois, Roy 2065 T. Fielding, Dirk van Gulik, Ted Hardie, Larry Masinter, Jeffrey 2066 Mogul, Frederick G.M. Roeber, Paul Sutton, and Klaus Weide. 2068 16 References 2070 [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 2071 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 2072 2068, HTTP Working Group, January, 1997. 2074 [2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. 2075 Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft 2076 draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, 2077 1996. 2079 [3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext 2080 Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, 2081 May 1996. 2083 [4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. 2084 Internet-Draft draft-ietf-http-feature-reg-00.txt, HTTP Working 2085 Group, October 30, 1996. 2087 [5] K. Holtman, A. Mutz. HTTP Remote Variant Selection Algorithm 2088 -- RVSA/1.0. Internet-Draft draft-ietf-http-rvsa-v10-00.txt, 2089 HTTP Working Group. 2091 17 Authors' addresses 2093 Koen Holtman 2094 Technische Universiteit Eindhoven 2095 Postbus 513 2096 Kamer HG 6.57 2097 5600 MB Eindhoven (The Netherlands) 2098 Email: koen@win.tue.nl 2100 Andrew H. Mutz 2101 Hewlett-Packard Company 2102 1501 Page Mill Road 3U-3 2103 Palo Alto CA 94304, USA 2104 Fax +1 415 857 4691 2105 Email: mutz@hpl.hp.com 2107 18 Appendix: feature negotiation examples 2109 This appendix contains examples of the use of feature tags in 2110 variant descriptions. The tag names used here are examples only, 2111 they do not in general reflect the tag naming scheme proposed in 2112 [4]. 2114 18.1 Use of feature tags 2116 Feature tags can be used in variant lists to express the quality 2117 degradation associated with the presence or absence of certain 2118 features. One example is 2120 {"index.html.plain" 0.7 }, 2121 {"index.html" 1.0 {features tables frames}} 2123 Here, the "{features tables frames}" part expresses that index.html 2124 uses the features tagged as tables and frames. If these features 2125 are absent, the overall quality of index.html degrades to 0. 2126 Another example is 2128 {"home.graphics" 1.0 {features !textonly}}, 2129 {"home.textonly" 0.7 } 2131 where the "{features !textonly}" part expresses that home.graphics 2132 requires the absence of the textonly feature. If the feature is 2133 present, the overall quality of home.graphics degrades to 0. 2135 The absence of a feature need not always degrade the overall quality 2136 to 0. In the example 2138 {"x.html.1" 1.0 {features fonts/0.7}} 2140 the absence of the fonts feature degrades the quality with a factor 2141 of 0.7. "fonts/0.7" can be pronounced as "fonts, or a degradation 2142 of 0.7". Finally, in the example 2144 {"y.html" 1.0 {features [blebber wolx] }} 2146 The "[blebber wolx]" expresses that y.html requires the presence of 2147 the blebber feature or the wolx feature. This construct can be 2148 used in a number of cases: 2150 1. blebber and wolx actually tag the same feature, but they were 2151 registered by different people, and some user agents say they 2152 support blebber while others say they support wolx. 2154 2. blebber and wolx are HTML tags of different vendors which 2155 implement the same functionality, and which are used 2156 together in y.html without interference. 2158 3. blebber and wolx are HTML tags of different vendors which 2159 implement the same functionality, and y.html uses the tags in 2160 a conditional HTML construct. 2162 4. blebber is a complicated HTML tag with only a sketchy 2163 definition, implemented by one user agent vendor, and wolx 2164 indicates implementation of a well-defined subset of the 2165 blebber tag by some other vendor(s). y.html uses only this 2166 well-defined subset. 2168 18.2 Use of numeric feature tags 2170 As an example of negotiation in a numeric area, the following 2171 variant list describes four variants with title graphics designed 2172 for increasing screen widths: 2174 {"home.pda" 1.0 {features screenwidth=<-199> }}, 2175 {"home.narrow" 1.0 {features screenwidth=<200-599> }}, 2176 {"home.normal" 1.0 {features screenwidth=<600-999> }}, 2177 {"home.wide" 1.0 {features screenwidth=<1000-> }}, 2178 {"home.normal"} 2180 The last element of the list specifies a safe default for user 2181 agents which do not implement screen width negotiation. Such user 2182 agents will reject the first four variants as unusable, as they 2183 seem to rely on a feature which they do not understand. 2185 18.3 Feature tag design 2187 When designing a new feature tag, it is important to take into 2188 account that existing user agents, which do not recognize the new 2189 tag will treat the feature as absent. In general, a new feature 2190 tag needs to be designed in such a way that absence of the tag is 2191 the default case which reflects current practice. If this design 2192 principle is ignored, the resulting feature tag will generally be 2193 unusable. 2195 As an example, one could try to support negotiation between 2196 monochrome and color content by introducing a `color' feature tag, 2197 the presence of which would indicate the capability to display 2198 color graphics. However, if this new tag is used in a variant 2199 list, for example 2201 {"rainbow.gif" 1.0 {features color} } 2202 {"rainbow.mono.gif" 0.6 {features !color}} 2204 then existing user agents, which would not recognize the color tag, 2205 would all display the monochrome rainbow. The color tag is 2206 therefore unusable in situations where optimal results for existing 2207 user agents are desired. To provide for negotiation in this area, 2208 one must introduce a `monochrome' feature tag; its presence 2209 indicates that the user agent can only render (or the user prefers 2210 to view) monochrome graphics. 2212 19 Appendix: origin server implementation considerations 2214 19.1 Implementation with a CGI script 2216 Transparent content negotiation has been designed to allow a broad 2217 range of implementation options at the origin server side. A very 2218 minimal implementation can be done using the CGI interface. The 2219 CGI script below is an example. 2221 #!/bin/sh 2223 cat - <<'blex' 2224 TCN: list 2225 Alternates: {"stats.tables.html" 1.0 {type text/html} {features 2226 tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95 2227 {type application/postscript}} 2228 Vary: * 2229 Content-Type: text/html 2231 <title>Multiple Choices for Web Statistics 2232

Multiple Choices for Web Statistics:

2233 2240 blex 2242 The Alternates header in the above script must be read as a single 2243 line. The script always generates a list response with the 200 2244 (OK) code, which ensures compatibility with non-negotiating 2245 HTTP/1.0 agents. 2247 19.2 Direct support by HTTP servers 2249 Sophisticated HTTP servers could make a transparent negotiation 2250 module available to content authors. Such a module could 2251 incorporate a remote variant selection algorithm and an 2252 implementation of the algorithm for generating choice responses 2253 (section 10.2). The definition of interfaces to such modules is 2254 beyond the scope of this specification. 2256 19.3 Web publishing tools 2258 Web publishing tools could automatically generate several variants 2259 of a document (for example the original TeX version, a HTML version 2260 with tables, a HTML version without tables, and a Postscript 2261 version), together with an appropriate variant list in the 2262 interface format of a HTTP server transparent negotiation module. 2263 This would allow documents to be published as transparently 2264 negotiable resources. 2266 20 Appendix: Example of choice response construction 2268 The following is an example of the construction of a choice 2269 response by a proxy cache which supports HTTP/1.1 and transparent 2270 content negotiation. The use of the HTTP/1.1 conditional request 2271 mechanisms is also shown. 2273 Assume that a user agent has cached a variant list with the 2274 validator "1234" for the negotiable resource http://x.org/paper. 2275 Also assume that it has cached responses from two neighboring 2276 variants, with the entity tags "gonkyyyy" and W/"a;b". Assume that 2277 all three user agent cache entries are stale: they would need to be 2278 revalidated before the user agent can use them. If 2279 http://x.org/paper accessed in this situation, the user agent could 2280 send the following request to its proxy cache: 2282 GET /paper HTTP/1.1 2283 Host: x.org 2284 User-Agent: WuxtaWeb/2.4 2285 Negotiate: 1.0 2286 Accept: text/html, application/postscript;q=0.4, */* 2287 Accept-Language: en 2288 If-None-Match: "gonkyyyy;1234", W/"a;b;1234" 2290 Assume that the proxy cache has cached the same three items as the 2291 user agent, but that it has revalidated the variant list 8000 2292 seconds ago, so that the list is still fresh for the proxy. This 2293 means that the proxy can run a remote variant selection algorithm 2294 on the list and the incoming request. 2296 Assume that the remote algorithm is able to choose paper.en.html as 2297 the best variant. The proxy can now construct a choice response, 2298 using the algorithm in section 10.2. In steps 1 and 2 of the 2299 algorithm, the proxy can construct the following conditional 2300 request on the best variant, and send it to the origin server: 2302 GET /paper.html.en HTTP/1.1 2303 Host: x.org 2304 User-Agent: WuxtaWeb/2.4 2305 Negotiate: 1.0 2306 Accept: text/html, application/postscript;q=0.4, */* 2307 Accept-Language: en 2308 If-None-Match: "gonkyyyy", W/"a;b" 2309 Via: 1.1 fred 2311 On receipt of the response 2313 HTTP/1.1 304 Not Modified 2314 Date: Tue, 11 Jun 1996 20:05:31 GMT 2315 Etag: "gonkyyyy" 2317 from the origin server, the proxy can use its freshly revalidated 2318 paper.html.en cache entry to expand the response to a non-304 2319 response: 2321 HTTP/1.1 200 OK 2322 Date: Tue, 11 Jun 1996 20:05:31 GMT 2323 Content-Type: text/html 2324 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 2325 Content-Length: 5327 2326 Cache-control: max-age=604800 2327 Etag: "gonkyyyy" 2328 Via: 1.1 fred 2329 Age: 0 2331 A paper about .... 2333 Using this 200 response, the proxy can construct a choice response 2334 in step 4 of the algorithm: 2336 HTTP/1.1 200 OK 2337 Date: Tue, 11 Jun 1996 20:05:31 GMT 2338 TCN: choice 2339 Content-Type: text/html 2340 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 2341 Content-Length: 5327 2342 Cache-control: max-age=604800 2343 Content-Location: paper.html.en 2344 Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, 2345 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 2346 {"paper.ps.en" 1.0 {type application/postscript} 2347 {language en}} 2348 Etag: "gonkyyyy;1234" 2349 Vary: negotiate, accept, accept-language 2350 Expires: Thu, 01 Jan 1980 00:00:00 GMT 2351 Via: 1.1 fred 2352 Age: 8000 2354 <title>A paper about .... 2356 The choice response can subsequently be shortened to a 304 2357 response, because of the If-None-Match header in the original 2358 request from the user agent. Thus, the proxy can finally return 2360 HTTP/1.1 304 Not Modified 2361 Date: Tue, 11 Jun 1996 20:05:31 GMT 2362 Etag: "gonkyyyy;1234" 2363 Content-Location: paper.html.en 2364 Vary: negotiate, accept, accept-language 2365 Expires: Thu, 01 Jan 1980 00:00:00 GMT 2366 Via: 1.1 fred 2367 Age: 8000 2369 to the user agent. 2371 Expires: September 9, 1997