One document matched: draft-ietf-http-alternates-00.txt
HTTP Working Group Koen Holtman, TUE
Internet-Draft Andrew Mutz, Hewlett-Packard
Expires: March 15, 1998 September 15, 1997
The Alternates Header Field
draft-ietf-http-alternates-00.txt
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress".
To learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
West Coast).
Distribution of this document is unlimited. Please send
comments to the HTTP working group at
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
discussions about HTTP and the applications which use HTTP
should take place on the <www-talk@w3.org> mailing list.
HTML and change bar versions of this document are available
at <URL:http://gewis.win.tue.nl/~koen/conneg/>.
ABSTRACT
HTTP allows web site authors to put multiple versions of the
same information under a single URL. The Alternates header
field can be used to transmit a machine-readable description
of these versions. This allows the recipient to automatically
select the most appropriate version.
TABLE OF CONTENTS
1 Introduction
1.1 Background
1.2 Applicability
2 Terminology
2.1 Terms from HTTP/1.1
2.2 New terms
3 Notation
4 The Alternates header field
4.1 Definition
4.2 Length of variant lists
5 Variant descriptions
5.1 Syntax
5.2 URI
5.3 Source-quality
5.4 Type, charset, language, and length
5.5 Extension-attribute
6 Use of the Alternates header field
6.1 Use in a response which contains a variant
6.2 Use in a response which does not contain a variant
6.3 Use in a response which redirects to a variant
6.4 User agent guidelines
6.5 Negotiation on content encoding
6.6 Role of proxies
7 Security and privacy considerations
7.1 User agent choices revealing information of a private nature
7.2 Security holes revealed by negotiation
8 Acknowledgments
9 References
10 Authors' addresses
11 Appendix: Example of a variant selection algorithm
11.1 Computing overall quality values
11.2 Determining the result
11.3 Ranking dimensions
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'. The Alternates header field can be used to transmit a
machine-readable description of these variants. This allows the
recipient to automatically select the most appropriate variant.
This specification defines the Alternates header field as part of
the HTTP/1.x protocol suite [1].
Note: Though this specification is limited to discussing HTTP
transactions, elements of this specification could also be used
in other contexts. For example, variant descriptions could be
used in multipart mail messages.
1.1 Background
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 offer 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.
HTTP/1.1 [1] defines three forms of content negotiation:
1. Server-driven content negotiation, in which the origin server
selects the best variant
2. Agent-driven content negotiation, in which the user agent
selects the best variant
3. Transparent content negotiation, in which a a distributed
process is used to choose the best variant, with either the
user agent, the origin server, or a proxy in between making
the final choice.
See [1] for a detailed definition of these three forms, and a
discussion of their individual advantages and disadvantages.
HTTP/1.1 only defines the protocol elements necessary to support
server-driven negotiation. This document defines the Alternates
header field as a way of supporting agent-driven negotiation. The
protocol elements needed for transparent content negotiation are
defined in [4].
1.2 Applicability
This specification allows for agent-driven negotiation, using a
subset of the protocol elements in [4]. Implementations based on
this specification will be able to co-exist with implementations
based on plain HTTP/1.0 [3], plain HTTP/1.1 [1], and with
implementations using all protocol elements in [4].
2 Terminology
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
this document are to be interpreted as described in RFC 2119 [5].
2.1 Terms from HTTP/1.1
This specification mostly uses the terminology of the HTTP/1.1
specification [1]. The definitions below were reproduced 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.
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.
2.2 New terms
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
variant using some form of content negotiation.
variant list
A list containing variant descriptions, which can be bound to a
negotiable resource.
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 content negotiation.
variant selection algorithm
An algorithm which can choose the best variant from a variant
list.
3 Notation
The version of BNF used in this document is taken from [1], and
many of the nonterminals used are defined in [1].
4 The Alternates header field
When returning a particular piece of content, a server may wish to
notify the client that this content is available in multiple
variants. This can be done by adding an Alternates header field,
which lists the available variants, to the response. The
Alternates header field can also be used in a response which does
not include any particular variant, but which simply informs the
client that multiple variants are available.
An example of an alternates response header field, which lists
three variants, 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}}
On receipt of an Alternates header field, a user agent can use a
variant selection algorithm to choose the best variant from the
list. This specification does not define a standard variant
selection algorithm, user agent implementers may use whichever
algorithm they find most suitable. Appendix 11 contains an example
of a variant selection algorithm.
4.1 Definition
The Alternates response header field describes all available
variants for the resource on which the request was made. The
description for each variant includes an URI from which this
variant can be retrieved. The Alternates header field can also
contain directives for any negotiation process which is initiated
by the receipt of the response.
Alternates = "Alternates" ":" variant-list
variant-list = 1#( variant-description ; see section 5
| fallback-variant
| negotiation-directive )
fallback-variant = "{" <"> URI <"> "}"
negotiation-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}},
{"paper.html.en"}, x=y
Any relative URI specified in a variant-description or
fallback-variant field is relative to the request-URI.
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.
Only one fallback-variant field may be present. If the variant
selection algorithm of the user agent finds that all variants
described by variant-description fields 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.
This specification does not define any specific negotiation
directives for the Alternates header field. User agents SHOULD
ignore all negotiation directives they do not understand. If a
proxy receives an Alternates header field with an unknown
negotiation directive, it SHOULD, whenever possible, forward the
response towards the user agent instead of trying to take part in a
negotiation process itself.
4.2 Length of variant lists
As a general rule, variant lists in Alternates header fields should
be short: it is expected that a typical negotiable resource will
have 2 to 10 variants, depending on its purpose. Servers which
have many more variants SHOULD use a method of describing them
which is more sophisticated than the Alternates header field
defined in this document.
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 "}"
| 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 "}">
Examples are
{"paper.2" 0.7 {type text/html} {language fr}}
{"paper.5" 0.9 {type text/html} {length 1002}}
{"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 the
content it sends (on the Cookie request header field, for example),
but SHOULD NOT engage in 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 variant selection algorithms in user
agents (see appendix 11) 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 degradation factors are generally combined by multiplying
them, not by adding them.
In the 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 a
variant selection algorithm in the user agent.
5.4 Type, charset, language, and length
The type attribute of a variant description carries the same
information as its Content-Type response header field counterpart
defined in [1], except for any charset information, which MUST be
carried in the charset attribute. For, example, the header field
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 field 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-* header fields 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 field. If a Content-Language header
field is present, it does not have to contain an exact copy of
the information in the language attribute.
5.5 Extension-attribute
The extension-attribute allows future specifications to
incrementally define new dimensions of negotiation, and eases
content negotiation experiments. User agents conforming to this
specification SHOULD treat all variants with extension attributes
they do not recognize as unusable. Proxies SHOULD NOT do any
negotiation processing for a response if an extension attribute
unknown to them is present in the variant list. They SHOULD
forward the response unchanged towards the user agent instead.
The extension names "features" and "description" are reserved by
this specification for use in transparent content negotiation [4].
6 Use of the Alternates header field
This section defines conventions and guidelines for the use of the
Alternates header field.
6.1 Use in a response which contains a variant
If a request is done on a negotiable resource, the server may
return a particular variant in the response, together with an
Alternates header field which notifies the client that multiple
variants are available. An example of such a response is:
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
Content-Type: text/html
Content-Language: en
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
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}}
Content-Location: paper.1
Vary: *
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Cache-Control: max-age=604800
<title>A paper about ....
In this response, the Content-Location header field tells the user
agent which variant was included. The Vary, Expires, and
Cache-Control header fields ensure proper handling of the response
by HTTP/1.0 and HTTP/1.1 caches.
When detecting that an Alternates header field is present, a user
agent MAY choose to use a variant selection algorithm to select the
best variant of the negotiable resource. If the best variant is
not the same one as is included in the response (as identified by
the Content-Location header field), the user agent MAY do a new
request on the variant resource of the best variant in order to
retrieve it.
6.2 Use in a response which does not contain a variant
If the response to a request on a negotiable resource does not
contain a particular variant, the origin server should signal this
by not including any Content-Location header field. An example of
such a response is:
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:02:21 GMT
Content-Type: text/html
Content-Length: 227
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: *
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Cache-Control: max-age=604800
<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>
On receipt of such a response, the user agent SHOULD use a variant
selection algorithm to select the best variant of the negotiable
resource, and retrieve this variant. For compatibility with user
agents which are not capable of handling the Alternates header
field, a response body which allows the user to select the best
variant manually can be included.
6.3 Use in a response which redirects to a variant
By putting an Alternates header field in a redirection response, an
origin server can avoid the sending of a variant, which may be the
wrong variant, to a user agent capable of using the Alternates
header field, while still providing automatic selection for user
agents which are not capable of using the Alternates header field.
An example of such a response is:
HTTP/1.1 302 Moved Temporarily
Date: Tue, 11 Jun 1996 20:05:31 GMT
Content-Type: text/html
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}}
Location: paper.1
Content-Length: 53
This document is available <a href=paper.1>here</a>.
Note the use of a Location header field instead of a
Content-Location header field. On receipt of such a response, the
user agent SHOULD use a variant selection algorithm to select the
best variant of the negotiable resource, and retrieve this variant.
6.4 User agent guidelines
Summarizing the three sections above, if an Alternates header field
is present in the response, then
* a user agent SHOULD use its variant selection algorithm to
choose and retrieve the best variant if a Content-Location
header field is absent,
* and MAY use its variant selection algorithm to choose and
retrieve the best variant if a Content-Location header field
is present.
If the user agent is displaying a variant as the result of a
content negotiation process, and the variant is not an embedded or
inlined object, the following requirements apply.
1. 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 field. Such a notification and review
mechanism is needed because of privacy considerations, see
section 7.1.
2. 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.
3. 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.
6.5 Negotiation on content encoding
Negotiation on the content encoding of a response is orthogonal to
content negotiation based on the Alternates header field. The
presence of an Alternates header field in a response does not
change the rules, as stated by the HTTP/1.1 specification [1],
which determine when a content-encoding may be added or removed by
an origin server or proxy.
6.6 Role of proxies
This specification does not define mechanisms by which proxies can
use the Alternates header field, but does allow other
specifications to define such mechanisms. To ensure extensibility
of the Alternates header field, this specification does however
define, in section 4.1 and section 5.5, that a proxy should not
engage in a negotiation process when encountering an Alternates
header field which has a component unknown to it.
7 Security and privacy considerations
7.1 User agent choices revealing information of a private nature
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 through a mechanism as described in
section 6.4.
7.2 Security holes revealed by negotiation
Malicious servers could use content negotiation as a means of
obtaining information about security holes which may be present in
user agents.
8 Acknowledgments
Work on HTTP content negotiation has been done since at least 1993.
This specification builds on an earlier incomplete specification of
the Alternates header field recorded in [2]. The authors wish to
thank the individuals who have contributed to the work on content
negotiation in the HTTP working group, 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.
9 References
[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC
2068, HTTP Working Group, January 1997.
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee.
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January
1996.
[3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext
Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine,
May 1996.
[4] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP.
Internet-Draft draft-ietf-http-negotiation-04.txt, HTTP Working
Group, September 1997.
[5] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119. Harvard University, March 1997.
10 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
11 Appendix: Example of a variant selection algorithm
A negotiating user agent will choose the best variant from a
variant list with a 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 field, and an agent-side configuration database, which
contains
- 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- header fields,
- 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.
11.1 Computing overall quality values
As a first step in the 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 * 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, 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.
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.
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 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:
round5 ( qs * qt * qc * ql * qa ) = Q
--- --- --- --- ---
paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000
paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35000
paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.80000
11.2 Determining the result
Using all computed overall quality values, the end result of the
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 Alternates header field,
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.
11.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, ...
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.
Expires: March 15, 1998
| PAFTECH AB 2003-2026 | 2026-04-24 14:07:43 |