From: Roy T. Fielding Date: Sat, 6 Feb 1999 14:00:33 +0000 (+0000) Subject: Update docs according to new negotiation ordering. Note that we X-Git-Tag: 1.3.5~26 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=ba1afaed155f3c0ac99197b924effb9d5aea8300;p=apache Update docs according to new negotiation ordering. Note that we still don't have any documentation of TCN/RVSA effects. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82762 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/content-negotiation.html b/docs/manual/content-negotiation.html index 72d5a1356d..45c6639bc6 100644 --- a/docs/manual/content-negotiation.html +++ b/docs/manual/content-negotiation.html @@ -70,12 +70,17 @@ the HTTP/1.1 specification. It fully supports the Accept, Accept-Language, Accept-Charset and Accept-Encoding request headers.

-The terms used in content negotiation are: a resource is an -item which can be requested of a server, which might be selected as -the result of a content negotiation algorithm. If a resource is -available in several formats, these are called representations -or variants. The ways in which the variants for a particular -resource vary are called the dimensions of negotiation. +A resource is a conceptual entity identified by a URI +(RFC 2396). An HTTP server like Apache 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, character set, encoding, etc. Each resource may be +associated with zero, one, or more than one representation +at any given time. If multiple representations are available, +the resource is referred to as negotiable and each of its +representations is termed a variant. The ways in which the +variants for a negotiable resource vary are called the +dimensions of negotiation.

Negotiation in Apache

@@ -86,9 +91,9 @@ ways:

Using a type-map file

@@ -98,25 +103,25 @@ 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 use this feature, -you've got to have a SetHandler some place which defines a +you must have a handler set in the configuration that defines a file suffix as type-map; this is best done with a -
 
+
   AddHandler type-map var
-
 

-in srm.conf.  See comments in the sample config files for
-details. 

+
+in the server configuration file.  See the comments in the sample config
+file for more details. 

 
 Type map files have an entry for each available variant; these entries
-consist of contiguous RFC822-format header lines.  Entries for
+consist of contiguous HTTP-format header lines.  Entries for
 different variants are separated by blank lines.  Blank lines are
 illegal within an entry.  It is conventional to begin a map file with
 an entry for the combined entity as a whole (although this
 is not required, and if present will be ignored). An example
 map file is:
-
 
+
   URI: foo
 
   URI: foo.en.html
@@ -124,13 +129,14 @@ map file is:
   Content-language: en
 
   URI: foo.fr.de.html
-  Content-type: text/html; charset=iso-8859-2
+  Content-type: text/html;charset=iso-8859-2
   Content-language: fr, de
 

 
 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):
+
 
   URI: foo
 
@@ -142,14 +148,22 @@ as jpeg, gif, or ASCII-art):
 
   URI: foo.txt
   Content-type: text/plain; qs=0.01
-
 

 

 
-qs values can vary between 0.000 and 1.000. Note that any variant with
+qs values can vary in the range 0.000 to 1.000. Note that any variant with
 a qs value of 0.000 will never be chosen. Variants with no 'qs'
-parameter value are given a qs factor of 1.0.  

+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
+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 representation.  A qs value
+is therefore specific to a given variant depending on the nature of
+the resource it represents.
 
+

 The full list of headers recognized is:
 
 

@@ -160,22 +174,24 @@ The full list of headers recognized is:
        the same server (!), and they must refer to files to which the
        client would be granted access if they were to be requested
        directly.
-  
 Content-type:
+  
 Content-Type:
   
 media type --- charset, level and "qs" parameters may be given.  These
        are often referred to as MIME types; typical media types are
        image/gif, text/plain, or
        text/html; level=3.
-  
 Content-language:
+  
 Content-Language:
   
 The languages of the variant, specified as an Internet standard
