Apache -> httpd

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@922240 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 26 insertions, 26 deletions

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 @@
 
 <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 choosing the best variant.</p>
     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 choosing the best variant.</p>
     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