Typos and other minor mistakes

named <code>type-map</code> (or, for backwards-compatibility with

older Apache configurations, the mime type

<code>application/x-type-map</code>).  Note that to use this feature,

you've got to have an <code>SetHanlder</code> some place which defines a

you've got to have an <code>SetHandler</code> some place which defines a

file suffix as <code>type-map</code>; this is best done with a

<pre>

       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

       <code>x-compress</code>, or <code>gzip</code>, as appropriate.

       <code>x-compress</code>, or <code>x-gzip</code>, as appropriate.

  <dt> <code>Content-length:</code>

  <dd> 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

<h3>Multiviews</h3>

This is a per-directory option, meaning it can be set with an

<code>Options</code> directive within a <code>&lt;Directory&gt;</code>

<code>Options</code> directive within a <code>&lt;Directory&gt;</code>,

<code>&lt;Location&gt;</code> or <code>&lt;Files&gt;</code>

section in <code>access.conf</code>, or (if <code>AllowOverride</code>

is properly set) in <code>.htaccess</code> files.  Note that

<code>Options All</code> does not set <code>MultiViews</code>; you

have to ask for it by name.  (Fixing this is a one-line change to

<code>httpd.h</code>).

<code>http_core.h</code>).

<p>

<th>Notes

<tr><td>Media Type

<td>Browser indicates preferences on Accept: header. Each item 

can have an associate quality factor. Variant description can also

can have an associated quality factor. Variant description can also

have a quality factor.

<tr><td>Language

<td>Browser indicates preferneces on Accept-Language: header. Each

<tr><td>Encoding

<td>Browser indicates preference with Accept-Encoding: header.

<tr><td>Charset

<td>Browser indicates preference with Accept-Charset: header. Variant

<td>Browser indicates preference with Accept-Charset: header. Variants

can indicate a charset as a parameter of the media type.

</table>

<li>Select the variants with the highest language quality factor

<li>Select the variants with the best language match, using either the

  order of languages on the LanguagePriority directive (if present),

  order of languages on the <code>LanguagePriority</code> directive (if present),

  else the order of languages on the Accept-Language header.

<li>Select the variants with the highest 'level' media parameter

</ol>

