Big spelling and HTML cleanup of docs. Thanks go to weblint and ispell

main server what addresses and ports to listen to.  If no

<VirtualHost> directives are used, the server will behave the

same for all accepted requests. However, <VirtualHost> can be

used to specify a different behavour for one or more of the addresses

used to specify a different behavior for one or more of the addresses

and ports. To implement a VirtualHost, the server must first be told

to listen to the address and port to be used. Then a

<VirtualHost> section should be created for a specified address

<a href="dns-caveats.html">DNS Issues</a>

and

<a href="mod/core.html#virtualhost">&lt;VirtualHost&gt; section</a>.

</ul>

<!--#include virtual="footer.html" -->

</BODY>

main server what addresses and ports to listen to.  If no

<VirtualHost> directives are used, the server will behave the

same for all accepted requests. However, <VirtualHost> can be

used to specify a different behavour for one or more of the addresses

used to specify a different behavior for one or more of the addresses

and ports. To implement a VirtualHost, the server must first be told

to listen to the address and port to be used. Then a

<VirtualHost> section should be created for a specified address

<a href="dns-caveats.html">DNS Issues</a>

and

<a href="mod/core.html#virtualhost">&lt;VirtualHost&gt; section</a>.

</ul>

<!--#include virtual="footer.html" -->

</BODY>

<p>As implemented in Apache 1.1.1 and earlier versions, the method

Apache used to create PATH_INFO in the CGI environment was

counterintiutive, and could result in crashes in certain cases. In

counterintuitive, and could result in crashes in certain cases. In

Apache 1.2 and beyond, this behavior has changed. Although this

results in some compatibility problems with certain legacy CGI

applications, the Apache 1.2 behavior is still compatible with the

example, PATH_INFO would be set to "<code>/script</code>", and

SCRIPT_NAME to "<code>/cgi-ralph</code>". This makes sense and results

in no server behavior problems. It also permits the script to be

gauranteed that

guaranteed that

"<code>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</code>"

will always be an accessable URL that points to the current script,

something which was not neccessarily true with previous versions of

will always be an accessible URL that points to the current script,

something which was not necessarily true with previous versions of

Apache.

<p>However, the "<code>/ralph</code>"

<h2><a name="compat">Compatibility with Previous Servers</a></h2>

<p>It may be neccessary for a script that was designed for earlier

<p>It may be necessary for a script that was designed for earlier

versions of Apache or other servers to need the information that the

old PATH_INFO variable provided. For this purpose, Apache 1.2 (1.2b3

and later) sets an additional variable, FILEPATH_INFO. This

with Apache 1.1.1.</p>

<p>A script that wishes to work with both Apache 1.2 and earlier

versions can simply test for the existance of FILEPATH_INFO, and use

versions can simply test for the existence of FILEPATH_INFO, and use

it if available. Otherwise, it can use PATH_INFO. For example, in

Perl, one might use:

<pre>

<p>As implemented in Apache 1.1.1 and earlier versions, the method

Apache used to create PATH_INFO in the CGI environment was

counterintiutive, and could result in crashes in certain cases. In

counterintuitive, and could result in crashes in certain cases. In

Apache 1.2 and beyond, this behavior has changed. Although this

results in some compatibility problems with certain legacy CGI

applications, the Apache 1.2 behavior is still compatible with the

example, PATH_INFO would be set to "<code>/script</code>", and

SCRIPT_NAME to "<code>/cgi-ralph</code>". This makes sense and results

in no server behavior problems. It also permits the script to be

gauranteed that

guaranteed that

"<code>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</code>"

will always be an accessable URL that points to the current script,

something which was not neccessarily true with previous versions of

will always be an accessible URL that points to the current script,

something which was not necessarily true with previous versions of

Apache.

<p>However, the "<code>/ralph</code>"

<h2><a name="compat">Compatibility with Previous Servers</a></h2>

<p>It may be neccessary for a script that was designed for earlier

<p>It may be necessary for a script that was designed for earlier

versions of Apache or other servers to need the information that the

old PATH_INFO variable provided. For this purpose, Apache 1.2 (1.2b3

and later) sets an additional variable, FILEPATH_INFO. This

with Apache 1.1.1.</p>

<p>A script that wishes to work with both Apache 1.2 and earlier

versions can simply test for the existance of FILEPATH_INFO, and use

versions can simply test for the existence of FILEPATH_INFO, and use

it if available. Otherwise, it can use PATH_INFO. For example, in

Perl, one might use:

<pre>

As an example of a more complex request, this browser has been

configured to accept French and English, but prefer French, and to

accept various media types, preferring HTML over plain text or other

text types, and prefering GIF or jpeg over other media types, but also

text types, and preferring GIF or JPEG over other media types, but also

allowing any other media type as a last resort:

<pre>

       <code>image/gif</code>, <code>text/plain</code>, or

       <code>text/html;&nbsp;level=3</code>.

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

  <dd> The languages of the variant, specified as an internet standard

  <dd> The languages of the variant, specified as an Internet standard

       language code (e.g., <code>en</code> for English,

       <code>kr</code> for Korean, etc.).

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

applies a 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 negotaion actually takes place in order to use Apache's

content negotation features. However the rest of this document

details of how negotiation actually takes place in order to use Apache's

content negotiation features. However the rest of this document

explains in detail the algorithm used for those interested.  <p>

In some circumstances, Apache can 'fiddle' the quality factor of a

particular dimension to achive a better result. The ways Apache can

particular dimension to achieve a better result. The ways Apache can

fiddle quality factors is explained in more detail below.

<h3>Dimensions of Negotation</h3>

<h3>Dimensions of Negotiation</h3>

<table>

<tr><th>Dimension

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

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

item

can have a quality factor. Variants can be associated with none, one

or more languages.

<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

  dimensions of negotiation (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

If the Accept: header contains <i>no</i> q factors at all, Apache sets

the q value of "*/*", if present, to 0.01 to emulate the desired

behaviour. It also sets the q value of wildcards of the format

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 <i>not</i> applied, so requests from browsers

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>

protocol features to allow caching 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