-       language code (e.g., en for English,
+       language tag from RFC 1766 (e.g., en for English,
        kr for Korean, etc.).
-  
 Content-encoding:
+  
 Content-Encoding:
   
 If the file is compressed, or otherwise encoded, rather than
        containing the actual raw data, this says how that was done.
-       For compressed files (the only case where this generally comes
-       up), content encoding should be
-       x-compress, or x-gzip, as appropriate.
-  
 Content-length:
+       Apache only recognizes encodings that are defined by an
+       AddEncoding directive.
+       This normally includes the encodings x-compress
+       for compress'd files, and x-gzip for gzip'd files.
+       The x- prefix is ignored for encoding comparisons.
+  
 Content-Length:
   
 The size of the file.  Clients can ask to receive a given media
        type only if the variant isn't too big; specifying a content
        length in the map allows the server to compare against these
@@ -185,17 +201,15 @@ The full list of headers recognized is:
 
Multiviews

 
 

-This is a per-directory option, meaning it can be set with an
-Options directive within a <Directory>,
+MultiViews is a per-directory option, meaning it can be set with
+an Options directive within a <Directory>,
 <Location> or <Files>
 section in access.conf, or (if AllowOverride
 is properly set) in .htaccess files.  Note that
 Options All does not set MultiViews; you
-have to ask for it by name.  (Fixing this is a one-line change to
-http_core.h).
+have to ask for it by name.
 
 

-
 The effect of MultiViews is as follows: if the server
 receives a request for /some/dir/foo, if
 /some/dir has MultiViews enabled, and
@@ -204,23 +218,22 @@ directory looking for 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 forwards them along.
+requirements.
 
 

-
-This applies to searches for the file named by the
+MultiViews may also apply to searches for the file named by the
 DirectoryIndex directive, if the server is trying to
-index a directory; if the configuration files specify
-
+index a directory. If the configuration files specify
 
+
   DirectoryIndex index
+

 
-
 then the server will arbitrate between index.html
+then the server will arbitrate between index.html
 and index.html3 if both are present.  If neither are
 present, and index.cgi is there, the server will run it.
 
 

-
 If one of the files found when reading the directive is a CGI script,
 it's not obvious what should happen.  The code gives that case
 special treatment --- if the request was a POST, or a GET with
@@ -233,7 +246,7 @@ to be retrieved.
 
 After Apache 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
-applies a algorithm to decide on the 'best' variant to return, if
+applies an algorithm to decide on the 'best' variant to return, if
 any. To do this it calculates a quality value for each variant in each
 of the dimensions of variance. It is not necessary to know any of the
 details of how negotiation actually takes place in order to use Apache's
@@ -247,22 +260,28 @@ fiddle quality factors is explained in more detail below.
 
Dimensions of Negotiation

 
 
-
+
+
+
+
+
Dimension
+
Dimension
 Notes
-
Media Type
-Browser indicates preferences on Accept: header. Each item
+
Media Type
+Browser indicates preferences with the Accept header field. Each item
 can have an associated quality factor. Variant description can also
-have a quality factor.
-
Language
-Browser indicates preferences on Accept-Language: header. Each
-item
-can have a quality factor. Variants can be associated with none, one
-or more languages.
-
Encoding
-Browser indicates preference with Accept-Encoding: header.
-
Charset
-Browser indicates preference with Accept-Charset: header. Variants
-can indicate a charset as a parameter of the media type.
+have a quality factor (the "qs" parameter).
+
Language
+Browser indicates preferences with the Accept-Language header field.
+Each item can have a quality factor. Variants can be associated with none, one
+or more than one language.
+
Encoding
+Browser indicates preference with the Accept-Encoding header field.
+Each item can have a quality factor.
+
Charset
+Browser indicates preference with the Accept-Charset header field.
+Each item can have a quality factor.
+Variants can indicate a charset as a parameter of the media type.
 

 
 
Apache Negotiation Algorithm

@@ -270,13 +289,13 @@ can indicate a charset as a parameter of the media type.
 

 Apache uses an algorithm to select the 'best' variant (if any) to
 return to the browser. This algorithm is not configurable. It operates
-like this:
+as follows:
 
 
    
 
  1. 
-Firstly, for each dimension of the negotiation, the appropriate
-Accept header is checked and a quality assigned to this each
-variant. If the Accept header for any dimension means that this
+First, for each dimension of the negotiation, the appropriate
+Accept* header field is checked and a quality assigned to each
+variant. If the Accept* header for any dimension means that this
 variant is not acceptable, eliminate it. If no variants remain, go
 to step 4.
 
@@ -284,7 +303,7 @@ to step 4.
 the following tests is applied in order. Any variants not selected at
 each stage are eliminated. After each test, if only one variant
 remains, it is selected as the best match. If more than one variant
-remains, move onto the next test.
+remains, move on to the next test.
 
 
      
 
    1. Multiply the quality factor from the Accept header with the
@@ -301,6 +320,11 @@ remains, move onto the next test.
 
    2. Select the variants with the highest 'level' media parameter
   (used to give the version of text/html media types).
 
+
    3. Select only variants with acceptable charset media parameters,
+  as given on the Accept-Charset header line. Charset ISO-8859-1
+  is acceptable unless explicitly excluded. Variants not associated
+  with a particular charset are assumed to be in ISO-8859-1.
+
 
    4. Select the variants with the best encoding. If there are
   variants with an encoding that is acceptable to the user-agent,
   select only these variants. Otherwise if there is a mix of encoded
@@ -308,16 +332,11 @@ remains, move onto the next test.
   If either all variants are encoded or all variants are not encoded, 
   select all variants.
 
-
    5. Select only variants with acceptable charset media parameters,
-  as given on the Accept-Charset header line. Charset ISO-8859-1
-  is always acceptable. Variants not associated with a particular
-  charset are assumed to be in ISO-8859-1.
-
 
    6. Select the variants with the smallest content length
 
 
    7. Select the first variant of those remaining (this will be either the
-first listed in the type-map file, or the first read from the directory)
-and go to stage 3.
+  first listed in the type-map file, or the first read from the directory)
+  and go to stage 3.
 
 
    
 
@@ -326,7 +345,7 @@ and go to stage 3.
   dimensions of negotiation (browsers and caches can use this
   information when caching the resource). End.
 