<li>The algorithm has now select one 'best' variant, so return

  it as the response. The HTTP header Vary is set to indicate the

  dimensions of negotations (browsers and caches can use this

<li>The algorithm has now selected one 'best' variant, so return

  it as the response. The HTTP response header Vary is set to indicate the

  dimensions of negotation (browsers and caches can use this

  information when caching the resource). End.

<li>To get here means no variant was selected (because non are acceptable

  to the browser. Return a 406 status (meaning "No acceptable representation")

  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

  dimensions of variance.

Apache sometimes changes the quality values from what would be

expected by a strict interpretation of the algorithm above. This is to

get a netter result from the algorithm for browsers which do not send

get a better result from the algorithm for browsers which do not send

full or accurate information. Some of the most popular browsers send

Accept header information which would otherwise result in the

selection of the wrong variant in many cases. If a browser

<h3>Media Types and Wildcards</h3>

The Accept: request header indicates preferneces for media types. It

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:

<pre>

  Accept: image/*, */*

</pre>

would indicate that any type starting "image/" would be acceptable,

as would any other type (so the first "image/*" is redundant). Some

browsers routinly send wildcards in addition to explicit types they

would indicate that any type starting "image/" is acceptable,

as is any other type (so the first "image/*" is redundant). Some

browsers routinely send wildcards in addition to explicit types they

can handle. For example:

<pre>

  Accept: text/html, text/plain, image/gif, image/jpeg, */*

</pre>

The intention of this result is to indicate that the explicitly

The intention of this is to indicate that the explicitly

listed types are preferred, but if a different representation is

available, that is ok too. However under the basic algoryth, as given

available, that is ok too. However under the basic algorithm, as given

above, the */* wildcard has exactly equal preference to all the other

types, so they are not being preferred. The browser should really have

sent a request with a lower quality (preference) value for *.*, such

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, by default

Apache marks all response that are returned after content negotiation

as non-cacheable. Unfortunately, this can increase network traffic by

requiring the resouce to be obtained from the original server evry

time. The HTTP/1.1 protocol includes features to make this much more

efficient, by allowing cacheing.  <p>

For requrests which come from a HTTP/1.0 compliant client (either a

hits could 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 cacheing of negotiated responses. <P>

For requests which come from a HTTP/1.0 compliant client (either a

browser or a cache), the directive <tt>CacheNegotiatedDocs</tt> 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

named <code>type-map</code> (or, for backwards-compatibility with

older Apache configurations, the mime type

<code>application/x-type-map</code>).  Note that to use this feature,

you've got to have an <code>SetHanlder</code> some place which defines a

you've got to have an <code>SetHandler</code> some place which defines a

file suffix as <code>type-map</code>; this is best done with a

<pre>

       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

       <code>x-compress</code>, or <code>gzip</code>, as appropriate.

       <code>x-compress</code>, or <code>x-gzip</code>, as appropriate.

  <dt> <code>Content-length:</code>

  <dd> 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

<h3>Multiviews</h3>

This is a per-directory option, meaning it can be set with an

<code>Options</code> directive within a <code>&lt;Directory&gt;</code>

<code>Options</code> directive within a <code>&lt;Directory&gt;</code>,

<code>&lt;Location&gt;</code> or <code>&lt;Files&gt;</code>

section in <code>access.conf</code>, or (if <code>AllowOverride</code>

is properly set) in <code>.htaccess</code> files.  Note that

<code>Options All</code> does not set <code>MultiViews</code>; you

have to ask for it by name.  (Fixing this is a one-line change to

<code>httpd.h</code>).

<code>http_core.h</code>).

<p>

<th>Notes

<tr><td>Media Type

<td>Browser indicates preferences on Accept: header. Each item 

can have an associate quality factor. Variant description can also

can have an associated quality factor. Variant description can also

have a quality factor.

<tr><td>Language

<td>Browser indicates preferneces on Accept-Language: header. Each

<tr><td>Encoding

<td>Browser indicates preference with Accept-Encoding: header.

<tr><td>Charset

<td>Browser indicates preference with Accept-Charset: header. Variant

<td>Browser indicates preference with Accept-Charset: header. Variants

can indicate a charset as a parameter of the media type.

</table>

<li>Select the variants with the highest language quality factor

<li>Select the variants with the best language match, using either the

  order of languages on the LanguagePriority directive (if present),

  order of languages on the <code>LanguagePriority</code> directive (if present),

  else the order of languages on the Accept-Language header.

<li>Select the variants with the highest 'level' media parameter

</ol>

<li>The algorithm has now select one 'best' variant, so return

  it as the response. The HTTP header Vary is set to indicate the

  dimensions of negotations (browsers and caches can use this

<li>The algorithm has now selected one 'best' variant, so return

  it as the response. The HTTP response header Vary is set to indicate the

  dimensions of negotation (browsers and caches can use this

  information when caching the resource). End.

<li>To get here means no variant was selected (because non are acceptable

  to the browser. Return a 406 status (meaning "No acceptable representation")

  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

  dimensions of variance.

Apache sometimes changes the quality values from what would be

expected by a strict interpretation of the algorithm above. This is to

get a netter result from the algorithm for browsers which do not send

get a better result from the algorithm for browsers which do not send

full or accurate information. Some of the most popular browsers send

Accept header information which would otherwise result in the

selection of the wrong variant in many cases. If a browser

<h3>Media Types and Wildcards</h3>

The Accept: request header indicates preferneces for media types. It

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:

<pre>

  Accept: image/*, */*

</pre>

would indicate that any type starting "image/" would be acceptable,

as would any other type (so the first "image/*" is redundant). Some

browsers routinly send wildcards in addition to explicit types they

would indicate that any type starting "image/" is acceptable,

as is any other type (so the first "image/*" is redundant). Some

browsers routinely send wildcards in addition to explicit types they

can handle. For example:

<pre>

  Accept: text/html, text/plain, image/gif, image/jpeg, */*

</pre>

The intention of this result is to indicate that the explicitly

The intention of this is to indicate that the explicitly

listed types are preferred, but if a different representation is

available, that is ok too. However under the basic algoryth, as given

available, that is ok too. However under the basic algorithm, as given

above, the */* wildcard has exactly equal preference to all the other

types, so they are not being preferred. The browser should really have

sent a request with a lower quality (preference) value for *.*, such

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, by default

Apache marks all response that are returned after content negotiation

as non-cacheable. Unfortunately, this can increase network traffic by

requiring the resouce to be obtained from the original server evry

time. The HTTP/1.1 protocol includes features to make this much more

efficient, by allowing cacheing.  <p>

For requrests which come from a HTTP/1.0 compliant client (either a

hits could 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 cacheing of negotiated responses. <P>

For requests which come from a HTTP/1.0 compliant client (either a

browser or a cache), the directive <tt>CacheNegotiatedDocs</tt> 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