From 1658e1ab84d8a6de36b48efa6fb565c6444c2cf5 Mon Sep 17 00:00:00 2001 From: Rich Bowen Date: Fri, 12 Mar 2010 12:39:41 +0000 Subject: [PATCH] Apache -> httpd git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@922240 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/content-negotiation.html.en | 54 ++++++++++++------------- docs/manual/content-negotiation.xml | 52 ++++++++++++------------ 2 files changed, 53 insertions(+), 53 deletions(-) diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en index 97bf52535d..fd7d98a894 100644 --- a/docs/manual/content-negotiation.html.en +++ b/docs/manual/content-negotiation.html.en @@ -25,7 +25,7 @@ -

Apache supports content negotiation as described in +

The Apache HTTP Server (httpd) 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 @@ -38,7 +38,7 @@ by default.

-

Apache supports 'server driven' content negotiation, as +

httpd supports 'server driven' content negotiation, as defined in the HTTP/1.1 specification. It fully supports the Accept, Accept-Language, Accept-Charset andAccept-Encoding - request headers. Apache also supports 'transparent' + request headers. httpd 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 + identified by a URI (RFC 2396). An HTTP server like Apache HTTP Server provides access to representations of the resource(s) within its namespace, with each representation in the form of a sequence of bytes with a defined media type, @@ -104,7 +104,7 @@ Negotiation the dimensions of negotiation.

top
-

Negotiation in Apache

+

Negotiation in httpd

In order to negotiate a resource, the server needs to be given information about each of the variants. This is done in @@ -124,7 +124,7 @@ 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 + older httpd configurations, the 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 @@ -234,24 +234,24 @@ Negotiation

The Negotiation Methods

-

After Apache has obtained a list of the variants for a given +

After httpd has obtained a list of the variants for a given resource, either from a type-map file or from the filenames in the directory, it invokes one of two methods to decide on the 'best' variant to return, if any. It is not necessary to know any of the details of how negotiation actually takes place in - order to use Apache's content negotiation features. However the + order to use httpd's content negotiation features. However the rest of this document explains the methods used for those interested.

There are two negotiation methods:

    -
  1. Server driven negotiation with the Apache - algorithm is used in the normal case. The Apache +
  2. Server driven negotiation with the httpd + algorithm is used in the normal case. The httpd algorithm is explained in more detail below. When this - algorithm is used, Apache can sometimes 'fiddle' the quality + algorithm is used, httpd can sometimes 'fiddle' the quality factor of a particular dimension to achieve a better result. - The ways Apache can fiddle quality factors is explained in + The ways httpd can fiddle quality factors is explained in more detail below.
  3. Transparent content negotiation is used @@ -260,7 +260,7 @@ Negotiation
    4. the browser full control over deciding on the 'best' variant, the result is therefore dependent on the specific algorithms used by the browser. As part of the transparent negotiation - process, the browser can ask Apache to run the 'remote + process, the browser can ask httpd to run the 'remote variant selection algorithm' defined in RFC 2296.
@@ -311,9 +311,9 @@ Negotiation -

Apache Negotiation Algorithm

+

httpd Negotiation Algorithm

-

Apache can use the following algorithm to select the 'best' +

httpd can use the following algorithm to select the 'best' variant (if any) to return to the browser. This algorithm is not further configurable. It operates as follows:

@@ -401,8 +401,8 @@ Negotiation

Fiddling with Quality Values

-

Apache sometimes changes the quality values from what would - be expected by a strict interpretation of the Apache +

httpd sometimes changes the quality values from what would + be expected by a strict interpretation of the httpd negotiation algorithm above. This is to get a better result from the algorithm for browsers which do not send full or accurate information. Some of the most popular browsers send @@ -441,7 +441,7 @@ Negotiation no variant matches an explicitly listed type.

If the Accept: header contains no q - factors at all, Apache sets the q value of "*/*", if present, to + factors at all, httpd 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 @@ -452,7 +452,7 @@ Negotiation

