You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2010/03/12 13:39:42 UTC
svn commit: r922240 - in /httpd/httpd/trunk/docs/manual:
content-negotiation.html.en content-negotiation.xml
Author: rbowen
Date: Fri Mar 12 12:39:41 2010
New Revision: 922240
URL: http://svn.apache.org/viewvc?rev=922240&view=rev
Log:
Apache -> httpd
Modified:
httpd/httpd/trunk/docs/manual/content-negotiation.html.en
httpd/httpd/trunk/docs/manual/content-negotiation.xml
Modified: httpd/httpd/trunk/docs/manual/content-negotiation.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/content-negotiation.html.en?rev=922240&r1=922239&r2=922240&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/content-negotiation.html.en (original)
+++ httpd/httpd/trunk/docs/manual/content-negotiation.html.en Fri Mar 12 12:39:41 2010
@@ -25,7 +25,7 @@
</div>
- <p>Apache supports content negotiation as described in
+ <p>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.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="./images/down.gif" /> <a href="#about">About Content Negotiation</a></li>
-<li><img alt="" src="./images/down.gif" /> <a href="#negotiation">Negotiation in Apache</a></li>
+<li><img alt="" src="./images/down.gif" /> <a href="#negotiation">Negotiation in httpd</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#methods">The Negotiation Methods</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#better">Fiddling with Quality
Values</a></li>
@@ -81,17 +81,17 @@ Negotiation</a></li>
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
</code></p></div>
- <p>Apache supports 'server driven' content negotiation, as
+ <p>httpd supports 'server driven' content negotiation, as
defined in the HTTP/1.1 specification. It fully supports the
<code>Accept</code>, <code>Accept-Language</code>,
<code>Accept-Charset</code> and<code>Accept-Encoding</code>
- 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.</p>
<p>A <strong>resource</strong> 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 <strong>representations</strong> 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</a></li>
the <strong>dimensions</strong> of negotiation.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
-<h2><a name="negotiation" id="negotiation">Negotiation in Apache</a></h2>
+<h2><a name="negotiation" id="negotiation">Negotiation in httpd</a></h2>
<p>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></li>
<p>A type map is a document which is associated with the handler
named <code>type-map</code> (or, for backwards-compatibility with
- older Apache configurations, the <a class="glossarylink" href="./glossary.html#mime-type" title="see glossary">MIME-type</a>
+ older httpd configurations, the <a class="glossarylink" href="./glossary.html#mime-type" title="see glossary">MIME-type</a>
<code>application/x-type-map</code>). Note that to use this
feature, you must have a handler set in the configuration that
defines a file suffix as <code>type-map</code>; this is best done
@@ -234,24 +234,24 @@ Negotiation</a></li>
<div class="section">
<h2><a name="methods" id="methods">The Negotiation Methods</a></h2>
- <p>After Apache has obtained a list of the variants for a given
+ <p>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. </p>
<p>There are two negotiation methods:</p>
<ol>
- <li><strong>Server driven negotiation with the Apache
- algorithm</strong> is used in the normal case. The Apache
+ <li><strong>Server driven negotiation with the httpd
+ algorithm</strong> 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.</li>
<li><strong>Transparent content negotiation</strong> is used
@@ -260,7 +260,7 @@ Negotiation</a></li>
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.</li>
</ol>
@@ -311,9 +311,9 @@ Negotiation</a></li>
</table>
-<h3><a name="algorithm" id="algorithm">Apache Negotiation Algorithm</a></h3>
+<h3><a name="algorithm" id="algorithm">httpd Negotiation Algorithm</a></h3>
- <p>Apache can use the following algorithm to select the 'best'
+ <p>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:</p>
@@ -401,8 +401,8 @@ Negotiation</a></li>
<h2><a name="better" id="better">Fiddling with Quality
Values</a></h2>
- <p>Apache sometimes changes the quality values from what would
- be expected by a strict interpretation of the Apache
+ <p>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</a></li>
no variant matches an explicitly listed type.</p>
<p>If the <code>Accept:</code> header contains <em>no</em> 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</a></li>
<h3><a name="exceptions" id="exceptions">Language Negotiation Exceptions</a></h3>
- <p>New in Apache 2.0, some exceptions have been added to the
+ <p>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.</p>
@@ -461,7 +461,7 @@ Negotiation</a></li>
<code>Accept-language</code> 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 <code>Accept-language</code> in these cases and provide a
document that does not explicitly match the client's request. The
<code class="directive"><a href="./mod/mod_negotiation.html#forcelanguagepriority">ForceLanguagePriority</a></code>
@@ -484,7 +484,7 @@ Negotiation</a></li>
language match is possible and the server is about to return a "No
Acceptable Variants" error or fallback to the <code class="directive"><a href="./mod/mod_negotiation.html#languagepriority">LanguagePriority</a></code>, the server
will ignore the subset specification and match <code>en-GB</code>
- against <code>en</code> documents. Implicitly, Apache will add
+ against <code>en</code> 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</a></li>
<p>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 <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> recognizes
+ since httpd 2.0.47 <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> recognizes
the <a href="env.html">environment variable</a>
<code>prefer-language</code>. If it exists and contains an
appropriate language tag, <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> will
@@ -512,7 +512,7 @@ Negotiation</a></li>
<h2><a name="extensions" id="extensions">Extensions to Transparent Content
Negotiation</a></h2>
-<p>Apache extends the transparent content negotiation protocol (RFC
+<p>httpd extends the transparent content negotiation protocol (RFC
2295) as follows. A new <code>{encoding ..}</code> 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 choos
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.</p>
@@ -653,7 +653,7 @@ factors to 5 decimal places before choos
virtual host, and takes no arguments. It has no effect on requests
from HTTP/1.1 clients.</p>
- <p>For HTTP/1.1 clients, Apache sends a <code>Vary</code> HTTP
+ <p>For HTTP/1.1 clients, httpd sends a <code>Vary</code> 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
Modified: httpd/httpd/trunk/docs/manual/content-negotiation.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/content-negotiation.xml?rev=922240&r1=922239&r2=922240&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/content-negotiation.xml (original)
+++ httpd/httpd/trunk/docs/manual/content-negotiation.xml Fri Mar 12 12:39:41 2010
@@ -26,7 +26,7 @@
<summary>
- <p>Apache supports content negotiation as described in
+ <p>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
</example>
- <p>Apache supports 'server driven' content negotiation, as
+ <p>httpd supports 'server driven' content negotiation, as
defined in the HTTP/1.1 specification. It fully supports the
<code>Accept</code>, <code>Accept-Language</code>,
<code>Accept-Charset</code> and<code>Accept-Encoding</code>
- 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.</p>
<p>A <strong>resource</strong> 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 <strong>representations</strong> 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 <strong>dimensions</strong> of negotiation.</p>
</section>
-<section id="negotiation"><title>Negotiation in Apache</title>
+<section id="negotiation"><title>Negotiation in httpd</title>
<p>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 @@
<p>A type map is a document which is associated with the handler
named <code>type-map</code> (or, for backwards-compatibility with
- older Apache configurations, the <glossary>MIME-type</glossary>
+ older httpd configurations, the <glossary>MIME-type</glossary>
<code>application/x-type-map</code>). Note that to use this
feature, you must have a handler set in the configuration that
defines a file suffix as <code>type-map</code>; this is best done
@@ -231,24 +231,24 @@
<section id="methods"><title>The Negotiation Methods</title>
- <p>After Apache has obtained a list of the variants for a given
+ <p>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. </p>
<p>There are two negotiation methods:</p>
<ol>
- <li><strong>Server driven negotiation with the Apache
- algorithm</strong> is used in the normal case. The Apache
+ <li><strong>Server driven negotiation with the httpd
+ algorithm</strong> 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.</li>
<li><strong>Transparent content negotiation</strong> 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.</li>
</ol>
@@ -308,9 +308,9 @@
</table>
</section>
-<section id="algorithm"><title>Apache Negotiation Algorithm</title>
+<section id="algorithm"><title>httpd Negotiation Algorithm</title>
- <p>Apache can use the following algorithm to select the 'best'
+ <p>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:</p>
@@ -398,8 +398,8 @@
<section id="better"><title>Fiddling with Quality
Values</title>
- <p>Apache sometimes changes the quality values from what would
- be expected by a strict interpretation of the Apache
+ <p>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.</p>
<p>If the <code>Accept:</code> header contains <em>no</em> 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 @@
<section id="exceptions"><title>Language Negotiation Exceptions</title>
- <p>New in Apache 2.0, some exceptions have been added to the
+ <p>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.</p>
@@ -458,7 +458,7 @@
<code>Accept-language</code> 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 <code>Accept-language</code> in these cases and provide a
document that does not explicitly match the client's request. The
<directive
@@ -483,7 +483,7 @@
Acceptable Variants" error or fallback to the <directive
module="mod_negotiation">LanguagePriority</directive>, the server
will ignore the subset specification and match <code>en-GB</code>
- against <code>en</code> documents. Implicitly, Apache will add
+ against <code>en</code> 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 @@
<p>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 <module>mod_negotiation</module> recognizes
+ since httpd 2.0.47 <module>mod_negotiation</module> recognizes
the <a href="env.html">environment variable</a>
<code>prefer-language</code>. If it exists and contains an
appropriate language tag, <module>mod_negotiation</module> will
@@ -511,7 +511,7 @@
<section id="extensions"><title>Extensions to Transparent Content
Negotiation</title>
-<p>Apache extends the transparent content negotiation protocol (RFC
+<p>httpd extends the transparent content negotiation protocol (RFC
2295) as follows. A new <code>{encoding ..}</code> 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 choos
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.</p>
@@ -655,7 +655,7 @@ factors to 5 decimal places before choos
virtual host, and takes no arguments. It has no effect on requests
from HTTP/1.1 clients.</p>
- <p>For HTTP/1.1 clients, Apache sends a <code>Vary</code> HTTP
+ <p>For HTTP/1.1 clients, httpd sends a <code>Vary</code> 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