-
  2. To get here means no variant was selected (because non are acceptable
+
  3. To get here means no variant was selected (because none are acceptable
   to the browser). Return a 406 status (meaning "No acceptable representation")
   with a response body consisting of an HTML document listing the
   available variants. Also set the HTTP Vary header to indicate the
@@ -508,12 +527,11 @@ if there is one) must be on the right hand side of the MIME-type extension
 
    Note on Caching
    
 
 
    
-When a cache stores a document, it associates it with the request URL.
+When a cache stores a representation, it associates it with the request URL.
 The next time that URL is requested, the cache can use the stored
-document, provided it is still within date. But if the resource is
-subject to content negotiation at the server, this would result in
-only the first requested variant being cached, and subsequent cache
-hits could return the wrong response. To prevent this,
+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 marks all responses that are returned after content negotiation
 as non-cacheable by HTTP/1.0 clients. Apache also supports the HTTP/1.1
 protocol features to allow caching of negotiated responses. 
    
@@ -522,8 +540,7 @@ For requests which come from a HTTP/1.0 compliant client (either a
 browser or a cache), the directive CacheNegotiatedDocs can be
 used to allow caching of responses which were subject to negotiation.
 This directive can be given in the server config or virtual host, and
-takes no arguments. It has no effect on requests from HTTP/1.1
-clients.
+takes no arguments. It has no effect on requests from HTTP/1.1 clients.
 
 
 
diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en
index 72d5a1356d..45c6639bc6 100644
--- a/docs/manual/content-negotiation.html.en
+++ b/docs/manual/content-negotiation.html.en
@@ -70,12 +70,17 @@ the HTTP/1.1 specification. It fully supports the Accept,
 Accept-Language, Accept-Charset and Accept-Encoding request headers.
 
    
 
-The terms used in content negotiation are: a resource is an
-item which can be requested of a server, which might be selected as
-the result of a content negotiation algorithm. If a resource is
-available in several formats, these are called representations
-or variants. The ways in which the variants for a particular
-resource vary are called the dimensions of negotiation.
+A resource is a conceptual entity identified by a URI
+(RFC 2396).  An HTTP server like Apache 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, character set, encoding, etc.  Each resource may be
+associated with zero, one, or more than one representation
+at any given time.  If multiple representations are available,
+the resource is referred to as negotiable and each of its
+representations is termed a variant. The ways in which the
+variants for a negotiable resource vary are called the
+dimensions of negotiation.
 
 
    Negotiation in Apache
    
 
@@ -86,9 +91,9 @@ ways:
 
 
      
   
    •  Using a type map (i.e., a *.var file) which
-       names the files containing the variants explicitly
-  
    •  Or using a 'MultiViews' search, where the server does an implicit
