Content negotiation, or more accurately content selection, is the selection of the document that best matches the clients capabilities, from one of several available documents. There are two implementations of this.
type-map
) which explicitly lists the files
containing the variants.A type map has the same format as RFC822 mail headers. It contains document descriptions separated by blank lines, with lines beginning with a hash character ('#') treated as comments. A document description consists of several header records; records may be continued on multiple lines if the continuation lines start with spaces. The leading space will be deleted and the lines concatenated. A header record consists of a keyword name, which always ends in a colon, followed by a value. Whitespace is allowed between the header name and value, and between the tokens of value. The headers allowed are:
x-compress
for compress'd files, and x-gzip
for gzip'd
files. The x-
prefix is ignored for encoding
comparisons.en
,
meaning English.name=value
. Common parameters include:
text/html
this defaults to 2, otherwise
0.
Content-Type: image/jpeg; qs=0.8
A MultiViews search is enabled by the MultiViews /some/dir/foo
and
/some/dir/foo
does not exist, then the
server reads the directory looking for all files named
foo.*
, and effectively fakes up a type map which
names all those files, assigning them the same media types and
content-encodings it would have if the client had asked for one
of them by name. It then chooses the best match to the client's
requirements, and returns that document.
If set, this directive allows content-negotiated documents to be cached by proxy servers. This could mean that clients behind those proxys could retrieve versions of the documents that are not the best match for their abilities, but it will make caching more efficient.
This directive only applies to requests which come from HTTP/1.0 browsers. HTTP/1.1 provides much better control over the caching of negotiated documents, and this directive has no effect in responses to HTTP/1.1 requests.
Prior to version 2.0,
The
ForceLanguagePriority Prefer
uses
LanguagePriority
to serve a one valid result, rather
than returning an HTTP result 300 (MULTIPLE CHOICES) when there
are several equally valid choices. If the directives below were
given, and the user's Accept-Language header assigned en and de
each as quality .500 (equally acceptable) then then first matching
variant, en, will be served.
ForceLanguagePriority Fallback
uses
LanguagePriority
to serve a valid result, rather than
returning an HTTP result 406 (NOT ACCEPTABLE). If the directives
below were given, and the user's Accept-Language only permitted an
es langauge response, but such a variant isn't found, then the
first variant from the LanguagePriority list below will be
served.
Both options, Prefer and Fallback, may be specified, so either the first matching variant from LanguagePriority will be served if more that one variant is acceptable, or first available document will be served if none of the variants matched the client's acceptable list of languages.
The
For a request for foo.html
, where
foo.html.fr
and foo.html.de
both
existed, but the browser did not express a language preference,
then foo.html.fr
would be returned.
Note that this directive only has an effect if a 'best'
language cannot be determined by any other means or the None
. Correctly implemented HTTP/1.1 requests
will mean this directive has no effect.