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.Multiviews
A type map has a format similar to 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:
Content-Encoding:
x-compress
for compress'd files, and x-gzip
for gzip'd
files. The x-
prefix is ignored for encoding
comparisons.Content-Language:
en
,
meaning English. If the variant contains more than one
language, they are separated by a comma.Content-Length:
Content-Type:
name=value
. Common
parameters include:
level
text/html
this defaults to 2, otherwise
0.qs
qs
values are therefore specific to a given
resource.URI:
Body:
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.
The
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 the first matching variant, en
,
will be served.
ForceLanguagePriority Fallback
uses
Accept-Language
only permitted an es
language response, but such a variant isn't found, then the first
variant from the
Both options, Prefer
and Fallback
, may be
specified, so either the first matching variant from
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
. In general, the client determines the
language preference, not the server.