-       filename pattern match, and chooses from among the results.
+       names the files containing the variants explicitly, or
+  
    •  Using a 'MultiViews' search, where the server does an implicit
+       filename pattern match and chooses from among the results.
 
    
 
 
    Using a type-map file
    
@@ -98,25 +103,25 @@ 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 use this feature,
-you've got to have a SetHandler some place which defines a
+you must have a handler set in the configuration that defines a
 file suffix as type-map; this is best done with a
-
     
+
       AddHandler type-map var
-
 
    
-in srm.conf.  See comments in the sample config files for
-details. 
    
+
+in the server configuration file.  See the comments in the sample config
+file for more details. 
    
 
 Type map files have an entry for each available variant; these entries
-consist of contiguous RFC822-format header lines.  Entries for
+consist of contiguous HTTP-format header lines.  Entries for
 different variants are separated by blank lines.  Blank lines are
 illegal within an entry.  It is conventional to begin a map file with
 an entry for the combined entity as a whole (although this
 is not required, and if present will be ignored). An example
 map file is:
-
     
+
       URI: foo
 
   URI: foo.en.html
@@ -124,13 +129,14 @@ map file is:
   Content-language: en
 
   URI: foo.fr.de.html
-  Content-type: text/html; charset=iso-8859-2
+  Content-type: text/html;charset=iso-8859-2
   Content-language: fr, de
 
    
 
 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):
+
 
       URI: foo
 
@@ -142,14 +148,22 @@ as jpeg, gif, or ASCII-art):
 
   URI: foo.txt
   Content-type: text/plain; qs=0.01
-
 
    
 
    
 
-qs values can vary between 0.000 and 1.000. Note that any variant with
+qs values can vary in the range 0.000 to 1.000. Note that any variant with
 a qs value of 0.000 will never be chosen. Variants with no 'qs'
-parameter value are given a qs factor of 1.0.  
    
+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
+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 representation.  A qs value
+is therefore specific to a given variant depending on the nature of
+the resource it represents.
 
+
    
 The full list of headers recognized is:
 
 
    
@@ -160,22 +174,24 @@ The full list of headers recognized is:
        the same server (!), and they must refer to files to which the
        client would be granted access if they were to be requested
        directly.
-  
     Content-type:
+  
     Content-Type:
   
     media type --- charset, level and "qs" parameters may be given.  These
        are often referred to as MIME types; typical media types are
        image/gif, text/plain, or
        text/html; level=3.
-  
     Content-language:
+  
     Content-Language:
   
     The languages of the variant, specified as an Internet standard
