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:
leveltext/html this defaults to 2, otherwise
0.qsqs 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.