From: Jason S. Lingohr Apache's supports content negotiation as described in
+ Apache supports content negotiation as described in
the HTTP/1.1 specification. It can choose the best
representation of a resource based on the browser-supplied
preferences for media type, languages, character set and
@@ -33,8 +33,8 @@
incomplete negotiation information. Content negotiation is provided by the
- mod_negotiation
module.
- which is compiled in by default.mod_negotiation
module, which is compiled in
+ by default.
Apache supports 'server driven' content negotiation, as
defined in the HTTP/1.1 specification. It fully supports the
- Accept, Accept-Language, Accept-Charset and Accept-Encoding
+ Accept
, Accept-Language
,
+ Accept-Charset
andAccept-Encoding
request headers. Apache also supports 'transparent'
content negotiation, which is an experimental negotiation
protocol defined in RFC 2295 and RFC 2296. It does not offer
- support for 'feature negotiation' as defined in these RFCs.
A resource is a conceptual entity identified by a URI (RFC 2396). An HTTP server like Apache @@ -124,11 +125,13 @@ Negotiation
A type map is a document which is associated with the
handler named type-map
(or, for
backwards-compatibility with older Apache configurations, the
- mime type application/x-type-map
). Note that to
+ MIME type application/x-type-map
). Note that to
use this feature, you must have a handler set in the
configuration that defines a file suffix as
- type-map
; this is best done with a
type-map
; this is best done with
+
AddHandler type-map .var
in the server configuration file.
Type map files should have the same name as the resource @@ -157,7 +160,7 @@ Negotiation filename's extension, even when Multiviews is on. If the variants have different source qualities, that may be indicated by the "qs" parameter to the media type, as in this picture - (available as jpeg, gif, or ASCII-art):
+ (available as JPEG, GIF, or ASCII-art):
URI: foo
@@ -177,11 +180,11 @@ Negotiation
Variants with no 'qs' parameter value are given a qs factor of
1.0. The qs parameter indicates the relative 'quality' of this
variant compared to the other available variants, independent
- of the client's capabilities. For example, a jpeg file is
- usually of higher source quality than an ascii file if it is
+ of the client's capabilities. For example, a JPEG file is
+ usually of higher source quality than an ASCII file if it is
attempting to represent a photograph. However, if the resource
- being represented is an original ascii art, then an ascii
- representation would have a higher source quality than a jpeg
+ being represented is an original ASCII art, then an ASCII
+ representation would have a higher source quality than a JPEG
representation. A qs value is therefore specific to a given
variant depending on the nature of the resource it
represents.
Accept
+ header field. Each item can have an associated quality factor.
+ Variant description can also have a quality factor (the "qs"
+ parameter).Accept-Language
header field. Each item can have
+ a quality factor. Variants can be associated with none, one or
+ more than one language.Accept-Encoding
header field. Each item can have
+ a quality factor.Accept-Charset
header field. Each item can have a
+ quality factor. Variants can indicate a charset as a parameter
+ of the media type.Accept
+ header with the quality-of-source factor for this variants
media type, and select the variants with the highest
value.LanguagePriority
directive
- (if present).Accept-Language
header (if present), or else
+ the order of languages in the LanguagePriority
+ directive (if present).
text/*
media type
- but not explicitly associated with a particular charset
- are assumed to be in ISO-8859-1.Accept-Charset
+ header line. Charset ISO-8859-1 is acceptable unless
+ explicitly excluded. Variants with a text/*
+ media type but not explicitly associated with a particular
+ charset are assumed to be in ISO-8859-1.
Vary
is set to indicate the dimensions of
+ negotiation (browsers and caches can use this information when
+ caching the resource). End.
Vary
header to
+ indicate the dimensions of variance.
Accept
header information which would otherwise
+ result in the selection of the wrong variant in many cases. If a
+ browser sends full and correct information these fiddles will not
+ be applied.
The Accept: request header indicates preferences for media - types. It can also include 'wildcard' media types, such as - "image/*" or "*/*" where the * matches any string. So a request +
The Accept:
request header indicates preferences
+ for media types. It can also include 'wildcard' media types, such
+ as "image/*" or "*/*" where the * matches any string. So a request
including:
Accept: image/*, */*
If the Accept: header contains no q factors at all, - Apache sets the q value of "*/*", if present, to 0.01 to - emulate the desired behavior. It also sets the q value of - wildcards of the format "type/*" to 0.02 (so these are - preferred over matches against "*/*". If any media type on the - Accept: header contains a q factor, these special values are - not applied, so requests from browsers which send the - explicit information to start with work as expected.
+If the Accept:
header contains no q
+ factors at all, Apache sets the q value of "*/*", if present, to
+ 0.01 to emulate the desired behavior. It also sets the q value of
+ wildcards of the format "type/*" to 0.02 (so these are preferred
+ over matches against "*/*". If any media type on the
+ Accept:
header contains a q factor, these special
+ values are not applied, so requests from browsers which
+ send the explicit information to start with work as expected.
When a client requests a page on your server, but the server
- cannot find a single page that matches the Accept-language sent by
+ cannot find a single page that matches the
+ Accept-language
sent by
the browser, the server will return either a "No Acceptable
Variant" or "Multiple Choices" response to the client. To avoid
these error messages, it is possible to configure Apache to ignore
- the Accept-language in these cases and provide a document that
- does not explicitly match the client's request. The ForceLanguagePriority
+ the Accept-language
in these cases and provide a
+ document that does not explicitly match the client's request. The
+ ForceLanguagePriority
directive can be used to override one or both of these error
- messages and substitute the servers judgement in the form of the
+ messages and substitute the servers judgement in the form of the
LanguagePriority
directive.
en
. (Note that it is almost surely a configuration
error to include en-GB
and not en
in the
- Accept-Language header, since it is very unlikely that a reader
- understands British English, but doesn't understand English in
- general. Unfortunately, many current clients have default
- configurations that resemble this.) However, if no other language
- match is possible and the server is about to return a "No
+ Accept-Language
header, since it is very unlikely
+ that a reader understands British English, but doesn't understand
+ English in general. Unfortunately, many current clients have
+ default configurations that resemble this.) However, if no other
+ language match is possible and the server is about to return a "No
Acceptable Variants" error or fallback to the LanguagePriority
, the server
will ignore the subset specification and match en-GB
against en
documents. Implicitly, Apache will add
@@ -487,7 +493,7 @@ Negotiation
specification and to work effectively with properly configured
clients.
- In order to support advanced techniques (such as Cookies or +
In order to support advanced techniques (such as cookies or
special URL-paths) to determine the user's preferred language,
since Apache 2.0.47 mod_negotiation
recognizes
the environment variable
@@ -512,9 +518,9 @@ variant lists to label variants which are available with a specific
content-encoding only. The implementation of the RVSA/1.0 algorithm
(RFC 2296) is extended to recognize encoded variants in the list, and
to use them as candidate variants whenever their encodings are
-acceptable according to the Accept-Encoding request header. The
-RVSA/1.0 implementation does not round computed quality factors to 5
-decimal places before choosing the best variant.
Accept-Encoding
request
+header. The RVSA/1.0 implementation does not round computed quality
+factors to 5 decimal places before choosing the best variant.
Apache's supports content negotiation as described in +
Apache supports content negotiation as described in the HTTP/1.1 specification. It can choose the best representation of a resource based on the browser-supplied preferences for media type, languages, character set and @@ -16,8 +16,8 @@ incomplete negotiation information.
Content negotiation is provided by the
-
Apache supports 'server driven' content negotiation, as
defined in the HTTP/1.1 specification. It fully supports the
- Accept, Accept-Language, Accept-Charset and Accept-Encoding
+ Accept
, Accept-Language
,
+ Accept-Charset
andAccept-Encoding
request headers. Apache also supports 'transparent'
content negotiation, which is an experimental negotiation
protocol defined in RFC 2295 and RFC 2296. It does not offer
- support for 'feature negotiation' as defined in these RFCs.
A resource is a conceptual entity identified by a URI (RFC 2396). An HTTP server like Apache @@ -95,11 +96,13 @@
A type map is a document which is associated with the
handler named type-map
(or, for
backwards-compatibility with older Apache configurations, the
- mime type application/x-type-map
). Note that to
+ MIME type application/x-type-map
). Note that to
use this feature, you must have a handler set in the
configuration that defines a file suffix as
- type-map
; this is best done with a
type-map
; this is best done with
+
in the server configuration file.
Type map files should have the same name as the resource @@ -128,7 +131,7 @@ filename's extension, even when Multiviews is on. If the variants have different source qualities, that may be indicated by the "qs" parameter to the media type, as in this picture - (available as jpeg, gif, or ASCII-art):
+ (available as JPEG, GIF, or ASCII-art):Accept
+ header field. Each item can have an associated quality factor.
+ Variant description can also have a quality factor (the "qs"
+ parameter).Accept-Language
header field. Each item can have
+ a quality factor. Variants can be associated with none, one or
+ more than one language.Accept-Encoding
header field. Each item can have
+ a quality factor.Accept-Charset
header field. Each item can have a
+ quality factor. Variants can indicate a charset as a parameter
+ of the media type.Accept
+ header with the quality-of-source factor for this variants
media type, and select the variants with the highest
value.LanguagePriority
directive
- (if present).Accept-Language
header (if present), or else
+ the order of languages in the LanguagePriority
+ directive (if present).
text/*
media type
- but not explicitly associated with a particular charset
- are assumed to be in ISO-8859-1.Accept-Charset
+ header line. Charset ISO-8859-1 is acceptable unless
+ explicitly excluded. Variants with a text/*
+ media type but not explicitly associated with a particular
+ charset are assumed to be in ISO-8859-1.
Vary
is set to indicate the dimensions of
+ negotiation (browsers and caches can use this information when
+ caching the resource). End.
Vary
header to
+ indicate the dimensions of variance.
Accept
header information which would otherwise
+ result in the selection of the wrong variant in many cases. If a
+ browser sends full and correct information these fiddles will not
+ be applied.
The Accept: request header indicates preferences for media - types. It can also include 'wildcard' media types, such as - "image/*" or "*/*" where the * matches any string. So a request +
The Accept:
request header indicates preferences
+ for media types. It can also include 'wildcard' media types, such
+ as "image/*" or "*/*" where the * matches any string. So a request
including:
If the Accept: header contains no q factors at all, - Apache sets the q value of "*/*", if present, to 0.01 to - emulate the desired behavior. It also sets the q value of - wildcards of the format "type/*" to 0.02 (so these are - preferred over matches against "*/*". If any media type on the - Accept: header contains a q factor, these special values are - not applied, so requests from browsers which send the - explicit information to start with work as expected.
+If the Accept:
header contains no q
+ factors at all, Apache sets the q value of "*/*", if present, to
+ 0.01 to emulate the desired behavior. It also sets the q value of
+ wildcards of the format "type/*" to 0.02 (so these are preferred
+ over matches against "*/*". If any media type on the
+ Accept:
header contains a q factor, these special
+ values are not applied, so requests from browsers which
+ send the explicit information to start with work as expected.
When a client requests a page on your server, but the server
- cannot find a single page that matches the Accept-language sent by
+ cannot find a single page that matches the
+ Accept-language
sent by
the browser, the server will return either a "No Acceptable
Variant" or "Multiple Choices" response to the client. To avoid
these error messages, it is possible to configure Apache to ignore
- the Accept-language in these cases and provide a document that
- does not explicitly match the client's request. The
en
. (Note that it is almost surely a configuration
error to include en-GB
and not en
in the
- Accept-Language header, since it is very unlikely that a reader
- understands British English, but doesn't understand English in
- general. Unfortunately, many current clients have default
- configurations that resemble this.) However, if no other language
- match is possible and the server is about to return a "No
+ Accept-Language
header, since it is very unlikely
+ that a reader understands British English, but doesn't understand
+ English in general. Unfortunately, many current clients have
+ default configurations that resemble this.) However, if no other
+ language match is possible and the server is about to return a "No
Acceptable Variants" error or fallback to the en-GB
@@ -467,7 +473,7 @@
specification and to work effectively with properly configured
clients.
- In order to support advanced techniques (such as Cookies or +
In order to support advanced techniques (such as cookies or
special URL-paths) to determine the user's preferred language,
since Apache 2.0.47
Accept-Encoding
request
+header. The RVSA/1.0 implementation does not round computed quality
+factors to 5 decimal places before choosing the best variant.