-       language code (e.g., en for English,
+       language tag from RFC 1766 (e.g., en for English,
        kr for Korean, etc.).
-  
     Content-encoding:
+  
     Content-Encoding:
   
     If the file is compressed, or otherwise encoded, rather than
        containing the actual raw data, this says how that was done.
-       For compressed files (the only case where this generally comes
-       up), content encoding should be
-       x-compress, or x-gzip, as appropriate.
-  
     Content-length:
+       Apache only recognizes encodings that are defined by an
+       AddEncoding directive.
+       This normally includes the encodings x-compress
+       for compress'd files, and x-gzip for gzip'd files.
+       The x- prefix is ignored for encoding comparisons.
+  
     Content-Length:
   
     The size of the file.  Clients can ask to receive a given media
        type only if the variant isn't too big; specifying a content
        length in the map allows the server to compare against these
@@ -185,17 +201,15 @@ The full list of headers recognized is:
 
    Multiviews
    
 
 
    
-This is a per-directory option, meaning it can be set with an
-Options directive within a <Directory>,
+MultiViews is a per-directory option, meaning it can be set with
+an Options directive within a <Directory>,
 <Location> or <Files>
 section in access.conf, or (if AllowOverride
 is properly set) in .htaccess files.  Note that
 Options All does not set MultiViews; you
-have to ask for it by name.  (Fixing this is a one-line change to
-http_core.h).
+have to ask for it by name.
 
 
    
-
 The effect of MultiViews is as follows: if the server
 receives a request for /some/dir/foo, if
 /some/dir has MultiViews enabled, and
@@ -204,23 +218,22 @@ directory looking for 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 forwards them along.
+requirements.
 
 
    
-
-This applies to searches for the file named by the
+MultiViews may also apply to searches for the file named by the
 DirectoryIndex directive, if the server is trying to
-index a directory; if the configuration files specify
-
    +index a directory. If the configuration files specify
 
+
       DirectoryIndex index
+
    
 
-
     then the server will arbitrate between index.html
+then the server will arbitrate between index.html
 and index.html3 if both are present.  If neither are
 present, and index.cgi is there, the server will run it.
 
 
    
-
 If one of the files found when reading the directive is a CGI script,
 it's not obvious what should happen.  The code gives that case
 special treatment --- if the request was a POST, or a GET with
@@ -233,7 +246,7 @@ to be retrieved.
 
 After Apache 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
-applies a algorithm to decide on the 'best' variant to return, if
+applies an algorithm to decide on the 'best' variant to return, if
 any. To do this it calculates a quality value for each variant in each
 of the dimensions of variance. It is not necessary to know any of the
 details of how negotiation actually takes place in order to use Apache's
@@ -247,22 +260,28 @@ fiddle quality factors is explained in more detail below.
 
    Dimensions of Negotiation
    
 
 
-
+
+
+
+
+
    Dimension
+
    Dimension
 Notes
-
    Media Type
-Browser indicates preferences on Accept: header. Each item
+
    Media Type
+Browser indicates preferences with the Accept header field. Each item
 can have an associated quality factor. Variant description can also
-have a quality factor.
-
    Language
-Browser indicates preferences on Accept-Language: header. Each
-item
-can have a quality factor. Variants can be associated with none, one
-or more languages.
-
    Encoding
-Browser indicates preference with Accept-Encoding: header.
-
    Charset
-Browser indicates preference with Accept-Charset: header. Variants
-can indicate a charset as a parameter of the media type.
+have a quality factor (the "qs" parameter).
+
    Language
+Browser indicates preferences with the Accept-Language header field.
+Each item can have a quality factor. Variants can be associated with none, one
+or more than one language.
+
    Encoding
+Browser indicates preference with the Accept-Encoding header field.
+Each item can have a quality factor.
+
    Charset
+Browser indicates preference with the Accept-Charset header field.
+Each item can have a quality factor.
+Variants can indicate a charset as a parameter of the media type.
 
    
 
 
    Apache Negotiation Algorithm
    
@@ -270,13 +289,13 @@ can indicate a charset as a parameter of the media type.
 
    
 Apache uses an algorithm to select the 'best' variant (if any) to
 return to the browser. This algorithm is not configurable. It operates
-like this:
+as follows:
 
 
      
 
    1. 
-Firstly, for each dimension of the negotiation, the appropriate
-Accept header is checked and a quality assigned to this each
-variant. If the Accept header for any dimension means that this
+First, for each dimension of the negotiation, the appropriate
+Accept* header field is checked and a quality assigned to each
+variant. If the Accept* header for any dimension means that this
 variant is not acceptable, eliminate it. If no variants remain, go
 to step 4.
 
@@ -284,7 +303,7 @@ to step 4.
 the following tests is applied in order. Any variants not selected at
 each stage are eliminated. After each test, if only one variant
 remains, it is selected as the best match. If more than one variant
-remains, move onto the next test.
+remains, move on to the next test.
 
 
        
 
      1. Multiply the quality factor from the Accept header with the
@@ -301,6 +320,11 @@ remains, move onto the next test.
 
      2. Select the variants with the highest 'level' media parameter
   (used to give the version of text/html media types).
 
+
      3. Select only variants with acceptable charset media parameters,
+  as given on the Accept-Charset header line. Charset ISO-8859-1
+  is acceptable unless explicitly excluded. Variants not associated
+  with a particular charset are assumed to be in ISO-8859-1.
+
 
      4. Select the variants with the best encoding. If there are
   variants with an encoding that is acceptable to the user-agent,
   select only these variants. Otherwise if there is a mix of encoded
@@ -308,16 +332,11 @@ remains, move onto the next test.
   If either all variants are encoded or all variants are not encoded, 
   select all variants.
 
-
      5. Select only variants with acceptable charset media parameters,
-  as given on the Accept-Charset header line. Charset ISO-8859-1
-  is always acceptable. Variants not associated with a particular
-  charset are assumed to be in ISO-8859-1.
-
 
      6. Select the variants with the smallest content length
 
 
      7. Select the first variant of those remaining (this will be either the
-first listed in the type-map file, or the first read from the directory)
-and go to stage 3.
+  first listed in the type-map file, or the first read from the directory)
+  and go to stage 3.
 
 
      
 
@@ -326,7 +345,7 @@ and go to stage 3.
   dimensions of negotiation (browsers and caches can use this
   information when caching the resource). End.
 