Language Negotiation Exceptions

-

New in Apache 2.0, some exceptions have been added to the +

New in httpd 2.0, some exceptions have been added to the negotiation algorithm to allow graceful fallback when language negotiation fails to find a match.

@@ -461,7 +461,7 @@ Negotiation 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 + these error messages, it is possible to configure httpd to ignore the Accept-language in these cases and provide a document that does not explicitly match the client's request. The ForceLanguagePriority @@ -484,7 +484,7 @@ Negotiation 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 + against en documents. Implicitly, httpd will add the parent language to the client's acceptable language list with a very low quality value. But note that if the client requests "en-GB; q=0.9, fr; q=0.8", and the server has documents @@ -495,7 +495,7 @@ Negotiation

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 + since httpd 2.0.47 mod_negotiation recognizes the environment variable prefer-language. If it exists and contains an appropriate language tag, mod_negotiation will @@ -512,7 +512,7 @@ Negotiation

Extensions to Transparent Content Negotiation

-

Apache extends the transparent content negotiation protocol (RFC +

httpd extends the transparent content negotiation protocol (RFC 2295) as follows. A new {encoding ..} element is used in variant lists to label variants which are available with a specific content-encoding only. The implementation of the RVSA/1.0 algorithm @@ -640,9 +640,9 @@ factors to 5 decimal places before choosing the best variant.

can use the stored representation. But, if the resource is negotiable at the server, this might result in only the first requested variant being cached and subsequent cache hits might - return the wrong response. To prevent this, Apache normally + return the wrong response. To prevent this, httpd normally marks all responses that are returned after content negotiation - as non-cacheable by HTTP/1.0 clients. Apache also supports the + as non-cacheable by HTTP/1.0 clients. httpd also supports the HTTP/1.1 protocol features to allow caching of negotiated responses.

@@ -653,7 +653,7 @@ factors to 5 decimal places before choosing the best variant.

virtual host, and takes no arguments. It has no effect on requests from HTTP/1.1 clients.

-

For HTTP/1.1 clients, Apache sends a Vary HTTP +

For HTTP/1.1 clients, httpd sends a Vary HTTP response header to indicate the negotiation dimensions for the response. Caches can use this information to determine whether a subsequent request can be served from the local copy. To diff --git a/docs/manual/content-negotiation.xml b/docs/manual/content-negotiation.xml index 99fd780ccf..0d89fe4894 100644 --- a/docs/manual/content-negotiation.xml +++ b/docs/manual/content-negotiation.xml @@ -26,7 +26,7 @@

-

Apache supports content negotiation as described in +

The Apache HTTP Server (httpd) 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 @@ -71,17 +71,17 @@ Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 -

Apache supports 'server driven' content negotiation, as +

httpd supports 'server driven' content negotiation, as defined in the HTTP/1.1 specification. It fully supports the Accept, Accept-Language, Accept-Charset andAccept-Encoding - request headers. Apache also supports 'transparent' + request headers. httpd 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 + identified by a URI (RFC 2396). An HTTP server like Apache HTTP Server provides access to representations of the resource(s) within its namespace, with each representation in the form of a sequence of bytes with a defined media type, @@ -94,7 +94,7 @@ the dimensions of negotiation.

-
Negotiation in Apache +
Negotiation in httpd

In order to negotiate a resource, the server needs to be given information about each of the variants. This is done in @@ -114,7 +114,7 @@

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 + older httpd configurations, the 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 @@ -231,24 +231,24 @@

The Negotiation Methods -

After Apache has obtained a list of the variants for a given +

After httpd has obtained a list of the variants for a given resource, either from a type-map file or from the filenames in the directory, it invokes one of two methods to decide on the 'best' variant to return, if any. It is not necessary to know any of the details of how negotiation actually takes place in - order to use Apache's content negotiation features. However the + order to use httpd's content negotiation features. However the rest of this document explains the methods used for those interested.

There are two negotiation methods:

    -
  1. Server driven negotiation with the Apache - algorithm is used in the normal case. The Apache +
  2. Server driven negotiation with the httpd + algorithm is used in the normal case. The httpd algorithm is explained in more detail below. When this - algorithm is used, Apache can sometimes 'fiddle' the quality + algorithm is used, httpd can sometimes 'fiddle' the quality factor of a particular dimension to achieve a better result. - The ways Apache can fiddle quality factors is explained in + The ways httpd can fiddle quality factors is explained in more detail below.
  3. Transparent content negotiation is used @@ -257,7 +257,7 @@ the browser full control over deciding on the 'best' variant, the result is therefore dependent on the specific algorithms used by the browser. As part of the transparent negotiation - process, the browser can ask Apache to run the 'remote + process, the browser can ask httpd to run the 'remote variant selection algorithm' defined in RFC 2296.
@@ -308,9 +308,9 @@
-
Apache Negotiation Algorithm +
httpd Negotiation Algorithm -

Apache can use the following algorithm to select the 'best' +

httpd can use the following algorithm to select the 'best' variant (if any) to return to the browser. This algorithm is not further configurable. It operates as follows:

@@ -398,8 +398,8 @@
Fiddling with Quality Values -

Apache sometimes changes the quality values from what would - be expected by a strict interpretation of the Apache +

httpd sometimes changes the quality values from what would + be expected by a strict interpretation of the httpd negotiation algorithm above. This is to get a better result from the algorithm for browsers which do not send full or accurate information. Some of the most popular browsers send @@ -438,7 +438,7 @@ no variant matches an explicitly listed type.

If the Accept: header contains no q - factors at all, Apache sets the q value of "*/*", if present, to + factors at all, httpd 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 @@ -449,7 +449,7 @@

Language Negotiation Exceptions -

New in Apache 2.0, some exceptions have been added to the +

New in httpd 2.0, some exceptions have been added to the negotiation algorithm to allow graceful fallback when language negotiation fails to find a match.

@@ -458,7 +458,7 @@ 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 + these error messages, it is possible to configure httpd to ignore the Accept-language in these cases and provide a document that does not explicitly match the client's request. The LanguagePriority, the server will ignore the subset specification and match en-GB - against en documents. Implicitly, Apache will add + against en documents. Implicitly, httpd will add the parent language to the client's acceptable language list with a very low quality value. But note that if the client requests "en-GB; q=0.9, fr; q=0.8", and the server has documents @@ -494,7 +494,7 @@

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 + since httpd 2.0.47 mod_negotiation recognizes the environment variable prefer-language. If it exists and contains an appropriate language tag, mod_negotiation will @@ -511,7 +511,7 @@

Extensions to Transparent Content Negotiation -

Apache extends the transparent content negotiation protocol (RFC +

httpd extends the transparent content negotiation protocol (RFC 2295) as follows. A new {encoding ..} element is used in variant lists to label variants which are available with a specific content-encoding only. The implementation of the RVSA/1.0 algorithm @@ -641,9 +641,9 @@ factors to 5 decimal places before choosing the best variant.

can use the stored representation. But, if the resource is negotiable at the server, this might result in only the first requested variant being cached and subsequent cache hits might - return the wrong response. To prevent this, Apache normally + return the wrong response. To prevent this, httpd normally marks all responses that are returned after content negotiation - as non-cacheable by HTTP/1.0 clients. Apache also supports the + as non-cacheable by HTTP/1.0 clients. httpd also supports the HTTP/1.1 protocol features to allow caching of negotiated responses.

@@ -655,7 +655,7 @@ factors to 5 decimal places before choosing the best variant.

virtual host, and takes no arguments. It has no effect on requests from HTTP/1.1 clients.

-

For HTTP/1.1 clients, Apache sends a Vary HTTP +

For HTTP/1.1 clients, httpd sends a Vary HTTP response header to indicate the negotiation dimensions for the response. Caches can use this information to determine whether a subsequent request can be served from the local copy. To -- 2.40.0