diff options
Diffstat (limited to 'doc/rfc/rfc2295.txt')
| -rw-r--r-- | doc/rfc/rfc2295.txt | 3251 |
1 files changed, 3251 insertions, 0 deletions
diff --git a/doc/rfc/rfc2295.txt b/doc/rfc/rfc2295.txt new file mode 100644 index 0000000..2811353 --- /dev/null +++ b/doc/rfc/rfc2295.txt @@ -0,0 +1,3251 @@ + + + + + + +Network Working Group K. Holtman +Request for Comments: 2295 TUE +Category: Experimental A. Mutz + Hewlett-Packard + March 1998 + + + Transparent Content Negotiation in HTTP + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +ABSTRACT + + HTTP allows web site authors to put multiple versions of the same + information under a single URL. Transparent content negotiation is + an extensible negotiation mechanism, layered on top of HTTP, for + automatically selecting the best version when the URL is accessed. + This enables the smooth deployment of new web data formats and markup + tags. + +TABLE OF CONTENTS + + 1 Introduction................................................4 + 1.1 Background................................................4 + + 2 Terminology.................................................5 + 2.1 Terms from HTTP/1.1.......................................5 + 2.2 New terms.................................................6 + + 3 Notation....................................................8 + + 4 Overview....................................................9 + 4.1 Content negotiation.......................................9 + 4.2 HTTP/1.0 style negotiation scheme.........................9 + 4.3 Transparent content negotiation scheme...................10 + 4.4 Optimizing the negotiation process.......................12 + 4.5 Downwards compatibility with non-negotiating user agents.14 + 4.6 Retrieving a variant by hand.............................15 + 4.7 Dimensions of negotiation................................15 + + + +Holtman & Mutz Experimental [Page 1] + +RFC 2295 Transparent Content Negotiation March 1998 + + + 4.8 Feature negotiation......................................15 + 4.9 Length of variant lists..................................16 + 4.10 Relation with other negotiation schemes.................16 + + 5 Variant descriptions.......................................17 + 5.1 Syntax...................................................17 + 5.2 URI......................................................17 + 5.3 Source-quality...........................................18 + 5.4 Type, charset, language, and length......................19 + 5.5 Features.................................................19 + 5.6 Description..............................................19 + 5.7 Extension-attribute......................................20 + + 6 Feature negotiation........................................20 + 6.1 Feature tags.............................................20 + 6.1.1 Feature tag values.....................................21 + 6.2 Feature sets.............................................21 + 6.3 Feature predicates.......................................22 + 6.4 Features attribute.......................................24 + + 7 Remote variant selection algorithms........................25 + 7.1 Version numbers..........................................25 + + 8 Content negotiation status codes and headers...............25 + 8.1 506 Variant Also Negotiates..............................25 + 8.2 Accept-Features..........................................26 + 8.3 Alternates...............................................27 + 8.4 Negotiate................................................28 + 8.5 TCN......................................................30 + 8.6 Variant-Vary.............................................30 + + 9 Cache validators...........................................31 + 9.1 Variant list validators..................................31 + 9.2 Structured entity tags...................................31 + 9.3 Assigning entity tags to variants........................32 + + 10 Content negotiation responses..............................32 + 10.1 List response...........................................33 + 10.2 Choice response.........................................34 + 10.3 Adhoc response..........................................37 + 10.4 Reusing the Alternates header...........................38 + 10.5 Extracting a normal response from a choice response.....39 + 10.6 Elaborate Vary headers..................................39 + 10.6.1 Construction of an elaborate Vary header..............40 + 10.6.2 Caching of an elaborate Vary header...................41 + 10.7 Adding an Expires header for HTTP/1.0 compatibility.....41 + 10.8 Negotiation on content encoding.........................41 + + + + +Holtman & Mutz Experimental [Page 2] + +RFC 2295 Transparent Content Negotiation March 1998 + + + 11 User agent support for transparent negotiation.............42 + 11.1 Handling of responses...................................42 + 11.2 Presentation of a transparently negotiated resource.....42 + + 12 Origin server support for transparent negotiation..........43 + 12.1 Requirements............................................43 + 12.2 Negotiation on transactions other than GET and HEAD.....45 + + 13 Proxy support for transparent negotiation..................45 + + 14 Security and privacy considerations........................46 + 14.1 Accept- headers revealing personal information..........46 + 14.2 Spoofing of responses from variant resources............47 + 14.3 Security holes revealed by negotiation..................47 + + 15 Internationalization considerations........................47 + + 16 Acknowledgments............................................47 + + 17 References.................................................48 + + 18 Authors' Addresses.........................................48 + + 19 Appendix: Example of a local variant selection algorithm...49 + 19.1 Computing overall quality values........................49 + 19.2 Determining the result..................................51 + 19.3 Ranking dimensions......................................51 + + 20 Appendix: feature negotiation examples.....................52 + 20.1 Use of feature tags.....................................52 + 20.2 Use of numeric feature tags.............................53 + 20.3 Feature tag design......................................53 + + 21 Appendix: origin server implementation considerations......54 + 21.1 Implementation with a CGI script........................54 + 21.2 Direct support by HTTP servers..........................55 + 21.3 Web publishing tools....................................55 + + 22 Appendix: Example of choice response construction..........55 + + 23 Full Copyright Statement...................................58 + + + + + + + + + + +Holtman & Mutz Experimental [Page 3] + +RFC 2295 Transparent Content Negotiation March 1998 + + +1 Introduction + + HTTP allows web site authors to put multiple versions of the same + information under a single URI. Each of these versions is called a + `variant'. Transparent content negotiation is an extensible + negotiation mechanism for automatically and efficiently retrieving + the best variant when a GET or HEAD request is made. This enables + the smooth deployment of new web data formats and markup tags. + + This specification defines transparent content negotiation as an + extension on top of the HTTP/1.1 protocol [1]. However, use of this + extension does not require use of HTTP/1.1: transparent content + negotiation can also be done if some or all of the parties are + HTTP/1.0 [2] systems. + + Transparent content negotiation is called `transparent' because it + makes all variants which exist inside the origin server visible to + outside parties. + + Note: Some members of the IETF are currently undertaking a number + of activities which are loosely related to this experimental + protocol. First, there is an effort to define a protocol- + independent registry for feature tags. The intention is that this + experimental protocol will be one of the clients of the registry. + Second, some research is being done on content negotiation systems + for other transport protocols (like internet mail and internet fax) + and on generalized negotiation systems for multiple transport + protocols. At the time of writing, it is unclear if or when this + research will lead to results in the form of complete negotiation + system specifications. It is also unclear to which extent possible + future specifications can or will re-use elements of this + experimental protocol. + +1.1 Background + + The addition of content negotiation to the web infrastructure has + been considered important since the early days of the web. Among the + expected benefits of a sufficiently powerful system for content + negotiation are + + * smooth deployment of new data formats and markup tags will + allow graceful evolution of the web + + * eliminating the need to choose between a `state of the art + multimedia homepage' and one which can be viewed by all web users + + * enabling good service to a wider range of browsing + platforms (from low-end PDA's to high-end VR setups) + + + +Holtman & Mutz Experimental [Page 4] + +RFC 2295 Transparent Content Negotiation March 1998 + + + * eliminating error-prone and cache-unfriendly + User-Agent based negotiation + + * enabling construction of sites without `click here for the X + version' links + + * internationalization, and the ability to offer multi-lingual + content without a bias towards one language. + +2 Terminology + + The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in + this document are to be interpreted as described in RFC 2119 [4]. + + This specification uses the term `header' as an abbreviation for for + `header field in a request or response message'. + +2.1 Terms from HTTP/1.1 + + This specification mostly uses the terminology of the HTTP/1.1 + specification [1]. For the convenience of the reader, this section + reproduces some key terminology definition from [1]. + + request + An HTTP request message. + + response + An HTTP response message. + + resource + A network data object or service that can be identified by a URI. + Resources may be available in multiple representations (e.g. + multiple languages, data formats, size, resolutions) or vary in + other ways. + + content negotiation + The mechanism for selecting the appropriate representation when + servicing a request. + + client + A program that establishes connections for the purpose of sending + requests. + + user agent + The client which initiates a request. These are often browsers, + editors, spiders (web-traversing robots), or other end user tools. + + + + + +Holtman & Mutz Experimental [Page 5] + +RFC 2295 Transparent Content Negotiation March 1998 + + + server + An application program that accepts connections in order to service + requests by sending back responses. Any given program may be + capable of being both a client and a server; our use of these terms + refers only to the role being performed by the program for a + particular connection, rather than to the program's capabilities in + general. Likewise, any server may act as an origin server, proxy, + gateway, or tunnel, switching behavior based on the nature of each + request. + + origin server + The server on which a given resource resides or is to be created. + + proxy + An intermediary program which acts as both a server and a client + for the purpose of making requests on behalf of other clients. + Requests are serviced internally or by passing them on, with + possible translation, to other servers. A proxy must implement + both the client and server requirements of this specification. + + age + The age of a response is the time since it was sent by, or + successfully validated with, the origin server. + + fresh + A response is fresh if its age has not yet exceeded its freshness + lifetime. + +2.2 New terms + + transparently negotiable resource + A resource, identified by a single URI, which has multiple + representations (variants) associated with it. When servicing a + request on its URI, it allows selection of the best representation + using the transparent content negotiation mechanism. A + transparently negotiable resource always has a variant list bound + to it, which can be represented as an Alternates header (defined in + section 8.3). + + variant list + A list containing variant descriptions, which can be bound to a + transparently negotiable resource. + + + + + + + + + +Holtman & Mutz Experimental [Page 6] + +RFC 2295 Transparent Content Negotiation March 1998 + + + variant description + A machine-readable description of a variant resource, usually found + in a variant list. A variant description contains the variant + resource URI and various attributes which describe properties of + the variant. Variant descriptions are defined in section 5. + + variant resource + A resource from which a variant of a negotiable resource can be + retrieved with a normal HTTP/1.x GET request, i.e. a GET request + which does not use transparent content negotiation. + + neighboring variant + A variant resource is called a neighboring variant resource of some + transparently negotiable HTTP resource if the variant resource has + a HTTP URL, and if the absolute URL of the variant resource up to + its last slash equals the absolute URL of the negotiable resource + up to its last slash, where equality is determined with the URI + comparison rules in section 3.2.3 of [1]. The property of being a + neighboring variant is important because of security considerations + (section 14.2). Not all variants of a negotiable resource need to + be neighboring variants. However, access to neighboring variants + can be more highly optimized by the use of remote variant selection + algorithms (section 7) and choice responses (section 10.2). + + remote variant selection algorithm + A standardized algorithm by which a server can sometimes choose a + best variant on behalf of a negotiating user agent. The algorithm + typically computes whether the Accept- headers in the request + contain sufficient information to allow a choice, and if so, which + variant is the best variant. The use of a remote algorithm can + speed up the negotiation process. + + list response + A list response returns the variant list of the negotiable + resource, but no variant data. It can be generated when the server + does not want to, or is not allowed to, return a particular best + variant for the request. List responses are defined in section + 10.1. + + choice response + A choice response returns a representation of the best variant for + the request, and may also return the variant list of the negotiable + resource. It can be generated when the server has sufficient + information to be able to choose the best variant on behalf the + user agent, but may only be generated if this best variant is a + neighboring variant. Choice responses are defined in section 10.2. + + + + + +Holtman & Mutz Experimental [Page 7] + +RFC 2295 Transparent Content Negotiation March 1998 + + + adhoc response + An adhoc response can be sent by an origin server as an extreme + measure, to achieve compatibility with a non-negotiating or buggy + client if this compatibility cannot be achieved by sending a list + or choice response. There are very little requirements on the + contents of an adhoc response. Adhoc responses are defined in + section 10.3. + + Accept- headers + The request headers: Accept, Accept-Charset, Accept-Language, and + Accept-Features. + + supports transparent content negotiation + From the viewpoint of an origin server or proxy, a user agent + supports transparent content negotiation if and only if it sends a + Negotiate header (section 8.4) which indicates such support. + + server-side override + If a request on a transparently negotiated resource is made by a + client which supports transparent content negotiation, an origin + server is said to perform a server-side override if the server + ignores the directives in the Negotiate request header, and instead + uses a custom algorithm to choose an appropriate response. A + server-side override can sometimes be used to work around known + client bugs. It could also be used by protocol extensions on top + of transparent content negotiation. + +3 Notation + + The version of BNF used in this document is taken from [1], and many + of the nonterminals used are defined in [1]. Note that the + underlying charset is US-ASCII. + + One new BNF construct is added: + + 1%rule + + stands for one or more instances of "rule", separated by whitespace: + + 1%rule = rule *( 1*LWS rule ) + + This specification also introduces + + number = 1*DIGIT + + short-float = 1*3DIGIT [ "." 0*3DIGIT ] + + + + + +Holtman & Mutz Experimental [Page 8] + +RFC 2295 Transparent Content Negotiation March 1998 + + + This specification uses the same conventions as in [1] (see section + 1.2 of [1]) for defining the significance of each particular + requirement. + +4 Overview + + This section gives an overview of transparent content negotiation. + It starts with a more general discussion of negotiation as provided + by HTTP. + +4.1 Content negotiation + + HTTP/1.1 allows web site authors to put multiple versions of the same + information under a single resource URI. Each of these versions is + called a `variant'. For example, a resource http://x.org/paper could + bind to three different variants of a paper: + + 1. HTML, English + 2. HTML, French + 3. Postscript, English + + Content negotiation is the process by which the best variant is + selected if the resource is accessed. The selection is done by + matching the properties of the available variants to the capabilities + of the user agent and the preferences of the user. + + It has always been possible under HTTP to have multiple + representations available for one resource, and to return the most + appropriate representation for each subsequent request. However, + HTTP/1.1 is the first version of HTTP which has provisions for doing + this in a cache-friendly way. These provisions include the Vary + response header, entity tags, and the If-None-Match request header. + +4.2 HTTP/1.0 style negotiation scheme + + The HTTP/1.0 protocol elements allow for a negotiation scheme as + follows: + + Server _____ proxy _____ proxy _____ user + x.org cache cache agent + + < ---------------------------------- + | GET http://x.org/paper + | Accept- headers + choose + | + ---------------------------------- > + Best variant + + + +Holtman & Mutz Experimental [Page 9] + +RFC 2295 Transparent Content Negotiation March 1998 + + + When the resource is accessed, the user agent sends (along with its + request) various Accept- headers which express the user agent + capabilities and the user preferences. Then the origin server uses + these Accept- headers to choose the best variant, which is returned + in the response. + + The biggest problem with this scheme is that it does not scale well. + For all but the most minimal user agents, Accept- headers expressing + all capabilities and preferences would be very large, and sending + them in every request would be hugely inefficient, in particular + because only a small fraction of the resources on the web have + multiple variants. + +4.3 Transparent content negotiation scheme + + The transparent content negotiation scheme eliminates the need to + send huge Accept- headers, and nevertheless allows for a selection + process that always yields either the best variant, or an error + message indicating that user agent is not capable of displaying any + of the available variants. + + Under the transparent content negotiation scheme, the server sends a + list with the available variants and their properties to the user + agent. An example of a list with three variants is + + {"paper.1" 0.9 {type text/html} {language en}}, + {"paper.2" 0.7 {type text/html} {language fr}}, + {"paper.3" 1.0 {type application/postscript} {language en}} + + The syntax and semantics of the variant descriptions in this list are + covered in section 5. When the list is received, the user agent can + choose the best variant and retrieve it. Graphically, the + communication can be represented as follows: + + + + + + + + + + + + + + + + + + +Holtman & Mutz Experimental [Page 10] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Server _____ proxy _____ proxy _____ user + x.org cache cache agent + + < ---------------------------------- + | GET http://x.org/paper + | + ----------------------------------- > [list response] + return of list | + choose + | + < ---------------------------------- + | GET http://x.org/paper.1 + | + ---------------------------------- > [normal response] + return of paper.1 + + The first response returning the list of variants is called a `list + response'. The second response is a normal HTTP response: it does + not contain special content negotiation related information. Only + the user agent needs to know that the second request actually + retrieves a variant. For the other parties in the communication, the + second transaction is indistinguishable from a normal HTTP + transaction. + + With this scheme, information about capabilities and preferences is + only used by the user agent itself. Therefore, sending such + information in large Accept- headers is unnecessary. Accept- headers + do have a limited use in transparent content negotiation however; the + sending of small Accept- headers can often speed up the negotiation + process. This is covered in section 4.4. + + List responses are covered in section 10.1. As an example, the list + response in the above picture could be: + + HTTP/1.1 300 Multiple Choices + Date: Tue, 11 Jun 1996 20:02:21 GMT + TCN: list + Alternates: {"paper.1" 0.9 {type text/html} {language en}}, + {"paper.2" 0.7 {type text/html} {language fr}}, + {"paper.3" 1.0 {type application/postscript} + {language en}} + Vary: negotiate, accept, accept-language + ETag: "blah;1234" + Cache-control: max-age=86400 + Content-Type: text/html + Content-Length: 227 + <h2>Multiple Choices:</h2> + <ul> + + + +Holtman & Mutz Experimental [Page 11] + +RFC 2295 Transparent Content Negotiation March 1998 + + + <li><a href=paper.1>HTML, English version</a> + <li><a href=paper.2>HTML, French version</a> + <li><a href=paper.3>Postscript, English version</a> + </ul> + + The Alternates header in the response contains the variant list. The + Vary header is included to ensure correct caching by plain HTTP/1.1 + caches (see section 10.6). The ETag header allows the response to be + revalidated by caches, the Cache-Control header controls this + revalidation. The HTML entity included in the response allows the + user to select the best variant by hand if desired. + +4.4 Optimizing the negotiation process + + The basic transparent negotiation scheme involves two HTTP + transactions: one to retrieve the list, and a second one to retrieve + the chosen variant. There are however several ways to `cut corners' + in the data flow path of the basic scheme. + + First, caching proxies can cache both variant lists and variants. + Such caching can reduce the communication overhead, as shown in the + following example: + + Server _____ proxy _____ proxy __________ user + x.org cache cache agent + + < -------------- + | GET ../paper + | + has the list + in cache + | + ------------- > [list response] + list | + | + choose + | + < -------------------------- + | GET ../paper.1 + | + has the variant + in cache + | + -------------------------- > [normal response] + return of paper.1 + + + + + + +Holtman & Mutz Experimental [Page 12] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Second, the user agent can send small Accept- headers, which may + contain enough information to allow the server to choose the best + variant and return it directly. + + Server _____ proxy _____ proxy _____ user + x.org cache cache agent + + < ---------------------------------- + | GET http://x.org/paper + | small Accept- headers + | + able to choose on + behalf of user agent + | + ---------------------------------- > [choice response] + return of paper.1 and list + + This choosing based on small Accept- headers is done with a `remote + variant selection algorithm'. Such an algorithm takes the variant + list and the Accept- headers as input. It then computes whether the + Accept- headers contain sufficient information to choose on behalf of + the user agent, and if so, which variant is the best variant. If the + best variant is a neighboring variant, it may be returned, together + with the variant list, in a choice response. + + A server may only choose on behalf of a user agent supporting + transparent content negotiation if the user agent explicitly allows + the use of a particular remote variant selection algorithm in the + Negotiate request header. User agents with sophisticated internal + variant selection algorithms may want to disallow a remote choice, or + may want to allow it only when retrieving inline images. If the + local algorithm of the user agent is superior in only some difficult + areas of negotiation, it is possible to enable the remote algorithm + for the easy areas only. More information about the use of a remote + variant selection algorithm can be found in [3]. + + Choice responses are covered in section 10.2. For example, the + choice response in the above picture could be: + + HTTP/1.1 200 OK + Date: Tue, 11 Jun 1996 20:05:31 GMT + TCN: choice + Content-Type: text/html + Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT + Content-Length: 5327 + Cache-control: max-age=604800 + Content-Location: paper.1 + Alternates: {"paper.1" 0.9 {type text/html} {language en}}, + + + +Holtman & Mutz Experimental [Page 13] + +RFC 2295 Transparent Content Negotiation March 1998 + + + {"paper.2" 0.7 {type text/html} {language fr}}, + {"paper.3" 1.0 {type application/postscript} + {language en}} + Etag: "gonkyyyy;1234" + Vary: negotiate, accept, accept-language + Expires: Thu, 01 Jan 1980 00:00:00 GMT + + <title>A paper about .... + + Finally, the above two kinds of optimization can be combined; a + caching proxy which has the list will sometimes be able to choose on + behalf of the user agent. This could lead to the following + communication pattern: + + Server _____ proxy _____ proxy __________ user + x.org cache cache agent + + < --------------- + | GET ../paper + | small Accept + | + able to choose + on behalf + | + < ---------- + | GET ../paper.1 + | + ---------- > [normal response] + paper.1 | + ---------------- > [choice response] + paper.1 and list + + Note that this cutting of corners not only saves bandwidth, it also + eliminates delays due to packet round trip times, and reduces the + load on the origin server. + +4.5 Downwards compatibility with non-negotiating user agents + + To handle requests from user agents which do not support transparent + content negotiation, this specification allows the origin server to + revert to a HTTP/1.0 style negotiation scheme. The specification of + heuristics for such schemes is beyond the scope of this document. + + + + + + + + + +Holtman & Mutz Experimental [Page 14] + +RFC 2295 Transparent Content Negotiation March 1998 + + +4.6 Retrieving a variant by hand + + It is always possible for a user agent to retrieve the variant list + which is bound to a negotiable resource. The user agent can use this + list to make available a menu of all variants and their + characteristics to the user. Such a menu allows the user to randomly + browse other variants, and makes it possible to manually correct any + sub-optimal choice made by the automatic negotiation process. + +4.7 Dimensions of negotiation + + Transparent content negotiation defines four dimensions of + negotiation: + + 1. Media type (MIME type) + 2. Charset + 3. Language + 4. Features + + The first three dimensions have traditionally been present in HTTP. + The fourth dimension is added by this specification. Additional + dimensions, beyond the four mentioned above, could be added by future + specifications. + + Negotiation on the content encoding of a response (gzipped, + compressed, etc.) is left outside of the realm of transparent + negotiation. See section 10.8 for more information. + +4.8 Feature negotiation + + Feature negotiation intends to provide for all areas of negotiation + not covered by the type, charset, and language dimensions. Examples + are negotiation on + + * HTML extensions + * Extensions of other media types + * Color capabilities of the user agent + * Screen size + * Output medium (screen, paper, ...) + * Preference for speed vs. preference for graphical detail + + The feature negotiation framework (section 6) is the principal means + by which transparent negotiation offers extensibility; a new + dimension of negotiation (really a sub-dimension of the feature + dimension) can be added without the need for a new standards effort + by the simple registration of a `feature tag'. + + + + + +Holtman & Mutz Experimental [Page 15] + +RFC 2295 Transparent Content Negotiation March 1998 + + +4.9 Length of variant lists + + As a general rule, variant lists should be short: it is expected that + a typical transparently negotiable resource will have 2 to 10 + variants, depending on its purpose. Variant lists should be short + for a number of reasons: + + 1. The user must be able to pick a variant by hand to correct a + bad automatic choice, and this is more difficult with a long + variant list. + + 2. A large number of variants will decrease the efficiency of + internet proxy caches. + + 3. Long variant lists will make some transparently negotiated + responses longer. + + In general, it is not desirable to create a transparently negotiable + resource with hundreds of variants in order to fine-tune the + graphical presentation of a resource. Any graphical fine-tuning + should be done, as much as possible, by using constructs which act at + the user agent side, for example + + <center><img src=titlebanner.gif width=100% + alt="MegaBozo Corp"></center> + + In order to promote user agent side fine tuning, which is more + scalable than fine tuning over the network, user agents which + implement a scripting language for content rendering are encouraged + to make the availability of this language visible for transparent + content negotiation, and to allow rendering scripts to access the + capabilities and preferences data used for content negotiation, as + far as privacy considerations permit this. + +4.10 Relation with other negotiation schemes + + The HTTP/1.x protocol suite allows for many different negotiation + mechanisms. Transparent content negotiation specializes in scalable, + interoperable negotiation of content representations at the HTTP + level. It is intended that transparent negotiation can co-exist with + other negotiation schemes, both open and proprietary, which cover + different application domains or work at different points in the + author-to-user chain. Ultimately, it will be up to the resource + author to decide which negotiation mechanism, or combination of + negotiation mechanisms, is most appropriate for the task at hand. + + + + + + +Holtman & Mutz Experimental [Page 16] + +RFC 2295 Transparent Content Negotiation March 1998 + + +5 Variant descriptions + +5.1 Syntax + + A variant can be described in a machine-readable way with a variant + description. + + variant-description = + "{" <"> URI <"> source-quality *variant-attribute"}" + + source-quality = qvalue + + variant-attribute = "{" "type" media-type "}" + | "{" "charset" charset "}" + | "{" "language" 1#language-tag "}" + | "{" "length" 1*DIGIT "}" + | "{" "features" feature-list "}" + | "{" "description" + quoted-string [ language-tag ] "}" + | extension-attribute + + extension-attribute = "{" extension-name extension-value "}" + extension-name = token + extension-value = *( token | quoted-string | LWS + | extension-specials ) + + extension-specials = + <any element of tspecials except <"> and "}"> + + The feature-list syntax is defined in section 6.4. + + Examples are + + {"paper.2" 0.7 {type text/html} {language fr}} + + {"paper.5" 0.9 {type text/html} {features tables}} + + {"paper.1" 0.001} + + The various attributes which can be present in a variant description + are covered in the subsections below. Each attribute may appear only + once in a variant description. + +5.2 URI + + The URI attribute gives the URI of the resource from which the + variant can be retrieved with a GET request. It can be absolute or + relative to the Request-URI. The variant resource may vary (on the + + + +Holtman & Mutz Experimental [Page 17] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Cookie request header, for example), but MUST NOT engage in + transparent content negotiation itself. + +5.3 Source-quality + + The source-quality attribute gives the quality of the variant, as a + representation of the negotiable resource, when this variant is + rendered with a perfect rendering engine on the best possible output + medium. + + If the source-quality is less than 1, it often expresses a quality + degradation caused by a lossy conversion to a particular data format. + For example, a picture originally in JPEG form would have a lower + source quality when translated to the XBM format, and a much lower + source quality when translated to an ASCII-art variant. Note + however, that degradation is a function of the source; an original + piece of ASCII-art may degrade in quality if it is captured in JPEG + form. + + The source-quality could also represent a level of quality caused by + skill of language translation, or ability of the used media type to + capture the intended artistic expression. + + Servers should use the following table a guide when assigning source + quality values: + + 1.000 perfect representation + 0.900 threshold of noticeable loss of quality + 0.800 noticeable, but acceptable quality reduction + 0.500 barely acceptable quality + 0.300 severely degraded quality + 0.000 completely degraded quality + + The same table can be used by local variant selection algorithms (see + appendix 19) when assigning degradation factors for different content + rendering mechanisms. Note that most meaningful values in this table + are close to 1. This is due to the fact that quality factors are + generally combined by multiplying them, not by adding them. + + When assigning source-quality values, servers should not account for + the size of the variant and its impact on transmission and rendering + delays; the size of the variant should be stated in the length + attribute and any size-dependent calculations should be done by the + variant selection algorithm. Any constant rendering delay for a + particular media type (for example due to the startup time of a + helper application) should be accounted for by the user agent, when + assigning a quality factor to that media type. + + + + +Holtman & Mutz Experimental [Page 18] + +RFC 2295 Transparent Content Negotiation March 1998 + + +5.4 Type, charset, language, and length + + The type attribute of a variant description carries the same + information as its Content-Type response header counterpart defined + in [1], except for any charset information, which MUST be carried in + the charset attribute. For, example, the header + + Content-Type: text/html; charset=ISO-8859-4 + + has the counterpart attributes + + {type text/html} {charset ISO-8859-4} + + The language and length attributes carry the same information as + their Content-* response header counterparts in [1]. The length + attribute, if present, MUST thus reflect the length of the variant + alone, and not the total size of the variant and any objects inlined + or embedded by the variant. + + Though all of these attributes are optional, it is often desirable to + include as many attributes as possible, as this will increase the + quality of the negotiation process. + + Note: A server is not required to maintain a one-to-one + correspondence between the attributes in the variant description + and the Content-* headers in the variant response. For example, + if the variant description contains a language attribute, the + response does not necessarily have to contain a Content-Language + header. If a Content-Language header is present, it does not have + to contain an exact copy of the information in the language + attribute. + +5.5 Features + + The features attribute specifies how the presence or absence of + particular feature tags in the user agent affects the overall quality + of the variant. This attribute is covered in section 6.4. + +5.6 Description + + The description attribute gives a textual description of the variant. + It can be included if the URI and normal attributes of a variant are + considered too opaque to allow interpretation by the user. If a user + agent is showing a menu of available variants compiled from a variant + list, and if a variant has a description attribute, the user agent + SHOULD show the description attribute of the variant instead of + showing the normal attributes of the variant. The description field + uses the UTF-8 character encoding scheme [5], which is a superset of + + + +Holtman & Mutz Experimental [Page 19] + +RFC 2295 Transparent Content Negotiation March 1998 + + + US-ASCII, with ""%" HEX HEX" encoding. The optional language tag MAY + be used to specify the language used in the description text. + +5.7 Extension-attribute + + The extension-attribute allows future specifications to incrementally + define dimensions of negotiation which cannot be created by using the + feature negotiation framework, and eases content negotiation + experiments. In experimental situations, servers MUST ONLY generate + extension-attributes whose names start with "x-". User agents SHOULD + ignore all extension attributes they do not recognize. Proxies MUST + NOT run a remote variant selection algorithm if an unknown extension + attribute is present in the variant list. + +6 Feature negotiation + + This section defines the feature negotiation mechanism. Feature + negotiation has been introduced in section 4.8. Appendix 19 contains + examples of feature negotiation. + +6.1 Feature tags + + A feature tag (ftag) identifies something which can be negotiated on, + for example a property (feature) of a representation, a capability + (feature) of a user agent, or the preference of a user for a + particular type of representation. The use of feature tags need not + be limited to transparent content negotiation, and not every feature + tag needs to be usable in the HTTP transparent content negotiation + framework. + + ftag = token | quoted-string + + Note: A protocol-independent system for feature tag registration + is currently being developed in the IETF. This specification does + not define any feature tags. In experimental situations, the use + of tags which start with "x." is encouraged. + + Feature tags are used in feature sets (section 6.2) and in feature + predicates (section 6.3). Feature predicates are in turn used in + features attributes (section 6.4), which are used in variant + descriptions (section 5). Variant descriptions can be transmitted in + Alternates headers (section 8.3). + + The US-ASCII charset is used for feature tags. Feature tag + comparison is case-insensitive. A token tag XYZ is equal to a + quoted-string tag "XYZ". Examples are + + tables, fonts, blebber, wolx, screenwidth, colordepth + + + +Holtman & Mutz Experimental [Page 20] + +RFC 2295 Transparent Content Negotiation March 1998 + + + An example of the use of feature tags in a variant description is: + + {"index.html" 1.0 {type text/html} {features tables frames}} + + This specification follows general computing practice in that it + places no restrictions on what may be called a feature. At the + protocol level, this specification does not distinguish between + different uses of feature tags: a tag will be processed in the same + way, no matter whether it identifies a property, capability, or + preference. For some tags, it may be fluid whether the tag + represents a property, preference, or capability. For example, in + content negotiation on web pages, a "textonly" tag would identify a + capability of a text-only user agent, but the user of a graphical + user agent may use this tag to specify that text-only content is + preferred over graphical content. + +6.1.1 Feature tag values + + The definition of a feature tag may state that a feature tag can have + zero, one, or more values associated with it. These values + specialize the meaning of the tag. For example, a feature tag + `paper' could be associated with the values `A4' and `A5'. + + tag-value = token | quoted-string + + The US-ASCII charset is used for feature tag values. Equality + comparison for tag values MUST be done with a case-sensitive, octet- + by-octet comparison, where any ""%" HEX HEX" encodings MUST be + processed as in [1]. A token value XYZ is equal to a quoted-string + value "XYZ". + +6.2 Feature sets + + The feature set of a user agent is a data structure which records the + capabilities of the user agent and the preferences of the user. + + Feature sets are used by local variant selection algorithms (see + appendix 19 for an example). A user agent can use the Accept- + Features header (section 8.2) to make some of the contents of its + feature set known to remote variant selection algorithms. + + Structurally, a feature set is a possibly empty set, containing + records of the form + + ( feature tag , set of feature tag values ) + + + + + + +Holtman & Mutz Experimental [Page 21] + +RFC 2295 Transparent Content Negotiation March 1998 + + + If a record with a feature tag is present in the set, this means that + the user agent implements the corresponding capability, or that the + user has expressed the corresponding preference. + + Each record in a feature set has a, possibly empty, set of tag + values. For feature tags which cannot have values associated with + it, this set is always empty. For feature tags which can have zero, + one, or more values associated with it, this set contains those + values currently associated with the tag. If the set of a feature + tag T has the value V in it, it is said that `the tag T is present + with the value V'. + + This specification does not define a standard notation for feature + sets. An example of a very small feature set, in a mathematical + notation, is + + { ( "frames" , { } ) , + ( "paper" , { "A4" , "A5" } ) + } + + As feature registration is expected to be an ongoing process, it is + generally not possible for a user agent to know the meaning of all + feature tags it can possibly encounter in a variant description. A + user agent SHOULD treat all features tags unknown to it as absent + from its feature set. + + A user agent may change the contents of its feature set depending on + the type of request, and may also update it to reflect changing + conditions, for example a change in the window size. Therefore, when + considering feature negotiation, one usually talks about `the feature + set of the current request'. + +6.3 Feature predicates + + Feature predicates are predicates on the contents of feature sets. + They appear in the features attribute of a variant description. + + fpred = [ "!" ] ftag + | ftag ( "=" | "!=" ) tag-value + | ftag "=" "[" numeric-range "]" + + numeric-range = [ number ] "-" [ number ] + + Feature predicates are used in features attributes (section 6.4), + which are used in variant descriptions (section 5). Variant + descriptions can be transmitted in Alternates headers (section 8.3). + + + + + +Holtman & Mutz Experimental [Page 22] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Examples of feature predicates are + + blebber, !blebber, paper=a4, colordepth=5, blex!=54, + dpi=[300-599], colordepth=[24-] + + Using the feature set of the current request, a user agent SHOULD + compute the truth value of the different feature predicates as + follows. + + ftag true if the feature is present, false otherwise + + !ftag true if the feature is absent, false otherwise + + ftag=V true if the feature is present with the value V, + false otherwise, + + ftag!=V true if the feature is not present with the value V, + false otherwise, + + ftag=[N-M] true if the feature is present with at least one + numeric value, while the highest value with which it + is present in the range N-M, false otherwise. If N + is missing, the lower bound is 0. If M is missing, + the upper bound is infinity. + + As an example, with the feature set + + { ( "blex" , { } ), + ( "colordepth" , { "5" } ), + ( "UA-media" , { "stationary" } ), + ( "paper" , { "A4", "A3" } ) , + ( "x-version" , { "104", "200" } ) + } + + the following predicates are true: + + blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, UA- + media=stationary, UA-media!=screen, paper=A4, paper =!A0, + colordepth=[ 4 - 6 ], x-version=[100-300], x-version=[200-300] + + and the following predicates are false: + + !blex, blebber, colordepth=6, colordepth=foo, !colordepth, + screenwidth, screenwidth=640, screenwidth!=640, x-version=99, UA- + media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta + + + + + + +Holtman & Mutz Experimental [Page 23] + +RFC 2295 Transparent Content Negotiation March 1998 + + +6.4 Features attribute + + The features attribute, for which section 5.1 defines the syntax + + "{" "features" feature-list "}" + + is used in a variant description to specify how the presence or + absence of particular feature tags in the user agent affects the + overall quality of the variant. + + feature-list = 1%feature-list-element + + feature-list-element = ( fpred | fpred-bag ) + [ ";" [ "+" true-improvement ] + [ "-" false-degradation ] + ] + + fpred-bag = "[" 1%fpred "]" + + true-improvement = short-float + false-degradation = short-float + + Features attributes are used in variant descriptions (section 5). + Variant descriptions can be transmitted in Alternates headers + (section 8.3). + + Examples are: + + {features !textonly [blebber !wolx] colordepth=3;+0.7} + + {features !blink;-0.5 background;+1.5 [blebber !wolx];+1.4-0.8} + + The default value for the true-improvement is 1. The default value + for the false-degradation is 0, or 1 if a true-improvement value is + given. + + A user agent SHOULD, and a remote variant selection algorithm MUST + compute the quality degradation factor associated with the features + attribute by multiplying all quality degradation factors of the + elements of the feature-list. Note that the result can be a factor + greater than 1. + + A feature list element yields its true-improvement factor if the + corresponding feature predicate is true, or if at least one element + of the corresponding fpred-bag is true. The element yields its + false-degradation factor otherwise. + + + + + +Holtman & Mutz Experimental [Page 24] + +RFC 2295 Transparent Content Negotiation March 1998 + + +7 Remote variant selection algorithms + + A remote variant selection algorithm is a standardized algorithm by + which a server can choose a best variant on behalf of a negotiating + user agent. The use of a remote algorithm can speed up the + negotiation process by eliminating a request-response round trip. + + A remote algorithm typically computes whether the Accept- headers in + the request contain sufficient information to allow a choice, and if + so, which variant is the best variant. This specification does not + define any remote algorithms, but does define a mechanism to + negotiate on the use of such algorithms. + +7.1 Version numbers + + A version numbering scheme is used to distinguish between different + remote variant selection algorithms. + + rvsa-version = major "." minor + + major = 1*4DIGIT + minor = 1*4DIGIT + + An algorithm with the version number X.Y, with Y>0, MUST be downwards + compatible with all algorithms from X.0 up to X.Y. Downwards + compatibility means that, if supplied with the same information, the + newer algorithm MUST make the same choice, or a better choice, as the + old algorithm. There are no compatibility requirements between + algorithms with different major version numbers. + +8 Content negotiation status codes and headers + + This specification adds one new HTTP status code, and introduces six + new HTTP headers. It also extends the semantics of an existing + HTTP/1.1 header. + +8.1 506 Variant Also Negotiates + + The 506 status code indicates that the server has an internal + configuration error: the chosen variant resource is configured to + engage in transparent content negotiation itself, and is therefore + not a proper end point in the negotiation process. + + + + + + + + + +Holtman & Mutz Experimental [Page 25] + +RFC 2295 Transparent Content Negotiation March 1998 + + +8.2 Accept-Features + + The Accept-Features request header can be used by a user agent to + give information about the presence or absence of certain features in + the feature set of the current request. Servers can use this + information when running a remote variant selection algorithm. + + Note: the name `Accept-Features' for this header was chosen + because of symmetry considerations with other Accept- headers, + even though the Accept-Features header will generally not contain + an exhaustive list of features which are somehow `accepted'. A + more accurate name of this header would have been `Feature-Set- + Info'. + + Accept-Features = "Accept-Features" ":" + #( feature-expr *( ";" feature-extension ) ) + + feature-expr = [ "!" ] ftag + | ftag ( "=" | "!=" ) tag-value + | ftag "=" "{" tag-value "}" + | "*" + + feature-extension = token [ "=" ( token | quoted-string ) ] + + No feature extensions are defined in this specification. An example + is: + + Accept-Features: blex, !blebber, colordepth={5}, !screenwidth, + paper = A4, paper!="A2", x-version=104, * + + The different feature expressions have the following meaning: + + ftag ftag is present + + !ftag ftag is absent + + ftag=V ftag is present with the value V + + ftag!=V ftag is present, but not with the value V + + ftag={V} ftag is present with the value V, and not with any + other values + + * the expressions in this header do not fully describe + the feature set: feature tags not mentioned in this + header may also be present, and, except for the case + ftag={V}, tags may be present with more values than + mentioned. + + + +Holtman & Mutz Experimental [Page 26] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Absence of the Accept-Features header in a request is equivalent to + the inclusion of + + Accept-Features: * + + By using the Accept-Features header, a remote variant selection + algorithm can sometimes determine the truth value of a feature + predicate on behalf of the user agent. For example, with the header + + Accept-Features: blex, !blebber, colordepth={5}, !screenwidth, + paper = A4, paper!="A2", x-version=104, * + + the algorithm can determine that the following predicates are true: + + blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, + paper=A4, colordepth=[4-6] + + and that the following predicates are false: + + !blex, blebber, colordepth=6, colordepth=foo, !colordepth, + screenwidth, screenwidth=640, screenwidth!=640, + + but the truth value of the following predicates cannot be + determined: + + UA-media=stationary, UA-media!=screen, paper!=a0, + x-version=[100-300], x-version=[200-300], x-version=99, + UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta + +8.3 Alternates + + The Alternates response header is used to convey the list of variants + bound to a negotiable resource. This list can also include + directives for any content negotiation process. If a response from a + transparently negotiable resource includes an Alternates header, this + header MUST contain the complete variant list bound to the negotiable + resource. Responses from resources which do not support transparent + content negotiation MAY also use Alternates headers. + + Alternates = "Alternates" ":" variant-list + + variant-list = 1#( variant-description + | fallback-variant + | list-directive ) + + fallback-variant = "{" <"> URI <"> "}" + + list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> ) + + + +Holtman & Mutz Experimental [Page 27] + +RFC 2295 Transparent Content Negotiation March 1998 + + + | extension-list-directive + + extension-list-directive = + token [ "=" ( token | quoted-string ) ] + + An example is + + Alternates: {"paper.1" 0.9 {type text/html} {language en}}, + {"paper.2" 0.7 {type text/html} {language fr}}, + {"paper.3" 1.0 {type application/postscript} + {language en}}, + proxy-rvsa="1.0, 2.5" + + Any relative URI specified in a variant-description or fallback- + variant field is relative to the request-URI. Only one fallback- + variant field may be present. If the variant selection algorithm of + the user agent finds that all described variants are unacceptable, + then it SHOULD choose the fallback variant, if present, as the best + variant. If the user agent computes the overall quality values of + the described variants, and finds that several variants share the + highest value, then the first variant with this value in the list + SHOULD be chosen as the best variant. + + The proxy-rvsa directive restricts the use of remote variant + selection algorithms by proxies. If present, a proxy MUST ONLY use + algorithms which have one of the version numbers listed, or have the + same major version number and a higher minor version number as one of + the versions listed. Any restrictions set by proxy-rvsa come on top + of the restrictions set by the user agent in the Negotiate request + header. The directive proxy-rvsa="" will disable variant selection + by proxies entirely. Clients SHOULD ignore all extension-list- + directives they do not understand. + + A variant list may contain multiple differing descriptions of the + same variant. This can be convenient if the variant uses conditional + rendering constructs, or if the variant resource returns multiple + representations using a multipart media type. + +8.4 Negotiate + + The Negotiate request header can contain directives for any content + negotiation process initiated by the request. + + Negotiate = "Negotiate" ":" 1#negotiate-directive + + negotiate-directive = "trans" + | "vlist" + | "guess-small" + + + +Holtman & Mutz Experimental [Page 28] + +RFC 2295 Transparent Content Negotiation March 1998 + + + | rvsa-version + | "*" + | negotiate-extension + + negotiate-extension = token [ "=" token ] + + Examples are + + Negotiate: 1.0, 2.5 + Negotiate: * + + The negotiate directives have the following meaning + + "trans" + The user agent supports transparent content negotiation for + the current request. + + "vlist" + The user agent requests that any transparently negotiated + response for the current request includes an Alternates + header with the variant list bound to the negotiable resource. + Implies "trans". + + "guess-small" + The user agent allows origin servers to run a custom algorithm + which guesses the best variant for the request, and to return + this variant in a choice response, if the resulting choice + response is smaller than or not much larger than a list + response. The definition of `not much larger' is left to + origin server heuristics. Implies "vlist" and "trans". + + rvsa-version + The user agent allows origin servers and proxies to run the + remote variant selection algorithm with the indicated version + number, or with the same major version number and a higher + minor version number. If the algorithm has sufficient + information to choose a best, neighboring variant, the origin + server or proxy MAY return a choice response with this + variant. Implies "trans". + + "*" + The user agent allows origin servers and proxies to run any + remote variant selection algorithm. The origin server may + even run algorithms which have not been standardized. If the + algorithm has sufficient information to choose a best, + neighboring variant, the origin server or proxy MAY return a + choice response with this variant. Implies "trans". + + + + +Holtman & Mutz Experimental [Page 29] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Servers SHOULD ignore all negotiate-directives they do not + understand. If the Negotiate header allows a choice between multiple + remote variant selection algorithms which are all supported by the + server, the server SHOULD use some internal precedence heuristics to + select the best algorithm. + +8.5 TCN + + The TCN response header is used by a server to signal that the + resource is transparently negotiated. + + TCN = "TCN" ":" #( response-type + | server-side-override-directive + | tcn-extension ) + + response-type = "list" | "choice" | "adhoc" + + server-side-override-directive = "re-choose" | "keep" + + tcn-extension = token [ "=" ( token | quoted-string ) ] + + If the resource is not transparently negotiated, a TCN header MUST + NOT be included in any response. If the resource is transparently + negotiated, a TCN header, which includes the response-type value of + the response, MUST be included in every response with a 2xx status + code or any 3xx status code, except 304, in which it MAY be included. + A TCN header MAY also be included, without a response-type value, in + other responses from transparently negotiated resources. + + A server-side override directive MUST be included if the origin + server performed a server-side override when choosing the response. + If the directive is "re-choose", the server MUST include an + Alternates header with the variant bound to the negotiable resource + in the response, and user agent SHOULD use its internal variant + selection algorithm to choose, retrieve, and display the best variant + from this list. If the directive is "keep" the user agent SHOULD NOT + renegotiate on the response, but display it directly, or act on it + directly if it is a redirection response. + + Clients SHOULD ignore all tcn-extensions they do not understand. + +8.6 Variant-Vary + + The Variant-Vary response header can be used in a choice response to + record any vary information which applies to the variant data (the + entity body combined with some of the entity headers) contained in + the response, rather than to the response as a whole. + + + + +Holtman & Mutz Experimental [Page 30] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name ) + + Use of the Variant-Vary header is discussed in section 10.2. + +9 Cache validators + + To allow for correct and efficient caching and revalidation of + negotiated responses, this specification extends the caching model of + HTTP/1.1 [1] in various ways. + + This specification does not introduce a `variant-list-max-age' + directive which explicitly bounds the freshness lifetime of a cached + variant list, like the `max-age' Cache-Control directive bounds the + freshness lifetime of a cached response. However, this specification + does ensure that a variant list which is sent at a time T by the + origin server will never be re-used without revalidation by + semantically transparent caches after the time T+M. This M is the + maximum of all freshness lifetimes assigned (using max-age directives + or Expires headers) by the origin server to + + a. the responses from the negotiable resource itself, and + + b. the responses from its neighboring variant resources + + If no freshness lifetimes are assigned by the origin server, M is the + maximum of the freshness lifetimes which were heuristically assigned + by all caches which can re-use the variant list. + +9.1 Variant list validators + + A variant list validator is an opaque value which acts as the cache + validator of a variant list bound to a negotiable resource. + + variant-list-validator = <quoted-string not containing any ";"> + + If two responses contain the same variant list validator, a cache can + treat the Alternates headers in these responses as equivalent (though + the headers themselves need not be identical). + +9.2 Structured entity tags + + A structured entity tag consists of a normal entity tag of which the + opaque string is extended with a semicolon followed by the text + (without the surrounding quotes) of a variant list validator: + + + + + + + +Holtman & Mutz Experimental [Page 31] + +RFC 2295 Transparent Content Negotiation March 1998 + + + normal | variant list | structured + entity tag | validator | entity tag + -------------+----------------+----------------- + "etag" | "vlv" | "etag;vlv" + W/"etag" | "vlv" | W/"etag;vlv" + + Note that a structured entity tag is itself also an entity tag. The + structured nature of the tag allows caching proxies capable of + transparent content negotiation to perform some optimizations defined + in section 10. When not performing such optimizations, a structured + tag SHOULD be treated as a single opaque value, according to the + general rules in HTTP/1.1. Examples of structured entity tags are: + + "xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234" + + In the last example, the normal entity tag is "a;b;c;" and the + variant list validator is "1234". + + If a transparently negotiated response includes an entity tag, it + MUST be a structured entity tag. The variant list validator in the + structured tag MUST act as a validator for the variant list contained + in the Alternates header. The normal entity tag in the structured + tag MUST act as a validator of the entity body in the response and of + all entity headers except Alternates. + +9.3 Assigning entity tags to variants + + To allow for correct revalidation of transparently negotiated + responses by clients, origin servers SHOULD generate all normal + entity tags for the neighboring variant resources of the negotiable + resource in such a way that + + 1. the same tag is never used by two different variants, + unless this tag labels exactly the same entity on all occasions, + + 2. if one normal tag "X" is a prefix of another normal tag "XY", + then "Y" must never be a semicolon followed by a variant list + validator. + +10 Content negotiation responses + + If a request on a transparently negotiated resource yields a response + with a 2xx status code or any 3xx status code except 304, this + response MUST always be either a list response, a choice response, or + an adhoc response. These responses MUST always include a TCN header + which specifies their type. Transparently negotiated responses with + other status codes MAY also include a TCN header. + + + + +Holtman & Mutz Experimental [Page 32] + +RFC 2295 Transparent Content Negotiation March 1998 + + + The conditions under which the different content negotiation + responses may be sent are defined in section 12.1 for origin servers + and in section 13 for proxies. + + After having constructed a list, choice, or adhoc response, a server + MAY process any If-No-Match or If-Range headers in the request + message and shorten the response to a 304 (Not Modified) or 206 + (Partial Content) response, following the rules in the HTTP/1.1 + specification [1]. In this case, the entity tag of the shortened + response will identify it indirectly as a list, choice, or adhoc + response. + +10.1 List response + + A list response returns the variant list of the negotiable resource, + but no variant data. It can be generated when the server does not + want to, or is not allowed to, return a particular best variant for + the request. If the user agent supports transparent content + negotiation, the list response will cause it to select a best variant + and retrieve it. + + A list response MUST contain (besides the normal headers required by + HTTP) a TCN header which specifies the "list" response-type, the + Alternates header bound to the negotiable resource, a Vary header and + (unless it was a HEAD request) an entity body which allows the user + to manually select the best variant. + + An example of a list response is + + HTTP/1.1 300 Multiple Choices + Date: Tue, 11 Jun 1996 20:02:21 GMT + TCN: list + Alternates: {"paper.1" 0.9 {type text/html} {language en}}, + {"paper.2" 0.7 {type text/html} {language fr}}, + {"paper.3" 1.0 {type application/postscript} + {language en}} + Vary: negotiate, accept, accept-language + ETag: "blah;1234" + Cache-control: max-age=86400 + Content-Type: text/html + Content-Length: 227 + + <h2>Multiple Choices:</h2> + <ul> + <li><a href=paper.1>HTML, English version</a> + <li><a href=paper.2>HTML, French version</a> + <li><a href=paper.3>Postscript, English version</a> + </ul> + + + +Holtman & Mutz Experimental [Page 33] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Note: A list response can have any status code, but the 300 + (Multiple Choices) code is the most appropriate one for HTTP/1.1 + clients. Some existing versions of HTTP/1.0 clients are known to + silently ignore 300 responses, instead of handling them according + to the HTTP/1.0 specification [2]. Servers should therefore be + careful in sending 300 responses to non-negotiating HTTP/1.0 user + agents, and in making these responses cacheable. The 200 (OK) + status code can be used instead. + + The Vary header in the response SHOULD ensure correct handling by + plain HTTP/1.1 caching proxies. This header can either be + + Vary: * + + or a more elaborate header; see section 10.6.1. + + Only the origin server may construct list responses. Depending on + the status code, a list response is cacheable unless indicated + otherwise. + + According to the HTTP/1.1 specification [1], a user agent which does + not support transparent content negotiation will, when receiving a + list response with the 300 status code, display the entity body + included in the response. If the response contains a Location + header, however, the user agent MAY automatically redirect to this + location. + + The handling of list responses by clients supporting transparent + content negotiation is described in sections 11.1 and 13. + +10.2 Choice response + + A choice response returns a representation of the best variant for + the request, and may also return the variant list of the negotiable + resource. It can be generated when the server has sufficient + information to be able to choose the best variant on behalf the user + agent, but may only be generated if this best variant is a + neighboring variant. For request from user agents which do not + support transparent content negotiation, a server may always generate + a choice response, provided that the variant returned is a + neighboring variant. The variant returned in a choice response need + not necessarily be listed in the variant list bound to the negotiable + resource. + + + + + + + + +Holtman & Mutz Experimental [Page 34] + +RFC 2295 Transparent Content Negotiation March 1998 + + + A choice response merges a normal HTTP response from the chosen + variant, a TCN header which specifies the "choice" response-type, and + a Content-Location header giving the location of the variant. + Depending on the status code, a choice response is cacheable unless + indicated otherwise. + + Origin servers and proxy caches MUST construct choice responses with + the following algorithm (or any other algorithm which gives equal end + results for the client). + + In this algorithm, `the current Alternates header' refers to the + Alternates header containing the variant list which was used to + choose the best variant, and `the current variant list validator' + refers to the validator of this list. Section 10.4 specifies how + these two items can be obtained by a proxy cache. + + The algorithm consists of four steps. + + 1. Construct a HTTP request message on the best variant resource + by rewriting the request-URI and Host header (if appropriate) of + the received request message on the negotiable resource. + + 2. Generate a valid HTTP response message, but not one with the + 304 (Not Modified) code, for the request message constructed in + step 1. + + In a proxy cache, the response can be obtained from cache + memory, or by passing the constructed HTTP request towards the + origin server. If the request is passed on, the proxy MAY add, + modify, or delete If-None-Match and If-Range headers to optimize + the transaction with the upstream server. + + Note: the proxy should be careful not to add entity tags of + non-neighboring variants to If-* (conditional) headers of the + request, as there are no global uniqueness requirements for + these tags. + + 3. Only in origin servers: check for an origin server + configuration error. If the HTTP response message generated in + step 2 contains a TCN header, then the best variant resource is + not a proper end point in the transparent negotiation process, + and a 506 (Variant Also Negotiates) error response message + SHOULD be generated instead of going to step 4. + + 4. Add a number of headers to the HTTP response message generated + in step 2. + + + + + +Holtman & Mutz Experimental [Page 35] + +RFC 2295 Transparent Content Negotiation March 1998 + + + a. Add a TCN header which specifies the "choice" + response-type. + + b. Add a Content-Location header giving the location of the + chosen variant. Delete any Content-Location header which was + already present. + + Note: According to the HTTP/1.1 specification [1], if the + Content-Location header contains a relative URI, this URI + is relative to the URI in the Content-Base header, if + present, and relative to the request-URI if no Content- + Base header is present. + + c. If any Vary headers are present in the response message + from step 2, add, for every Vary header, a Variant-Vary + header with a copy of the contents of this Vary header. + + d. Delete any Alternates headers which are present in in the + response. Now, the current Alternates header MUST be added + if this is required by the Negotiate request header, or if + the server returns "re-choose" in the TCN response header. + Otherwise, the current Alternates header MAY be added. + + Note: It is usually a good strategy to always add the + current Alternates header, unless it is very large + compared to the rest of the response. + + e. Add a Vary header to ensure correct handling by plain + HTTP/1.1 caching proxies. This header can either be + + Vary: * + or a more elaborate header, see section 10.6. + + f. To ensure compatibility with HTTP/1.0 caching proxies which + do not recognize the Vary header, an Expires header with a + date in the past MAY be added. See section 10.7 for more + information. + + g. If an ETag header is present in the response message from + step 2, then extend the entity tag in that header with the + current variant list validator, as specified in section 9.2. + + Note: Step g. is required even if the variant list itself + is not added in step d. + + h. Only in proxy caches: set the Age header of the response to + + max( variant_age , alternates_age ) + + + +Holtman & Mutz Experimental [Page 36] + +RFC 2295 Transparent Content Negotiation March 1998 + + + where variant_age is the age of the variant response obtained + in step 2, calculated according to the rules in the HTTP/1.1 + specification [1], and alternates_age is the age of the + Alternates header added in step d, calculated according to + the rules in section 10.4. + + Note that a server can shorten the response produced by the above + algorithm to a 304 (Not Modified) response if an If-None-Match header + in the original request allows it. If this is the case, an + implementation of the above algorithm can avoid the unnecessary + internal construction of full response message in step 2, it need + only construct the parts which end up in the final 304 response. A + proxy cache which implements this optimization can sometimes generate + a legal 304 response even if it has not cached the variant data + itself. + + An example of a choice response is: + + HTTP/1.1 200 OK + Date: Tue, 11 Jun 1996 20:05:31 GMT + TCN: choice + Content-Type: text/html + Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT + Content-Length: 5327 + Cache-control: max-age=604800 + Content-Location: paper.1 + Alternates: {"paper.1" 0.9 {type text/html} {language en}}, + {"paper.2" 0.7 {type text/html} {language fr}}, + {"paper.3" 1.0 {type application/postscript} + {language en}} + Etag: "gonkyyyy;1234" + Vary: negotiate, accept, accept-language + Expires: Thu, 01 Jan 1980 00:00:00 GMT + + <title>A paper about .... + +10.3 Adhoc response + + An adhoc response can be sent by an origin server as an extreme + measure, to achieve compatibility with a non-negotiating or buggy + client if this compatibility cannot be achieved by sending a list or + choice response. There are very little requirements on the contents + of an adhoc response. An adhoc response MUST have a TCN header which + specifies the "adhoc" response-type, and a Vary header if the + response is cacheable. It MAY contain the Alternates header bound to + the negotiable resource. + + + + + +Holtman & Mutz Experimental [Page 37] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Any Vary header in the response SHOULD ensure correct handling by + plain HTTP/1.1 caching proxies. This header can either be + + Vary: * + + or a more elaborate header, see section 10.6.1. Depending on the + status code, an adhoc response is cacheable unless indicated + otherwise. + + As an example of the use of an adhoc response, suppose that the + variant resource "redirect-to-blah" yields redirection (302) + responses. A choice response with this variant could look as + follows: + + HTTP/1.1 302 Moved Temporarily + Date: Tue, 11 Jun 1996 20:02:28 GMT + TCN: choice + Content-location: redirect-to-blah + Location: http://blah.org/ + Content-Type: text/html + Content-Length: 62 + + This document is available <a href=http://blah.org/>here</a>. + + Suppose that the server knows that the receiving user agent has a + bug, which causes it to crash on responses which contain both a + Content-Location and a Location header. The server could then work + around this bug by performing a server-side override and sending the + following adhoc response instead: + + HTTP/1.1 302 Moved Temporarily + Date: Tue, 11 Jun 1996 20:02:28 GMT + TCN: adhoc, keep + Location: http://blah.org/ + Content-Type: text/html + Content-Length: 62 + + This document is available <a href=http://blah.org/>here</a>. + +10.4 Reusing the Alternates header + + If a proxy cache has available a negotiated response which is + cacheable, fresh, and has ETag and Alternates headers, then it MAY + extract the Alternates header and associated variant list validator + from the response, and reuse them (without unnecessary delay) to + + + + + + +Holtman & Mutz Experimental [Page 38] + +RFC 2295 Transparent Content Negotiation March 1998 + + + negotiate on behalf of the user agent (section 13) or to construct a + choice response (section 10.2). The age of the extracted Alternates + header is the age of the response from which it is extracted, + calculated according to the rules in the HTTP/1.1 specification [1]. + +10.5 Extracting a normal response from a choice response + + If a proxy receives a choice response, it MAY extract and cache the + normal HTTP response contained therein. The normal response can be + extracted by taking a copy of the choice response and then deleting + any Content-Location, Alternates, and Vary headers, renaming any + Variant-Vary headers to Vary headers, and shortening the structured + entity tag in any ETag header to a normal entity tag. + + This normal response MAY be cached (as a HTTP response to the variant + request as constructed in step 1. of section 10.2) and reused to + answer future direct requests on the variant resource, according to + the rules in the HTTP/1.1 specification [1]. + + Note: The caching of extracted responses can decrease the upstream + bandwidth usage with up to a factor 2, because two independent + HTTP/1.1 cache entries, one associated with the negotiable + resource URI and one with the variant URI, are created in the same + transaction. Without this optimization, both HTTP/1.1 cache + entries can only be created by transmitting the variant data + twice. + + For security reasons (see section 14.2), an extracted normal response + MUST NEVER be cached if belongs to a non-neighboring variant + resource. If the choice response claims to contain data for a non- + neighboring variant resource, the proxy SHOULD reject the choice + response as a probable spoofing attempt. + +10.6 Elaborate Vary headers + + If a HTTP/1.1 [1] server can generate varying responses for a request + on some resource, then the server MUST include a Vary header in these + responses if they are cacheable. This Vary header is a signal to + HTTP/1.1 caches that something special is going on. It prevents the + caches from returning the currently chosen response for every future + request on the resource. + + Servers engaging in transparent content negotiation will generate + varying responses. Therefore, cacheable list, choice, and adhoc + responses MUST always include a Vary header. + + + + + + +Holtman & Mutz Experimental [Page 39] + +RFC 2295 Transparent Content Negotiation March 1998 + + + The most simple Vary header which can be included is + + Vary: * + + This header leaves the way in which the response is selected by the + server completely unspecified. + + A more elaborate Vary header MAY be used to allow for certain + optimizations in HTTP/1.1 caches which do not have specific + optimizations for transparent content negotiation, but which do cache + multiple variant responses for one resource. Such a more elaborate + Vary header lists all request headers which can be used by the server + when selecting a response for a request on the resource. + +10.6.1 Construction of an elaborate Vary header + + Origin servers can construct a more elaborate Vary header in the + following way. First, start with the header + + Vary: negotiate + + `negotiate' is always included because servers use the information in + the Negotiate header when choosing between a list, choice, or adhoc + response. + + Then, if any of the following attributes is present in any variant + description in the Alternates header, add the corresponding header + name to the Vary header + + attribute | header name to add + -----------+--------------------- + type | accept + charset | accept-charset + language | accept-language + features | accept-features + + + The Vary header constructed in this way specifies the response + variation which can be caused by the use of a variant selection + algorithm in proxies. If the origin server will in some cases, for + example if contacted by a non-negotiating user agent, use a custom + negotiation algorithm which takes additional headers into account, + these names of these headers SHOULD also be added to the Vary header. + + + + + + + + +Holtman & Mutz Experimental [Page 40] + +RFC 2295 Transparent Content Negotiation March 1998 + + +10.6.2 Caching of an elaborate Vary header + + A proxy cache cannot construct an elaborate vary header using the + method above, because this method requires exact knowledge of any + custom algorithms present in the origin server. However, when + extracting an Alternates header from a response (section 10.4) caches + MAY also extract the Vary header in the response, and reuse it along + with the Alternates header. A clean Vary header can however only be + extracted if the variant does not vary itself, i.e. if a Variant-Vary + header is absent. + +10.7 Adding an Expires header for HTTP/1.0 compatibility + + To ensure compatibility with HTTP/1.0 caching proxies which do not + recognize the Vary header, an Expires header with a date in the past + can be added to the response, for example + + Expires: Thu, 01 Jan 1980 00:00:00 GMT + + If this is done by an origin server, the server SHOULD usually also + include a Cache-Control header for the benefit of HTTP/1.1 caches, + for example + + Cache-Control: max-age=604800 + + which overrides the freshness lifetime of zero seconds specified by + the included Expires header. + + Note: This specification only claims downwards compatibility with + the HTTP/1.0 proxy caches which implement the HTTP/1.0 + specification [2]. Some legacy proxy caches which return the + HTTP/1.0 protocol version number do not honor the HTTP/1.0 Expires + header as specified in [2]. Methods for achieving compatibility + with such proxy caches are beyond the scope of this specification. + +10.8 Negotiation on content encoding + + Negotiation on the content encoding of a response is orthogonal to + transparent content negotiation. The rules for when a content + encoding may be applied are the same as in HTTP/1.1: servers MAY + content-encode responses that are the result of transparent content + negotiation whenever an Accept-Encoding header in the request allows + it. When negotiating on the content encoding of a cacheable + response, servers MUST add the accept-encoding header name to the + Vary header of the response, or add `Vary: *'. + + + + + + +Holtman & Mutz Experimental [Page 41] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Servers SHOULD always be able to provide unencoded versions of every + transparently negotiated response. This means in particular that + every variant in the variant list SHOULD at least be available in an + unencoded form. + + Like HTTP/1.1, this specification allows proxies to encode or decode + relayed or cached responses on the fly, unless explicitly forbidden + by a Cache-Control directive. The encoded or decoded response still + contains the same variant as far as transparent content negotiation + is concerned. Note that HTTP/1.1 requires proxies to add a Warning + header if the encoding of a response is changed. + +11 User agent support for transparent negotiation + + This section specifies the requirements a user agent needs to satisfy + in order to support transparent negotiation. If the user agent + contains an internal cache, this cache MUST conform to the rules for + proxy caches in section 13. + +11.1 Handling of responses + + If a list response is received when a resource is accessed, the user + agent MUST be able to automatically choose, retrieve, and display the + best variant, or display an error message if none of the variants are + acceptable. + + If a choice response is received when a resource is accessed, the + usual action is to automatically display the enclosed entity. + However, if a remote variant selection algorithm which was enabled + could have made a choice different from the choice the local + algorithm would make, the user agent MAY apply its local algorithm to + any variant list in the response, and automatically retrieve and + display another variant if the local algorithm makes an other choice. + + When receiving a choice response, a user agent SHOULD check if + variant resource is a neighboring variant resource of the negotiable + resource. If this is not the case, the user agent SHOULD reject the + choice response as a probable spoofing attempt and display an error + message, for example by internally replacing the choice response with + a 502 (bad gateway) response. + +11.2 Presentation of a transparently negotiated resource + + If the user agent is displaying a variant which is not an embedded or + inlined object and which is the result of transparent content + negotiation, the following requirements apply. + + + + + +Holtman & Mutz Experimental [Page 42] + +RFC 2295 Transparent Content Negotiation March 1998 + + + 1. The user agent SHOULD allow the user to review a list of all + variants bound to the negotiable resource, and to manually + retrieve another variant if desired. There are two general ways + of providing such a list. First, the information in the + Alternates header of the negotiable resource could be used to + make an annotated menu of variants. Second, the entity included + in a list response of the negotiable resource could be displayed. + Note that a list response can be obtained by doing a GET request + which only has the "trans" directive in the Negotiate header. + + 2. The user agent SHOULD make available though its user interface + some indication that the resource being displayed is a negotiated + resource instead of a plain resource. It SHOULD also allow the + user to examine the variant list included in the Alternates + header. Such a notification and review mechanism is needed + because of privacy considerations, see section 14.1. + + 3. If the user agent shows the URI of the displayed information to + the user, it SHOULD be the negotiable resource URI, not the + variant URI that is shown. This encourages third parties, who + want to refer to the displayed information in their own + documents, to make a hyperlink to the negotiable resource as a + whole, rather than to the variant resource which happens to be + shown. Such correct linking is vital for the interoperability of + content across sites. The user agent SHOULD however also provide + a means for reviewing the URI of the particular variant which is + currently being displayed. + + 4. Similarly, if the user agent stores a reference to the + displayed information for future use, for example in a hotlist, + it SHOULD store the negotiable resource URI, not the variant URI. + + It is encouraged, but not required, that some of the above + functionality is also made available for inlined or embedded objects, + and when a variant which was selected manually is being displayed. + +12 Origin server support for transparent negotiation + +12.1 Requirements + + To implement transparent negotiation on a resource, the origin server + MUST be able to send a list response when getting a GET request on + the resource. It SHOULD also be able to send appropriate list + responses for HEAD requests. When getting a request on a + transparently negotiable resource, the origin server MUST NEVER + return a response with a 2xx status code or any 3xx status code, + except 304, which is not a list, choice, or adhoc response. + + + + +Holtman & Mutz Experimental [Page 43] + +RFC 2295 Transparent Content Negotiation March 1998 + + + If the request includes a Negotiate header with a "vlist" or "trans" + directive, but without any directive which allows the server to + select a best variant, a list response MUST ALWAYS be sent, except + when the server is performing a server-side override for bug + compatibility. If the request includes a Negotiate header with a + "vlist" or "guess-small" directive, an Alternates header with the + variant list bound to the negotiable resource MUST ALWAYS be sent in + any list, choice, or adhoc response, except when the server is + performing a server-side override for bug compatibility. + + If the Negotiate header allows it, the origin server MAY run a remote + variant selection algorithm. If the algorithm has sufficient + information to choose a best variant, and if the best variant is a + neighboring variant, the origin server MAY return a choice response + with this variant. + + When getting a request on a transparently negotiable resource from a + user agent which does not support transparent content negotiation, + the origin server MAY use a custom algorithm to select between + sending a list, choice, or adhoc response. + + The following table summarizes the rules above. + + |Req on |Usr agnt|server- | Response may be: | + |trans neg|capable |side +------+------+------+------+------+ + |resource?|of TCN? |override?|list |choice|adhoc |normal|error | + +---------+--------+---------+------+------+------+------+------+ + | Yes | Yes | No |always|smt(*)|never |never |always| + +---------+--------+---------+------+------+------+------+------+ + | Yes | Yes | Yes |always|always|always|never |always| + +---------+--------+---------+------+------+------+------+------+ + | Yes | No | - |always|always|always|never |always| + +---------+--------+---------+------+------+------+------+------+ + | No | - | - |never |never |never |always|always| + +---------+--------+---------+------+------+------+------+------+ + (*) sometimes, when allowed by the Negotiate request header + + Negotiability is a binary property: a resource is either + transparently negotiated, or it is not. Origin servers SHOULD NOT + vary the negotiability of a resource, or the variant list bound to + that resource, based on the request headers which are received. The + variant list and the property of being negotiated MAY however change + through time. The Cache-Control header can be used to control the + propagation of such time-dependent changes through caches. + + It is the responsibility of the author of the negotiable resource to + ensure that all resources in the variant list serve the intended + content, and that the variant resources do not engage in transparent + + + +Holtman & Mutz Experimental [Page 44] + +RFC 2295 Transparent Content Negotiation March 1998 + + + content negotiation themselves. + +12.2 Negotiation on transactions other than GET and HEAD + + If a resource is transparently negotiable, this only has an impact on + the GET and HEAD transactions on the resource. It is not possible + (under this specification) to do transparent content negotiation on + the direct result of a POST request. + + However, a POST request can return an unnegotiated 303 (See Other) + response which causes the user agent to do a GET request on a second + resource. This second resource could then use transparent content + negotiation to return an appropriate final response. The figure + below illustrates this. + + Server ______ proxy ______ proxy ______ user + x.org cache cache agent + + < ------------------------------------- + | POST http://x.org/cgi/submit + | <form contents in request body> + | + -------------------------------------- > + 303 See Other | + Location: http://x.org/result/OK | + | + < ------------------------------------- + | GET http://x.org/result/OK + | small Accept- headers + | + able to choose on + behalf of user agent + | + ------------------------------------- > + choice response with | + ..result/OK.nl variant | + displays OK.nl + + See the HTTP/1.1 specification [1] for details on the 303 (See Other) + status code. Note that this status code is not understood by some + HTTP/1.0 clients. + +13 Proxy support for transparent negotiation + + Transparent content negotiation is an extension on top of HTTP/1.x. + It is designed to work through any proxy which only implements the + HTTP/1.1 specification [1]. If Expires headers are added as + discussed in section 10.7, negotiation will also work though proxies + + + +Holtman & Mutz Experimental [Page 45] + +RFC 2295 Transparent Content Negotiation March 1998 + + + which implement HTTP/1.0 [2]. Thus, every HTTP/1.0 or HTTP/1.1 proxy + provides support for transparent content negotiation. However, if it + is to be claimed that a HTTP/1.x proxy offers transparent content + negotiation services, at least one of the specific optimizations + below MUST be implemented. + + An HTTP/1.x proxy MUST ONLY optimize (change) the HTTP traffic + flowing through it in ways which are explicitly allowed by the + specification(s) it conforms to. A proxy which supports transparent + content negotiation on top of HTTP/1.x MAY perform the optimizations + allowed for by HTTP/1.x. In addition, it MAY perform three + additional optimizations, defined below, on the HTTP traffic for + transparently negotiated resources and their neighboring variant + resources. + + First, when getting a request on a transparently negotiable resource + from a user agent which supports transparent content negotiation, the + proxy MAY return any cached, fresh list response from that resource, + even if the selecting request headers, as specified by the Vary + header, do not match. + + Second, when allowed by the user agent and origin server, a proxy MAY + reuse an Alternates header taken from a previous response (section + 10.4) to run a remote variant selection algorithm. If the algorithm + has sufficient information to choose a best variant, and if the best + variant is a neighboring variant, the proxy MAY return a choice + response with this variant. + + Third, if a proxy receives a choice response, it MAY extract and + cache the normal response embedded therein, as described in section + 10.5. + +14 Security and privacy considerations + +14.1 Accept- headers revealing personal information + + Accept- headers, in particular Accept-Language headers, may reveal + information which the user would rather keep private unless it will + directly improve the quality of service. For example, a user may not + want to send language preferences to sites which do not offer multi- + lingual content. The transparent content negotiation mechanism + allows user agents to omit sending of the Accept-Language header by + default, without adversely affecting the outcome of the negotiation + process if transparently negotiated multi-lingual content is + accessed. + + + + + + +Holtman & Mutz Experimental [Page 46] + +RFC 2295 Transparent Content Negotiation March 1998 + + + However, even if Accept- headers are never sent, the automatic + selection and retrieval of a variant by a user agent will reveal a + preference for this variant to the server. A malicious service + author could provide a page with `fake' negotiability on (ethnicity- + correlated) languages, with all variants actually being the same + English document, as a means of obtaining privacy-sensitive + information. Such a plot would however be visible to an alert victim + if the list of available variants and their properties is reviewed. + + Some additional privacy considerations connected to Accept- headers + are discussed in [1]. + +14.2 Spoofing of responses from variant resources + + The caching optimization in section 10.5 gives the implementer of a + negotiable resource control over the responses cached for all + neighboring variant resources. This is a security problem if a + neighboring variant resource belongs to another author. To provide + security in this case, the HTTP server will have to filter the + Content-Location headers in the choice responses generated by the + negotiable resource implementation. + +14.3 Security holes revealed by negotiation + + Malicious servers could use transparent content negotiation as a + means of obtaining information about security holes which may be + present in user agents. This is a risk in particular for negotiation + on the availability of scripting languages and libraries. + +15 Internationalization considerations + + This protocol defines negotiation facilities which can be used for + the internationalization of web content. For the + internationalization of list response bodies (section 10.1), HTTP/1.0 + style negotiation (section 4.2) can be used. + +16 Acknowledgments + + Work on HTTP content negotiation has been done since at least 1993. + The authors are unable to trace the origin of many of the ideas + incorporated in this document. Many members of the HTTP working + group have contributed to the negotiation model in this + specification. The authors wish to thank the individuals who have + commented on earlier versions of this document, including Brian + Behlendorf, Daniel DuBois, Martin J. Duerst, Roy T. Fielding, Jim + Gettys, Yaron Goland, Dirk van Gulik, Ted Hardie, Graham Klyne, Scott + Lawrence, Larry Masinter, Jeffrey Mogul, Henrik Frystyk Nielsen, + Frederick G.M. Roeber, Paul Sutton, and Klaus Weide and Mark Wood. + + + +Holtman & Mutz Experimental [Page 47] + +RFC 2295 Transparent Content Negotiation March 1998 + + +17 References + + [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and + T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC + 2068, January 1997. + + [2] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext + Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. + + [3] Holtman, K., and A. Mutz, "HTTP Remote Variant Selection + Algorithm -- RVSA/1.0", RFC 2296, March 1998. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO + 10646", RFC 2044, October 1996. + +18 Authors' Addresses + + Koen Holtman + Technische Universiteit Eindhoven + Postbus 513 + Kamer HG 6.57 + 5600 MB Eindhoven (The Netherlands) + + EMail: koen@win.tue.nl + + + Andrew H. Mutz + Hewlett-Packard Company + 1501 Page Mill Road 3U-3 + Palo Alto CA 94304, USA + + Fax +1 415 857 4691 + EMail: mutz@hpl.hp.com + + + + + + + + + + + + + + + +Holtman & Mutz Experimental [Page 48] + +RFC 2295 Transparent Content Negotiation March 1998 + + +19 Appendix: Example of a local variant selection algorithm + + A negotiating user agent will choose the best variant from a variant + list with a local variant selection algorithm. This appendix + contains an example of such an algorithm. + + The inputs of the algorithm are a variant list from an Alternates + header, and an agent-side configuration database, which contains + + - the feature set of the current request, + + - a collection of quality values assigned to media types, + languages, and charsets for the current request, following the + model of the corresponding HTTP/1.1 [1] Accept- headers, + + - a table which lists `forbidden' combinations of media types and + charsets, i.e. combinations which cannot be displayed because of + some internal user agent limitation. + + The output of the algorithm is either the best variant, or the + conclusion that none of the variants are acceptable. + +19.1 Computing overall quality values + + As a first step in the local variant selection algorithm, the overall + qualities associated with all variant descriptions in the list are + computed. + + The overall quality Q of a variant description is the value + + Q = round5( qs * qt * qc * ql * qf * qa ) + + where rounds5 is a function which rounds a floating point value to 5 + decimal places after the point. It is assumed that the user agent + can run on multiple platforms: the rounding function makes the + algorithm independent of the exact characteristics of the underlying + floating point hardware. + + The factors qs, qt, qc, ql, qf, and qa are determined as follows. + + qs Is the source quality factor in the variant description. + + qt The media type quality factor is 1 if there is no type + attribute in the variant description. Otherwise, it is the + quality value assigned to this type by the configuration + database. If the database does not assign a value, then the + factor is 0. + + + + +Holtman & Mutz Experimental [Page 49] + +RFC 2295 Transparent Content Negotiation March 1998 + + + qc The charset quality factor is 1 if there is no charset + attribute in the variant description. Otherwise, it is the + quality value assigned to this charset by the configuration + database. If the database does not assign a value, then the + factor is 0. + + ql The language quality factor is 1 if there is no language + attribute in the variant description. Otherwise, it is the + highest quality value the configuration database assigns to any + of the languages listed in the language attribute. If the + database does not assign a value to any of the languages + listed, then the factor is 0. + + qf The features quality factor is 1 if there is no features + attribute in the variant description. Otherwise, it is the + quality degradation factor computed for the features attribute + using the feature set of the current request. + + qa The quality adjustment factor is 0 if the variant description + lists a media type - charset combination which is `forbidden' + by the table, and 1 otherwise. + + As an example, if a variant list contains the variant description + + {"paper.2" 0.7 {type text/html} {language fr}} + + and if the configuration database contains the quality value + assignments + + types: text/html;q=1.0, type application/postscript;q=0.8 + languages: en;q=1.0, fr;q=0.5 + + then the local variant selection algorithm will compute the overall + quality for the variant description as follows: + + {"paper.2" 0.7 {type text/html} {language fr}} + | | | + | | | + V V V + round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000 + + With same configuration database, the variant list + + {"paper.1" 0.9 {type text/html} {language en}}, + {"paper.2" 0.7 {type text/html} {language fr}}, + {"paper.3" 1.0 {type application/postscript} {language en}} + + would yield the following computations: + + + +Holtman & Mutz Experimental [Page 50] + +RFC 2295 Transparent Content Negotiation March 1998 + + + round5 ( qs * qt * qc * ql * qf * qa ) = Q + --- --- --- --- --- --- + paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000 + paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 * 1.0 = 0.35000 + paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 * 1.0 = 0.80000 + +19.2 Determining the result + + Using all computed overall quality values, the end result of the + local variant selection algorithm is determined as follows. + + If all overall quality values are 0, then the best variant is the + fallback variant, if there is one in the list, else the result is the + conclusion that none of the variants are acceptable. + + If at least one overall quality value is greater than 0, then the + best variant is the variant which has the description with the + highest overall quality value, or, if there are multiple variant + descriptions which share the highest overall quality value, the + variant of the first variant description in the list which has this + highest overall quality value. + +19.3 Ranking dimensions + + Consider the following variant list: + + {"paper.greek" 1.0 {language el} {charset ISO-8859-7}}, + {"paper.english" 1.0 {language en} {charset ISO-8859-1}} + + It could be the case that the user prefers the language "el" over + "en", while the user agent can render "ISO-8859-1" better than "ISO- + 8859-7". The result is that in the language dimension, the first + variant is best, while the second variant is best in the charset + dimension. In this situation, it would be preferable to choose the + first variant as the best variant: the user settings in the language + dimension should take precedence over the hard-coded values in the + charset dimension. + + To express this ranking between dimensions, the user agent + configuration database should have a higher spread in the quality + values for the language dimension than for the charset dimension. + For example, with + + languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ... + + charsets: ISO-8859-1;q=1.0, ISO-8859-7;q=0.95, + ISO-8859-5;q=0.97, unicode-1-1;q=0, ... + + + + +Holtman & Mutz Experimental [Page 51] + +RFC 2295 Transparent Content Negotiation March 1998 + + + the first variant will have an overall quality of 0.95000, while the + second variant will have an overall quality 0.70000. This makes the + first variant the best variant. + +20 Appendix: feature negotiation examples + + This appendix contains examples of the use of feature tags in variant + descriptions. The tag names used here are examples only, they do not + in general reflect the tag naming scheme proposed in [4]. + +20.1 Use of feature tags + + Feature tags can be used in variant lists to express the quality + degradation associated with the presence or absence of certain + features. One example is + + {"index.html.plain" 0.7 }, + {"index.html" 1.0 {features tables frames}} + + Here, the "{features tables frames}" part expresses that index.html + uses the features tagged as tables and frames. If these features are + absent, the overall quality of index.html degrades to 0. Another + example is + + {"home.graphics" 1.0 {features !textonly}}, + {"home.textonly" 0.7 } + + where the "{features !textonly}" part expresses that home.graphics + requires the absence of the textonly feature. If the feature is + present, the overall quality of home.graphics degrades to 0. + + The absence of a feature need not always degrade the overall quality + to 0. In the example + + {"x.html.1" 1.0 {features fonts;-0.7}} + + the absence of the fonts feature degrades the quality with a factor + of 0.7. Finally, in the example + + {"y.html" 1.0 {features [blebber wolx] }} + + The "[blebber wolx]" expresses that y.html requires the presence of + the blebber feature or the wolx feature. This construct can be used + in a number of cases: + + 1. blebber and wolx actually tag the same feature, but they were + registered by different people, and some user agents say they + support blebber while others say they support wolx. + + + +Holtman & Mutz Experimental [Page 52] + +RFC 2295 Transparent Content Negotiation March 1998 + + + 2. blebber and wolx are HTML tags of different vendors which + implement the same functionality, and which are used together in + y.html without interference. + + 3. blebber and wolx are HTML tags of different vendors which + implement the same functionality, and y.html uses the tags in a + conditional HTML construct. + + 4. blebber is a complicated HTML tag with only a sketchy + definition, implemented by one user agent vendor, and wolx + indicates implementation of a well-defined subset of the blebber + tag by some other vendor(s). y.html uses only this well-defined + subset. + +20.2 Use of numeric feature tags + + As an example of negotiation in a numeric area, the following variant + list describes four variants with title graphics designed for + increasing screen widths: + + {"home.pda" 1.0 {features screenwidth=[-199] }}, + {"home.narrow" 1.0 {features screenwidth=[200-599] }}, + {"home.normal" 1.0 {features screenwidth=[600-999] }}, + {"home.wide" 1.0 {features screenwidth=[1000-] }}, + {"home.normal"} + + The last element of the list specifies a safe default for user agents + which do not implement screen width negotiation. Such user agents + will reject the first four variants as unusable, as they seem to rely + on a feature which they do not understand. + +20.3 Feature tag design + + When designing a new feature tag, it is important to take into + account that existing user agents, which do not recognize the new tag + will treat the feature as absent. In general, a new feature tag + needs to be designed in such a way that absence of the tag is the + default case which reflects current practice. If this design + principle is ignored, the resulting feature tag will generally be + unusable. + + As an example, one could try to support negotiation between + monochrome and color content by introducing a `color' feature tag, + the presence of which would indicate the capability to display color + graphics. However, if this new tag is used in a variant list, for + example + + {"rainbow.gif" 1.0 {features color} } + + + +Holtman & Mutz Experimental [Page 53] + +RFC 2295 Transparent Content Negotiation March 1998 + + + {"rainbow.mono.gif" 0.6 {features !color}} + + then existing user agents, which would not recognize the color tag, + would all display the monochrome rainbow. The color tag is therefore + unusable in situations where optimal results for existing user agents + are desired. To provide for negotiation in this area, one must + introduce a `monochrome' feature tag; its presence indicates that the + user agent can only render (or the user prefers to view) monochrome + graphics. + +21 Appendix: origin server implementation considerations + +21.1 Implementation with a CGI script + + Transparent content negotiation has been designed to allow a broad + range of implementation options at the origin server side. A very + minimal implementation can be done using the CGI interface. The CGI + script below is an example. + + #!/bin/sh + + cat - <<'blex' + TCN: list + Alternates: {"stats.tables.html" 1.0 {type text/html} {features + tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95 + {type application/postscript}} + Vary: * + Content-Type: text/html + + <title>Multiple Choices for Web Statistics</title> + <h2>Multiple Choices for Web Statistics:</h2> + <ul> + <li><a href=stats.tables.html>Version with HTML tables</a> + <p> + <li><a href=stats.html>Version without HTML tables</a> + <p> + <li><a href=stats.ps>Postscript version</a> + </ul> + blex + + The Alternates header in the above script must be read as a single + line. The script always generates a list response with the 200 (OK) + code, which ensures compatibility with non-negotiating HTTP/1.0 + agents. + + + + + + + +Holtman & Mutz Experimental [Page 54] + +RFC 2295 Transparent Content Negotiation March 1998 + + +21.2 Direct support by HTTP servers + + Sophisticated HTTP servers could make a transparent negotiation + module available to content authors. Such a module could incorporate + a remote variant selection algorithm and an implementation of the + algorithm for generating choice responses (section 10.2). The + definition of interfaces to such modules is beyond the scope of this + specification. + +21.3 Web publishing tools + + Web publishing tools could automatically generate several variants of + a document (for example the original TeX version, a HTML version with + tables, a HTML version without tables, and a Postscript version), + together with an appropriate variant list in the interface format of + a HTTP server transparent negotiation module. This would allow + documents to be published as transparently negotiable resources. + +22 Appendix: Example of choice response construction + + The following is an example of the construction of a choice response + by a proxy cache which supports HTTP/1.1 and transparent content + negotiation. The use of the HTTP/1.1 conditional request mechanisms + is also shown. + + Assume that a user agent has cached a variant list with the validator + "1234" for the negotiable resource http://x.org/paper. Also assume + that it has cached responses from two neighboring variants, with the + entity tags "gonkyyyy" and W/"a;b". Assume that all three user agent + cache entries are stale: they would need to be revalidated before the + user agent can use them. If http://x.org/paper accessed in this + situation, the user agent could send the following request to its + proxy cache: + + GET /paper HTTP/1.1 + Host: x.org + User-Agent: WuxtaWeb/2.4 + Negotiate: 1.0 + Accept: text/html, application/postscript;q=0.4, */* + Accept-Language: en + If-None-Match: "gonkyyyy;1234", W/"a;b;1234" + + Assume that the proxy cache has cached the same three items as the + user agent, but that it has revalidated the variant list 8000 seconds + ago, so that the list is still fresh for the proxy. This means that + the proxy can run a remote variant selection algorithm on the list + and the incoming request. + + + + +Holtman & Mutz Experimental [Page 55] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Assume that the remote algorithm is able to choose paper.html.en as + the best variant. The proxy can now construct a choice response, + using the algorithm in section 10.2. In steps 1 and 2 of the + algorithm, the proxy can construct the following conditional request + on the best variant, and send it to the origin server: + + GET /paper.html.en HTTP/1.1 + Host: x.org + User-Agent: WuxtaWeb/2.4 + Negotiate: 1.0 + Accept: text/html, application/postscript;q=0.4, */* + Accept-Language: en + If-None-Match: "gonkyyyy", W/"a;b" + Via: 1.1 fred + + On receipt of the response + + HTTP/1.1 304 Not Modified + Date: Tue, 11 Jun 1996 20:05:31 GMT + Etag: "gonkyyyy" + + from the origin server, the proxy can use its freshly revalidated + paper.html.en cache entry to expand the response to a non-304 + response: + + HTTP/1.1 200 OK + Date: Tue, 11 Jun 1996 20:05:31 GMT + Content-Type: text/html + Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT + Content-Length: 5327 + Cache-control: max-age=604800 + Etag: "gonkyyyy" + Via: 1.1 fred + Age: 0 + + <title>A paper about .... + + Using this 200 response, the proxy can construct a choice response + in step 4 of the algorithm: + + HTTP/1.1 200 OK + Date: Tue, 11 Jun 1996 20:05:31 GMT + TCN: choice + Content-Type: text/html + Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT + Content-Length: 5327 + Cache-control: max-age=604800 + Content-Location: paper.html.en + + + +Holtman & Mutz Experimental [Page 56] + +RFC 2295 Transparent Content Negotiation March 1998 + + + Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, + {"paper.html.fr" 0.7 {type text/html} {language fr}}, + {"paper.ps.en" 1.0 {type application/postscript} + {language en}} + + Etag: "gonkyyyy;1234" + Vary: negotiate, accept, accept-language + Expires: Thu, 01 Jan 1980 00:00:00 GMT + Via: 1.1 fred + Age: 8000 + + <title>A paper about .... + + The choice response can subsequently be shortened to a 304 response, + because of the If-None-Match header in the original request from the + user agent. Thus, the proxy can finally return + + HTTP/1.1 304 Not Modified + Date: Tue, 11 Jun 1996 20:05:31 GMT + Etag: "gonkyyyy;1234" + Content-Location: paper.html.en + Vary: negotiate, accept, accept-language + Expires: Thu, 01 Jan 1980 00:00:00 GMT + Via: 1.1 fred + Age: 8000 + + to the user agent. + + + + + + + + + + + + + + + + + + + + + + + + +Holtman & Mutz Experimental [Page 57] + +RFC 2295 Transparent Content Negotiation March 1998 + + +23 Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Holtman & Mutz Experimental [Page 58] + |