-
    2. To get here means no variant was selected (because non are acceptable
+
    3. To get here means no variant was selected (because none are acceptable
   to the browser). Return a 406 status (meaning "No acceptable representation")
   with a response body consisting of an HTML document listing the
   available variants. Also set the HTTP Vary header to indicate the
@@ -508,12 +527,11 @@ if there is one) must be on the right hand side of the MIME-type extension
 
      Note on Caching
      
 
 
      
-When a cache stores a document, it associates it with the request URL.
+When a cache stores a representation, it associates it with the request URL.
 The next time that URL is requested, the cache can use the stored
-document, provided it is still within date. But if the resource is
-subject to content negotiation at the server, this would result in
-only the first requested variant being cached, and subsequent cache
-hits could return the wrong response. To prevent this,
+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 marks all responses that are returned after content negotiation
 as non-cacheable by HTTP/1.0 clients. Apache also supports the HTTP/1.1
 protocol features to allow caching of negotiated responses. 
      
@@ -522,8 +540,7 @@ For requests which come from a HTTP/1.0 compliant client (either a
 browser or a cache), the directive CacheNegotiatedDocs can be
 used to allow caching of responses which were subject to negotiation.
 This directive can be given in the server config or virtual host, and
-takes no arguments. It has no effect on requests from HTTP/1.1
-clients.
+takes no arguments. It has no effect on requests from HTTP/1.1 clients.
 
 
 
diff --git a/docs/manual/mod/mod_negotiation.html b/docs/manual/mod/mod_negotiation.html
index a7d19896c4..96222acb22 100644
--- a/docs/manual/mod/mod_negotiation.html
+++ b/docs/manual/mod/mod_negotiation.html
@@ -46,26 +46,35 @@ The headers allowed are:
 
 
      
 
      Content-Encoding:
-
      The encoding of the file. Currently only two encodings are recognized
-by http; x-compress for compressed files, and x-gzip
-for gzipped files.
+
      The encoding of the file. Apache only recognizes encodings that are
+defined by an AddEncoding directive.
+This normally includes the encodings x-compress for compress'd
+files, and x-gzip for gzip'd files.  The x- prefix
+is ignored for encoding comparisons.
 
      Content-Language:
-
      The language of the variant, as an Internet standard language code, such
-as en.
+
      The language of the variant, as an Internet standard language tag
+(RFC 1766).  An example is en, meaning English.
 
      Content-Length:
 
      The length of the file, in bytes. If this header is not present, then
 the actual length of the file is used.
 
      Content-Type:
 
      The MIME media type of the document, with optional parameters.
-parameters are separated from the media type and from one another by
-semi-colons. Parameter syntax is name=value; allowed parameters are:
+Parameters are separated from the media type and from one another by a
+semi-colon, with a syntax of name=value. Common parameters
+include:
 
      
 
      level
-
      the value is an integer, which specifies the version of the media type.
+
      an integer specifying the version of the media type.
 For text/html this defaults to 2, otherwise 0.
 
      qs
-
      the value is a floating-point number with value between 0. and 1.
-It indications the 'quality' of this variant.
+
      a floating-point number with a value in the range 0.0 to 1.0,
+    indicating 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 attempting to represent a
+    photograph.  However, if the resource being represented is ascii art,
+    then an ascii file would have a higher source quality than a jpeg file.
+    All qs values are therefore specific to a given resource.
 
      
 Example:
 
      Content-Type: image/jpeg; qs=0.8
      
@@ -91,6 +100,14 @@ requirements, and returns that document.
      
 
    4. CacheNegotiatedDocs
 
    5. LanguagePriority
 
+
+See also:
+DefaultLanguage,
+AddEncoding,
+AddLanguage,
+AddType, and
+Option.
+