Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

This commit was manufactured by cvs2svn to create tag

'apache-1_3-merge-2-pre'.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/tags/apache-1_3-merge-2-pre@83687 13f79535-47bb-0310-9956-ffa450edef68
  • Loading branch information...
commit b4bca9791178730a2fbeb6dc557514851a56112d 1 parent e73a0bb
No Author authored
Showing with 0 additions and 30,676 deletions.
  1. +0 −295 build/binbuild.sh
  2. BIN  docs/docroot/apache_pb.gif
  3. +0 −59 docs/manual/LICENSE
  4. +0 −135 docs/manual/bind.html
  5. +0 −135 docs/manual/bind.html.en
  6. +0 −93 docs/manual/cgi_path.html
  7. +0 −93 docs/manual/cgi_path.html.en
  8. +0 −588 docs/manual/content-negotiation.html
  9. +0 −588 docs/manual/content-negotiation.html.en
  10. +0 −177 docs/manual/custom-error.html
  11. +0 −177 docs/manual/custom-error.html.en
  12. +0 −1,153 docs/manual/developer/API.html
  13. +0 −189 docs/manual/dns-caveats.html
  14. +0 −392 docs/manual/dso.html
  15. +0 −392 docs/manual/dso.html.en
  16. +0 −497 docs/manual/ebcdic.html
  17. +0 −64 docs/manual/env.html
  18. +0 −64 docs/manual/env.html.en
  19. +0 −104 docs/manual/expand.pl
  20. +0 −6 docs/manual/footer.html
  21. +0 −195 docs/manual/handler.html
  22. +0 −195 docs/manual/handler.html.en
  23. +0 −6 docs/manual/header.html
  24. BIN  docs/manual/images/custom_errordocs.gif
  25. BIN  docs/manual/images/home.gif
  26. BIN  docs/manual/images/index.gif
  27. +0 −60 docs/manual/images/mod_rewrite_fig1.fig
  28. BIN  docs/manual/images/mod_rewrite_fig1.gif
  29. +0 −50 docs/manual/images/mod_rewrite_fig2.fig
  30. BIN  docs/manual/images/mod_rewrite_fig2.gif
  31. BIN  docs/manual/images/sub.gif
  32. +0 −277 docs/manual/install-tpf.html
  33. +0 −270 docs/manual/install.html
  34. +0 −270 docs/manual/install.html.en
  35. +0 −220 docs/manual/invoking.html
  36. +0 −220 docs/manual/invoking.html.en
  37. +0 −68 docs/manual/location.html
  38. +0 −1,153 docs/manual/misc/API.html
  39. +0 −279 docs/manual/misc/FAQ-A.html
  40. +0 −378 docs/manual/misc/FAQ-B.html
  41. +0 −273 docs/manual/misc/FAQ-C.html
  42. +0 −370 docs/manual/misc/FAQ-D.html
  43. +0 −598 docs/manual/misc/FAQ-E.html
  44. +0 −524 docs/manual/misc/FAQ-F.html
  45. +0 −371 docs/manual/misc/FAQ-G.html
  46. +0 −265 docs/manual/misc/FAQ-H.html
  47. +0 −215 docs/manual/misc/FAQ-I.html
  48. +0 −111 docs/manual/misc/FAQ.html
  49. +0 −87 docs/manual/misc/client_block_api.html
  50. +0 −126 docs/manual/misc/compat_notes.html
  51. +0 −431 docs/manual/misc/custom_errordocs.html
  52. +0 −155 docs/manual/misc/descriptors.html
  53. +0 −324 docs/manual/misc/fin_wait_2.html
  54. +0 −8 docs/manual/misc/footer.html
  55. +0 −6 docs/manual/misc/header.html
  56. +0 −209 docs/manual/misc/howto.html
  57. +0 −151 docs/manual/misc/index.html
  58. +0 −305 docs/manual/misc/known_client_problems.html
  59. +0 −871 docs/manual/misc/perf-tuning.html
  60. +0 −232 docs/manual/misc/security_tips.html
  61. +0 −3,295 docs/manual/mod/core.html
  62. +0 −265 docs/manual/mod/directive-dict.html
  63. +0 −265 docs/manual/mod/directive-dict.html.en
  64. +0 −223 docs/manual/mod/directives.html
  65. +0 −8 docs/manual/mod/footer.html
  66. +0 −6 docs/manual/mod/header.html
  67. +0 −124 docs/manual/mod/index.html
  68. +0 −312 docs/manual/mod/mod_access.html
  69. +0 −126 docs/manual/mod/mod_actions.html
  70. +0 −405 docs/manual/mod/mod_alias.html
  71. +0 −68 docs/manual/mod/mod_asis.html
  72. +0 −214 docs/manual/mod/mod_auth.html
  73. +0 −363 docs/manual/mod/mod_auth_anon.html
  74. +0 −220 docs/manual/mod/mod_auth_db.html
  75. +0 −210 docs/manual/mod/mod_auth_dbm.html
  76. +0 −416 docs/manual/mod/mod_auth_digest.html
  77. +0 −814 docs/manual/mod/mod_autoindex.html
  78. +0 −143 docs/manual/mod/mod_cern_meta.html
  79. +0 −216 docs/manual/mod/mod_cgi.html
  80. +0 −103 docs/manual/mod/mod_dir.html
  81. +0 −137 docs/manual/mod/mod_env.html
  82. +0 −168 docs/manual/mod/mod_example.html
  83. +0 −327 docs/manual/mod/mod_expires.html
  84. +0 −121 docs/manual/mod/mod_headers.html
  85. +0 −329 docs/manual/mod/mod_imap.html
  86. +0 −420 docs/manual/mod/mod_include.html
  87. +0 −113 docs/manual/mod/mod_info.html
  88. +0 −73 docs/manual/mod/mod_isapi.html
  89. +0 −77 docs/manual/mod/mod_log_agent.html
  90. +0 −450 docs/manual/mod/mod_log_config.html
  91. +0 −117 docs/manual/mod/mod_log_referer.html
  92. +0 −538 docs/manual/mod/mod_mime.html
  93. +0 −275 docs/manual/mod/mod_mime_magic.html
  94. +0 −142 docs/manual/mod/mod_mmap_static.html
  95. +0 −201 docs/manual/mod/mod_negotiation.html
  96. +0 −1,162 docs/manual/mod/mod_proxy.html
  97. +0 −1,874 docs/manual/mod/mod_rewrite.html
  98. +0 −398 docs/manual/mod/mod_setenvif.html
  99. +0 −164 docs/manual/mod/mod_so.html
  100. +0 −122 docs/manual/mod/mod_speling.html
  101. +0 −131 docs/manual/mod/mod_status.html
  102. +0 −180 docs/manual/mod/mod_unique_id.html
  103. +0 −123 docs/manual/mod/mod_userdir.html
  104. +0 −199 docs/manual/mod/mod_usertrack.html
  105. +0 −311 docs/manual/mod/mod_vhost_alias.html
  106. +0 −254 docs/manual/platform/perf-bsd44.html
Sorry, we could not display the entire diff because it was too big.
295 build/binbuild.sh
View
@@ -1,295 +0,0 @@
-#!/bin/sh
-#
-# binbuild.sh - Builds an Apache binary distribution.
-# Initially written by Lars Eilebrecht <lars@apache.org>.
-#
-# This script falls under the Apache License.
-# See http://www.apache.org/docs/LICENSE
-
-
-CONFIGPARAM="--with-layout=BinaryDistribution --enable-module=most --enable-shared=max"
-APDIR=`pwd`
-APDIR=`basename $APDIR`
-VER=`echo $APDIR |sed s/apache_//`
-OS=`src/helpers/GuessOS`
-TAR="`src/helpers/PrintPath tar`"
-GTAR="`src/helpers/PrintPath gtar`"
-GZIP="`src/helpers/PrintPath gzip`"
-
-if [ x$1 != x ]
-then
- USER=$1
-else
- USER="`src/helpers/buildinfo.sh -n %u@%h%d`"
-fi
-
-if [ ! -f ./ABOUT_APACHE ]
-then
- echo "ERROR: The current directory contains no valid Apache distribution."
- echo "Please change the directory to the top level directory of a freshly"
- echo "unpacked Apache 1.3 source distribution and re-execute the script"
- echo "'./src/helpers/bindbuild.sh'."
- exit 1;
-fi
-
-if [ -d ./CVS ]
-then
- echo "ERROR: The current directory is a CVS checkout of Apache."
- echo "Only a standard Apache 1.3 source distribution should be used to"
- echo "create a binary distribution."
- exit 1;
-fi
-
-echo "Building Apache $VER binary distribution..."
-echo "Platform is \"$OS\"..."
-
-( echo "Build log for Apache binary distribution" && \
- echo "----------------------------------------------------------------------" && \
- ./configure $CONFIGPARAM && \
- echo "----------------------------------------------------------------------" && \
- make clean && \
- rm -rf bindist install-bindist.sh *.bindist
- echo "----------------------------------------------------------------------" && \
- make && \
- echo "----------------------------------------------------------------------" && \
- make install-quiet root="bindist/" && \
- echo "----------------------------------------------------------------------" && \
- make clean && \
- echo "----------------------------------------------------------------------" && \
- echo "[EOF]" \
-) > build.log 2>&1
-
-if [ ! -f ./bindist/bin/httpd ]
-then
- echo "ERROR: Failed to build Apache. See \"build.log\" for details."
- exit 1;
-fi
-
-echo "Binary image successfully created..."
-
-./bindist/bin/httpd -v
-
-echo "Creating supplementary files..."
-
-( echo " " && \
- echo "Apache $VER binary distribution" && \
- echo "================================" && \
- echo " " && \
- echo "This binary distribution is usable on a \"$OS\"" && \
- echo "system and was built by \"$USER\"." && \
- echo "" && \
- echo "The distribution contains all standard Apache modules as shared" && \
- echo "objects. This allows you to enable or disable particular modules" && \
- echo "with the LoadModule/AddModule directives in the configuration file" && \
- echo "without the need to re-compile Apache." && \
- echo "" && \
- echo "See \"INSTALL.bindist\" on how to install the distribution." && \
- echo " " && \
- echo "NOTE: Please do not send support-related mails to the address mentioned" && \
- echo " above or to any member of the Apache Group! Support questions" && \
- echo " should be directed to the \"comp.infosystems.www.servers.unix\"" && \
- echo " or \"comp.infosystems.www.servers.ms-windows\" newsgroup" && \
- echo " (as appropriate for the platform you use), where some of the" && \
- echo " Apache team lurk, in the company of many other Apache gurus" && \
- echo " who should be able to help." && \
- echo " If you think you found a bug in Apache or have a suggestion please" && \
- echo " visit the bug report page at http://www.apache.org/bug_report.html" && \
- echo " " && \
- echo "----------------------------------------------------------------------" && \
- ./bindist/bin/httpd -V && \
- echo "----------------------------------------------------------------------" \
-) > README.bindist
-cp README.bindist ../apache_$VER-$OS.README
-
-( echo " " && \
- echo "Apache $VER binary installation" && \
- echo "================================" && \
- echo " " && \
- echo "To install this binary distribution you have to execute the installation" && \
- echo "script \"install-bindist.sh\" in the top-level directory of the distribution." && \
- echo " " && \
- echo "The script takes the ServerRoot directory into which you want to install" && \
- echo "Apache as an option. If you ommit the option the default path" && \
- echo "\"/usr/local/apache\" is used." && \
- echo "Make sure you have write permissions in the target directory, e.g. switch" && \
- echo "to user \"root\" before you execute the script." && \
- echo " " && \
- echo "See \"README.bindist\" for further details about this distribution." && \
- echo " " && \
- echo "Please note that this distribution includes the complete Apache source code." && \
- echo "Therefore you may compile Apache yourself at any time if you have a compiler" && \
- echo "installation on your system." && \
- echo "See \"INSTALL\" for details on how to accomplish this." && \
- echo " " \
-) > INSTALL.bindist
-
-( echo "#!/bin/sh" && \
- echo "#" && \
- echo "# Usage: install-bindist.sh [ServerRoot]" && \
- echo "# This script installs the Apache binary distribution and" && \
- echo "# was automatically created by binbuild.sh." && \
- echo " " && \
- echo "lmkdir()" && \
- echo "{" && \
- echo " path=\"\"" && \
- echo " dirs=\`echo \$1 | sed -e 's%/% %g'\`" && \
- echo " mode=\$2" && \
- echo " " && \
- echo " set -- \${dirs}" && \
- echo " " && \
- echo " for d in \${dirs}" && \
- echo " do" && \
- echo " path=\"\${path}/\$d\"" && \
- echo " if test ! -d \"\${path}\" ; then" && \
- echo " mkdir \${path}" && \
- echo " if test \$? -ne 0 ; then" && \
- echo " echo \"Failed to create directory: \${path}\"" && \
- echo " exit 1" && \
- echo " fi" && \
- echo " chmod \${mode} \${path}" && \
- echo " fi" && \
- echo " done" && \
- echo "}" && \
- echo " " && \
- echo "lcopy()" && \
- echo "{" && \
- echo " from=\$1" && \
- echo " to=\$2" && \
- echo " dmode=\$3" && \
- echo " fmode=\$4" && \
- echo " " && \
- echo " test -d \${to} || lmkdir \${to} \${dmode}" && \
- echo " (cd \${from} && tar -cf - *) | (cd \${to} && tar -xf -)" && \
- echo " " && \
- echo " if test \"X\${fmode}\" != X ; then" && \
- echo " find \${to} -type f -print | xargs chmod \${fmode}" && \
- echo " fi" && \
- echo " if test \"X\${dmode}\" != X ; then" && \
- echo " find \${to} -type d -print | xargs chmod \${dmode}" && \
- echo " fi" && \
- echo "}" && \
- echo " " && \
- echo "##" && \
- echo "## determine path to (optional) Perl interpreter" && \
- echo "##" && \
- echo "PERL=no-perl5-on-this-system" && \
- echo "perls='perl5 perl'" && \
- echo "path=\`echo \$PATH | sed -e 's/:/ /g'\`" && \
- echo " " && \
- echo "for dir in \${path} ; do" && \
- echo " for pperl in \${perls} ; do" && \
- echo " if test -f \"\${dir}/\${pperl}\" ; then" && \
- echo " if \`\${dir}/\${pperl} -v | grep 'version 5\.' >/dev/null 2>&1\` ; then" && \
- echo " PERL=\"\${dir}/\${pperl}\"" && \
- echo " break" && \
- echo " fi" && \
- echo " fi" && \
- echo " done" && \
- echo "done" && \
- echo " " && \
- echo "if [ .\$1 = . ]" && \
- echo "then" && \
- echo " SR=/usr/local/apache" && \
- echo "else" && \
- echo " SR=\$1" && \
- echo "fi" && \
- echo "echo \"Installing binary distribution for platform $OS\"" && \
- echo "echo \"into directory \$SR ...\"" && \
- echo "lmkdir \$SR 755" && \
- echo "lmkdir \$SR/proxy 750" && \
- echo "lmkdir \$SR/logs 750" && \
- echo "lcopy bindist/man \$SR/man 755 644" && \
- echo "lcopy bindist/libexec \$SR/libexec 750 644" && \
- echo "lcopy bindist/include \$SR/include 755 644" && \
- echo "lcopy bindist/icons \$SR/icons 755 644" && \
- echo "lcopy bindist/cgi-bin \$SR/cgi-bin 750 750" && \
- echo "lcopy bindist/bin \$SR/bin 750 750" && \
- echo "if [ -d \$SR/conf ]" && \
- echo "then" && \
- echo " echo \"[Preserving existing configuration files.]\"" && \
- echo " cp bindist/conf/*.default \$SR/conf/" && \
- echo "else" && \
- echo " lcopy bindist/conf \$SR/conf 750 640" && \
- echo "fi" && \
- echo "if [ -d \$SR/htdocs ]" && \
- echo "then" && \
- echo " echo \"[Preserving existing htdocs directory.]\"" && \
- echo "else" && \
- echo " lcopy bindist/htdocs \$SR/htdocs 755 644" && \
- echo "fi" && \
- echo " " && \
- echo "sed -e \"s;^#!/.*;#!\$PERL;\" -e \"s;\@prefix\@;\$SR;\" -e \"s;\@sbindir\@;\$SR/bin;\" \\" && \
- echo " -e \"s;\@libexecdir\@;\$SR/libexec;\" -e \"s;\@includedir\@;\$SR/include;\" \\" && \
- echo " -e \"s;\@sysconfdir\@;\$SR/conf;\" bindist/bin/apxs > \$SR/bin/apxs" && \
- echo "sed -e \"s;^#!/.*;#!\$PERL;\" bindist/bin/dbmmanage > \$SR/bin/dbmmanage" && \
- echo "sed -e \"s%/usr/local/apache%\$SR%\" \$SR/conf/httpd.conf.default > \$SR/conf/httpd.conf" && \
- echo "sed -e \"s%PIDFILE=%PIDFILE=\$SR/%\" -e \"s%HTTPD=%HTTPD=\\\"\$SR/%\" -e \"s%httpd\$%httpd -d \$SR -R \$SR/libexec\\\"%\" bindist/bin/apachectl > \$SR/bin/apachectl" && \
- echo " " && \
- echo "echo \"Ready.\"" && \
- echo "echo \" +--------------------------------------------------------+\"" && \
- echo "echo \" | You now have successfully installed the Apache $VER |\"" && \
- echo "echo \" | HTTP server. To verify that Apache actually works |\"" && \
- echo "echo \" | correctly you should first check the (initially |\"" && \
- echo "echo \" | created or preserved) configuration files: |\"" && \
- echo "echo \" | |\"" && \
- echo "echo \" | \$SR/conf/httpd.conf\"" && \
- echo "echo \" | |\"" && \
- echo "echo \" | You should then be able to immediately fire up |\"" && \
- echo "echo \" | Apache the first time by running: |\"" && \
- echo "echo \" | |\"" && \
- echo "echo \" | \$SR/bin/apachectl start \"" &&\
- echo "echo \" | |\"" && \
- echo "echo \" | Thanks for using Apache. The Apache Group |\"" && \
- echo "echo \" | http://www.apache.org/ |\"" && \
- echo "echo \" +--------------------------------------------------------+\"" && \
- echo "echo \" \"" \
-) > install-bindist.sh
-chmod 755 install-bindist.sh
-
-sed -e "s%\"htdocs%\"/usr/local/apache/htdocs%" \
- -e "s%\"icons%\"/usr/local/apache/icons%" \
- -e "s%\"cgi-bin%\"/usr/local/apache/cgi-bin%" \
- -e "s%\"proxy%\"/usr/local/apache/proxy%" \
- -e "s%^ServerAdmin.*%ServerAdmin you@your.address%" \
- -e "s%#ServerName.*%#ServerName localhost%" \
- -e "s%Port 8080%Port 80%" \
- bindist/conf/httpd.conf.default > bindist/conf/httpd.conf
-cp bindist/conf/httpd.conf bindist/conf/httpd.conf.default
-
-echo "Creating distribution archive and readme file..."
-
-if [ ".`grep -i error build.log > /dev/null`" != . ]
-then
- echo "ERROR: Failed to build Apache. See \"build.log\" for details."
- exit 1;
-else
- if [ "x$GTAR" != "x" ]
- then
- $GTAR -zcf ../apache_$VER-$OS.tar.gz -C .. apache_$VER
- else
- if [ "x$TAR" != "x" ]
- then
- $TAR -cf ../apache_$VER-$OS.tar -C .. apache_$VER
- if [ "x$GZIP" != "x" ]
- then
- $GZIP ../apache_$VER-$OS.tar
- fi
- else
- echo "ERROR: Could not find a 'tar' program!"
- echo " Please execute the following commands manually:"
- echo " tar -cf ../apache_$VER-$OS.tar ."
- echo " gzip ../apache_$VER-$OS.tar"
- fi
- fi
-
- if [ -f ../apache_$VER-$OS.tar.gz ] && [ -f ../apache_$VER-$OS.README ]
- then
- echo "Ready."
- echo "You can find the binary archive (apache_$VER-$OS.tar.gz)"
- echo "and the readme file (apache_$VER-$OS.README) in the"
- echo "parent directory."
- exit 0;
- else
- exit 1;
- fi
-fi
BIN  docs/docroot/apache_pb.gif
View
Deleted file not rendered
59 docs/manual/LICENSE
View
@@ -1,59 +0,0 @@
-/* ====================================================================
- * Copyright (c) 1995-1999 The Apache Group. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- *
- * 3. All advertising materials mentioning features or use of this
- * software must display the following acknowledgment:
- * "This product includes software developed by the Apache Group
- * for use in the Apache HTTP server project (http://www.apache.org/)."
- *
- * 4. The names "Apache Server" and "Apache Group" must not be used to
- * endorse or promote products derived from this software without
- * prior written permission. For written permission, please contact
- * apache@apache.org.
- *
- * 5. Products derived from this software may not be called "Apache"
- * nor may "Apache" appear in their names without prior written
- * permission of the Apache Group.
- *
- * 6. Redistributions of any form whatsoever must retain the following
- * acknowledgment:
- * "This product includes software developed by the Apache Group
- * for use in the Apache HTTP server project (http://www.apache.org/)."
- *
- * THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
- * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
- * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
- * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
- * OF THE POSSIBILITY OF SUCH DAMAGE.
- * ====================================================================
- *
- * This software consists of voluntary contributions made by many
- * individuals on behalf of the Apache Group and was originally based
- * on public domain software written at the National Center for
- * Supercomputing Applications, University of Illinois, Urbana-Champaign.
- * For more information on the Apache Group and the Apache HTTP server
- * project, please see <http://www.apache.org/>.
- *
- */
-
-
-
135 docs/manual/bind.html
View
@@ -1,135 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Setting which addresses and ports Apache uses</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Setting which addresses and ports Apache uses</H1>
-
-<HR>
-
-When Apache starts, it connects to some port and address on the
-local machine and waits for incoming requests. By default, it
-listens to all addresses on the machine, and to the port
-as specified by the <TT>Port</TT> directive in the server configuration.
-However, it can be told to listen to more the one port, or to listen
-to only selected addresses, or a combination. This is often combined
-with the Virtual Host feature which determines how Apache
-responds to different IP addresses, hostnames and ports.<P>
-
-There are two directives used to restrict or specify which addresses
-and ports Apache listens to.
-
-<UL>
-<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to
- listening to
- a single address, and can be used to permit multiple Apache servers
- on the same machine listening to different IP addresses.
-<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server
- listen
- to more than one address and/or port.
-</UL>
-
-<H3><A NAME="bindaddress">BindAddress</A></H3>
-<A
- HREF="mod/directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address
- | hostname ]</EM><BR>
-<A
- HREF="mod/directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>BindAddress *</CODE><BR>
-<A
- HREF="mod/directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="mod/directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<P>
-
-Makes the server listen to just the specified address. If the argument
-is *, the server listens to all addresses. The port listened to
-is set with the <TT>Port</TT> directive. Only one BindAddress
-should be used.
-
-<H3><A NAME="listen">Listen</A></H3>
-<A
- HREF="mod/directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> Listen <EM>[ port | IP-address:port ]</EM><BR>
-<A
- HREF="mod/directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>none</CODE><BR>
-<A
- HREF="mod/directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="mod/directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<P>
-
-<TT>Listen</TT> can be used instead of <TT>BindAddress</TT> and
-<TT>Port</TT>. It tells the server to accept incoming requests on the
-specified port or address-and-port combination. If the first format is
-used, with a port number only, the server listens to the given port on
-all interfaces, instead of the port given by the <TT>Port</TT>
-directive. If an IP address is given as well as a port, the server
-will listen on the given port and interface. <P> Multiple Listen
-directives may be used to specify a number of addresses and ports to
-listen to. The server will respond to requests from any of the listed
-addresses and ports.<P>
-
-For example, to make the server accept connections on both port
-80 and port 8000, use:
-<PRE>
- Listen 80
- Listen 8000
-</PRE>
-
-To make the server accept connections on two specified
-interfaces and port numbers, use
-<PRE>
- Listen 192.170.2.1:80
- Listen 192.170.2.5:8000
-</PRE>
-
-<H2>How this works with Virtual Hosts</H2>
-
-BindAddress and Listen do not implement Virtual Hosts. They tell the
-main server what addresses and ports to listen to. If no
-&lt;VirtualHost&gt; directives are used, the server will behave the
-same for all accepted requests. However, &lt;VirtualHost&gt; can be
-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
-&lt;VirtualHost&gt; section should be created for a specified address
-and port to set the behavior of this virtual host. Note that if the
-&lt;VirtualHost&gt; is set for an address and port that the server is
-not listening to, it cannot be accessed.
-
-<H2>See also</H2>
-
-See also the documentation on
-<A HREF="vhosts/index.html">Virtual Hosts</A>,
-<A HREF="mod/core.html#bindaddress">BindAddress directive</A>,
-<A HREF="mod/core.html#port">Port directive</A>,
-<A HREF="dns-caveats.html">DNS Issues</A>
-and
-<A HREF="mod/core.html#virtualhost">&lt;VirtualHost&gt; section</A>.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
-
135 docs/manual/bind.html.en
View
@@ -1,135 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Setting which addresses and ports Apache uses</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Setting which addresses and ports Apache uses</H1>
-
-<HR>
-
-When Apache starts, it connects to some port and address on the
-local machine and waits for incoming requests. By default, it
-listens to all addresses on the machine, and to the port
-as specified by the <TT>Port</TT> directive in the server configuration.
-However, it can be told to listen to more the one port, or to listen
-to only selected addresses, or a combination. This is often combined
-with the Virtual Host feature which determines how Apache
-responds to different IP addresses, hostnames and ports.<P>
-
-There are two directives used to restrict or specify which addresses
-and ports Apache listens to.
-
-<UL>
-<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to
- listening to
- a single address, and can be used to permit multiple Apache servers
- on the same machine listening to different IP addresses.
-<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server
- listen
- to more than one address and/or port.
-</UL>
-
-<H3><A NAME="bindaddress">BindAddress</A></H3>
-<A
- HREF="mod/directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address
- | hostname ]</EM><BR>
-<A
- HREF="mod/directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>BindAddress *</CODE><BR>
-<A
- HREF="mod/directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="mod/directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<P>
-
-Makes the server listen to just the specified address. If the argument
-is *, the server listens to all addresses. The port listened to
-is set with the <TT>Port</TT> directive. Only one BindAddress
-should be used.
-
-<H3><A NAME="listen">Listen</A></H3>
-<A
- HREF="mod/directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> Listen <EM>[ port | IP-address:port ]</EM><BR>
-<A
- HREF="mod/directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>none</CODE><BR>
-<A
- HREF="mod/directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="mod/directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<P>
-
-<TT>Listen</TT> can be used instead of <TT>BindAddress</TT> and
-<TT>Port</TT>. It tells the server to accept incoming requests on the
-specified port or address-and-port combination. If the first format is
-used, with a port number only, the server listens to the given port on
-all interfaces, instead of the port given by the <TT>Port</TT>
-directive. If an IP address is given as well as a port, the server
-will listen on the given port and interface. <P> Multiple Listen
-directives may be used to specify a number of addresses and ports to
-listen to. The server will respond to requests from any of the listed
-addresses and ports.<P>
-
-For example, to make the server accept connections on both port
-80 and port 8000, use:
-<PRE>
- Listen 80
- Listen 8000
-</PRE>
-
-To make the server accept connections on two specified
-interfaces and port numbers, use
-<PRE>
- Listen 192.170.2.1:80
- Listen 192.170.2.5:8000
-</PRE>
-
-<H2>How this works with Virtual Hosts</H2>
-
-BindAddress and Listen do not implement Virtual Hosts. They tell the
-main server what addresses and ports to listen to. If no
-&lt;VirtualHost&gt; directives are used, the server will behave the
-same for all accepted requests. However, &lt;VirtualHost&gt; can be
-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
-&lt;VirtualHost&gt; section should be created for a specified address
-and port to set the behavior of this virtual host. Note that if the
-&lt;VirtualHost&gt; is set for an address and port that the server is
-not listening to, it cannot be accessed.
-
-<H2>See also</H2>
-
-See also the documentation on
-<A HREF="vhosts/index.html">Virtual Hosts</A>,
-<A HREF="mod/core.html#bindaddress">BindAddress directive</A>,
-<A HREF="mod/core.html#port">Port directive</A>,
-<A HREF="dns-caveats.html">DNS Issues</A>
-and
-<A HREF="mod/core.html#virtualhost">&lt;VirtualHost&gt; section</A>.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
-
93 docs/manual/cgi_path.html
View
@@ -1,93 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>PATH_INFO Changes in the CGI Environment</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</H1>
-
-<HR>
-
-<H2><A NAME="over">Overview</A></H2>
-
-<P>As implemented in Apache 1.1.1 and earlier versions, the method
-Apache used to create PATH_INFO in the CGI environment was
-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
-CGI/1.1 specification, and CGI scripts can be easily modified (<A
-HREF="#compat">see below</A>).
-
-<H2><A NAME="prob">The Problem</A></H2>
-
-<P>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME
-environment variables by looking at the filename, not the URL. While
-this resulted in the correct values in many cases, when the filesystem
-path was overloaded to contain path information, it could result in
-errant behavior. For example, if the following appeared in a config
-file:
-<PRE>
- Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph
-</PRE>
-<P>In this case, <CODE>user.cgi</CODE> is the CGI script, the "/ralph"
-is information to be passed onto the CGI. If this configuration was in
-place, and a request came for "<CODE>/cgi-ralph/script/</CODE>", the
-code would set PATH_INFO to "<CODE>/ralph/script</CODE>", and
-SCRIPT_NAME to "<CODE>/cgi-</CODE>". Obviously, the latter is
-incorrect. In certain cases, this could even cause the server to
-crash.</P>
-
-<H2><A NAME="solution">The Solution</A></H2>
-
-<P>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by
-looking directly at the URL, and determining how much of the URL is
-client-modifiable, and setting PATH_INFO to it. To use the above
-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
-guaranteed that
-"<CODE>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</CODE>"
-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>"
-information from the <CODE>Alias</CODE> directive is lost. This is
-unfortunate, but we feel that using the filesystem to pass along this
-sort of information is not a recommended method, and a script making
-use of it "deserves" not to work. Apache 1.2b3 and later, however, do
-provide <A HREF="#compat">a workaround.</A>
-
-<H2><A NAME="compat">Compatibility with Previous Servers</A></H2>
-
-<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
-environment variable contains the value that PATH_INFO would have had
-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 existence of FILEPATH_INFO, and use
-it if available. Otherwise, it can use PATH_INFO. For example, in
-Perl, one might use:
-<PRE>
- $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
-</PRE>
-
-<P>By doing this, a script can work with all servers supporting the
-CGI/1.1 specification, including all versions of Apache.</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
-
93 docs/manual/cgi_path.html.en
View
@@ -1,93 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>PATH_INFO Changes in the CGI Environment</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</H1>
-
-<HR>
-
-<H2><A NAME="over">Overview</A></H2>
-
-<P>As implemented in Apache 1.1.1 and earlier versions, the method
-Apache used to create PATH_INFO in the CGI environment was
-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
-CGI/1.1 specification, and CGI scripts can be easily modified (<A
-HREF="#compat">see below</A>).
-
-<H2><A NAME="prob">The Problem</A></H2>
-
-<P>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME
-environment variables by looking at the filename, not the URL. While
-this resulted in the correct values in many cases, when the filesystem
-path was overloaded to contain path information, it could result in
-errant behavior. For example, if the following appeared in a config
-file:
-<PRE>
- Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph
-</PRE>
-<P>In this case, <CODE>user.cgi</CODE> is the CGI script, the "/ralph"
-is information to be passed onto the CGI. If this configuration was in
-place, and a request came for "<CODE>/cgi-ralph/script/</CODE>", the
-code would set PATH_INFO to "<CODE>/ralph/script</CODE>", and
-SCRIPT_NAME to "<CODE>/cgi-</CODE>". Obviously, the latter is
-incorrect. In certain cases, this could even cause the server to
-crash.</P>
-
-<H2><A NAME="solution">The Solution</A></H2>
-
-<P>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by
-looking directly at the URL, and determining how much of the URL is
-client-modifiable, and setting PATH_INFO to it. To use the above
-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
-guaranteed that
-"<CODE>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</CODE>"
-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>"
-information from the <CODE>Alias</CODE> directive is lost. This is
-unfortunate, but we feel that using the filesystem to pass along this
-sort of information is not a recommended method, and a script making
-use of it "deserves" not to work. Apache 1.2b3 and later, however, do
-provide <A HREF="#compat">a workaround.</A>
-
-<H2><A NAME="compat">Compatibility with Previous Servers</A></H2>
-
-<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
-environment variable contains the value that PATH_INFO would have had
-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 existence of FILEPATH_INFO, and use
-it if available. Otherwise, it can use PATH_INFO. For example, in
-Perl, one might use:
-<PRE>
- $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
-</PRE>
-
-<P>By doing this, a script can work with all servers supporting the
-CGI/1.1 specification, including all versions of Apache.</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
-
588 docs/manual/content-negotiation.html
View
@@ -1,588 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Content Negotiation</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Content Negotiation</H1>
-
-<P>
-Apache's support for content negotiation has been updated to meet 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 encoding. It is also implements a
-couple of features to give more intelligent handling of requests from
-browsers which send incomplete negotiation information. <P>
-
-Content negotiation is provided by the
-<A HREF="mod/mod_negotiation.html">mod_negotiation</A> module,
-which is compiled in by default.
-
-<HR>
-
-<H2>About Content Negotiation</H2>
-
-<P>
-A resource may be available in several different representations. For
-example, it might be available in different languages or different
-media types, or a combination. One way of selecting the most
-appropriate choice is to give the user an index page, and let them
-select. However it is often possible for the server to choose
-automatically. This works because browsers can send as part of each
-request information about what representations they prefer. For
-example, a browser could indicate that it would like to see
-information in French, if possible, else English will do. Browsers
-indicate their preferences by headers in the request. To request only
-French representations, the browser would send
-
-<PRE>
- Accept-Language: fr
-</PRE>
-
-<P>
-Note that this preference will only be applied when there is a choice
-of representations and they vary by language.
-<P>
-
-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 preferring GIF or JPEG over other media types, but also
-allowing any other media type as a last resort:
-
-<PRE>
- Accept-Language: fr; q=1.0, en; q=0.5
- 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
-</PRE>
-
-Apache 1.2 supports 'server driven' content negotiation, as defined in
-the HTTP/1.1 specification. It fully supports the Accept,
-Accept-Language, Accept-Charset and Accept-Encoding request headers.
-Apache 1.3.4 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>
-
-A <STRONG>resource</STRONG> is a conceptual entity identified by a URI
-(RFC 2396). An HTTP server like Apache 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, 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 <STRONG>negotiable</STRONG> and each of its
-representations is termed a <STRONG>variant</STRONG>. The ways in which the
-variants for a negotiable resource vary are called the
-<STRONG>dimensions</STRONG> of negotiation.
-
-<H2>Negotiation in Apache</H2>
-
-<P>
-In order to negotiate a resource, the server needs to be given
-information about each of the variants. This is done in one of two
-ways:
-
-<UL>
- <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which
- names the files containing the variants explicitly, or
- <LI> Using a 'MultiViews' search, where the server does an implicit
- filename pattern match and chooses from among the results.
-</UL>
-
-<H3>Using a type-map file</H3>
-
-<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 mime type
-<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 with a
-
-<PRE>
- AddHandler type-map var
-</PRE>
-
-in the server configuration file. See the comments in the sample config
-file for more details. <P>
-
-Type map files have an entry for each available variant; these entries
-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:
-
-<PRE>
- URI: foo
-
- URI: foo.en.html
- Content-type: text/html
- Content-language: en
-
- URI: foo.fr.de.html
- Content-type: text/html;charset=iso-8859-2
- Content-language: fr, de
-</PRE>
-
-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):
-
-<PRE>
- URI: foo
-
- URI: foo.jpeg
- Content-type: image/jpeg; qs=0.8
-
- URI: foo.gif
- Content-type: image/gif; qs=0.5
-
- URI: foo.txt
- Content-type: text/plain; qs=0.01
-</PRE>
-<P>
-
-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. 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.
-
-<P>
-The full list of headers recognized is:
-
-<DL>
- <DT> <CODE>URI:</CODE>
- <DD> uri of the file containing the variant (of the given media
- type, encoded with the given content encoding). These are
- interpreted as URLs relative to the map file; they must be on
- the same server (!), and they must refer to files to which the
- client would be granted access if they were to be requested
- directly.
- <DT> <CODE>Content-Type:</CODE>
- <DD> media type --- charset, level and "qs" parameters may be given. These
- are often referred to as MIME types; typical media types are
- <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
- language tag from RFC 1766 (<EM>e.g.</EM>, <CODE>en</CODE> for English,
- <CODE>kr</CODE> for Korean, <EM>etc.</EM>).
- <DT> <CODE>Content-Encoding:</CODE>
- <DD> If the file is compressed, or otherwise encoded, rather than
- containing the actual raw data, this says how that was done.
- Apache only recognizes encodings that are defined by an
- <A HREF="mod/mod_mime.html#addencoding">AddEncoding</A> directive.
- This normally includes the encodings <CODE>x-compress</CODE>
- for compress'd files, and <CODE>x-gzip</CODE> for gzip'd files.
- The <CODE>x-</CODE> prefix is ignored for encoding comparisons.
- <DT> <CODE>Content-Length:</CODE>
- <DD> The size of the file. Specifying content
- lengths in the type-map allows the server to compare file sizes
- without checking the actual files.
- <DT> <CODE>Description:</CODE>
- <DD> A human-readable textual description of the variant. If Apache cannot
- find any appropriate variant to return, it will return an error
- response which lists all available variants instead. Such a variant
- list will include the human-readable variant descriptions.
-</DL>
-
-<H3>Multiviews</H3>
-
-<P>
-<CODE>MultiViews</CODE> is a per-directory option, meaning it can be set with
-an <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.
-
-<P>
-The effect of <CODE>MultiViews</CODE> is as follows: if the server
-receives a request for <CODE>/some/dir/foo</CODE>, if
-<CODE>/some/dir</CODE> has <CODE>MultiViews</CODE> enabled, and
-<CODE>/some/dir/foo</CODE> does <EM>not</EM> exist, then the server reads the
-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.
-
-<P>
-<CODE>MultiViews</CODE> may also apply to searches for the file named by the
-<CODE>DirectoryIndex</CODE> directive, if the server is trying to
-index a directory. If the configuration files specify
-
-<PRE>
- DirectoryIndex index
-</PRE>
-
-then the server will arbitrate between <CODE>index.html</CODE>
-and <CODE>index.html3</CODE> if both are present. If neither are
-present, and <CODE>index.cgi</CODE> is there, the server will run it.
-
-<P>
-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
-QUERY_ARGS or PATH_INFO, the script is given an extremely high quality
-rating, and generally invoked; otherwise it is given an extremely low
-quality rating, which generally causes one of the other views (if any)
-to be retrieved.
-
-<H2>The Negotiation Methods</H2>
-
-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
-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 rest of this document explains the
-methods used for those interested.
-<P>
-
-There are two negotiation methods:
-
-<OL>
-
-<LI><STRONG>Server driven negotiation with the Apache
-algorithm</STRONG> is used in the normal case. The Apache algorithm is
-explained in more detail below. When this algorithm is used, Apache
-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 more detail below.
-
-<LI><STRONG>Transparent content negotiation</STRONG> is used when the
-browser specifically requests this through the mechanism defined in RFC
-2295. This negotiation method gives 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 variant selection algorithm' defined in RFC 2296. </UL>
-
-
-<H3>Dimensions of Negotiation</H3>
-
-<TABLE>
-<TR valign="top">
-<TH>Dimension
-<TH>Notes
-<TR valign="top">
-<TD>Media Type
-<TD>Browser indicates preferences with the Accept header field. Each item
-can have an associated quality factor. Variant description can also
-have a quality factor (the "qs" parameter).
-<TR valign="top">
-<TD>Language
-<TD>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.
-<TR valign="top">
-<TD>Encoding
-<TD>Browser indicates preference with the Accept-Encoding header field.
-Each item can have a quality factor.
-<TR valign="top">
-<TD>Charset
-<TD>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.
-</TABLE>
-
-<H3>Apache Negotiation Algorithm</H3>
-
-<P>
-Apache 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:
-
-<OL>
-<LI>First, for each dimension of the negotiation, check the appropriate
-<EM>Accept*</EM> header field and assign a quality to each
-variant. If the <EM>Accept*</EM> header for any dimension implies that this
-variant is not acceptable, eliminate it. If no variants remain, go
-to step 4.
-
-<LI>Select the 'best' variant by a process of elimination. Each of the
-following tests is applied in order. Any variants not selected at each
-test are eliminated. After each test, if only one variant remains,
-select it as the best match and proceed to step 3. If more than one
-variant remains, move on to the next test.
-
-<OL>
-<LI>Multiply the quality factor from the Accept header with the
- quality-of-source factor for this variant's media type, and select
- the variants with the highest value.
-
-<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 in the Accept-Language header (if present), or else
- else the order of languages in the <CODE>LanguagePriority</CODE>
- directive (if present).
-
-<LI>Select the variants with the highest 'level' media parameter
- (used to give the version of text/html media types).
-
-<LI>Select variants with the best charset media parameters,
- as given on the Accept-Charset header line. Charset ISO-8859-1
- is acceptable unless explicitly excluded. Variants with a
- <CODE>text/*</CODE> media type but not explicitly associated
- with a particular charset are assumed to be in ISO-8859-1.
-
-<LI>Select those variants which have associated
- charset media parameters that are <EM>not</EM> ISO-8859-1.
- If there are no such variants, select all variants instead.
-
-<LI>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
- and non-encoded variants, select only the unencoded variants.
- If either all variants are encoded or all variants are not encoded,
- select all variants.
-
-<LI>Select the variants with the smallest content length.
-
-<LI>Select the first variant of those remaining. This will be either the
- first listed in the type-map file, or when variants are read from
- the directory, the one whose file name comes first when sorted using
- ASCII code order.
-
-</OL>
-
-<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 negotiation (browsers and caches can use this
- information when caching the resource). End.
-
-<LI>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
- dimensions of variance.
-
-</OL>
-
-<H2><A NAME="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 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 Accept header information which would
-otherwise result in the selection of the wrong variant in many
-cases. If a browser sends full and correct information these fiddles
-will not be applied.
-<P>
-
-<H3>Media Types and Wildcards</H3>
-
-<P>
-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/" 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 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 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
-as:
-<PRE>
- Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
-</PRE>
-
-The explicit types have no quality factor, so they default to a
-preference of 1.0 (the highest). The wildcard */* is given
-a low preference of 0.01, so other types will only be returned if
-no variant matches an explicitly listed type.
-<P>
-
-If the Accept: header contains <EM>no</EM> q factors at all, Apache 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 Accept: header contains a q factor,
-these special values are <EM>not</EM> applied, so requests from browsers
-which send the correct information to start with work as expected.
-
-<H3>Variants with no Language</H3>
-
-<P>
-If some of the variants for a particular resource have a language
-attribute, and some do not, those variants with no language
-are given a very low language quality factor of 0.001.<P>
-
-The reason for setting this language quality factor for
-variant with no language to a very low value is to allow
-for a default variant which can be supplied if none of the
-other variants match the browser's language preferences.
-
-For example, consider the situation with three variants:
-
-<UL>
-<LI>foo.en.html, language en
-<LI>foo.fr.html, language en
-<LI>foo.html, no language
-</UL>
-
-<P>
-The meaning of a variant with no language is that it is
-always acceptable to the browser. If the request Accept-Language
-header includes either en or fr (or both) one of foo.en.html
-or foo.fr.html will be returned. If the browser does not list
-either en or fr as acceptable, foo.html will be returned instead.
-
-<H2>Extensions to Transparent Content Negotiation</H2>
-
-Apache 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 (RFC 2296) is extended to recognize encoded
-variants in the list, and to use them as candidate variants whenever
-their encodings are acceptable according to the Accept-Encoding
-request header. The RVSA/1.0 implementation does not round computed
-quality factors to 5 decimal places before choosing the best variant.
-
-<H2>Note on hyperlinks and naming conventions</H2>
-
-<P>
-If you are using language negotiation you can choose between
-different naming conventions, because files can have more than one
-extension, and the order of the extensions is normally irrelevant
-(see <A HREF="mod/mod_mime.html">mod_mime</A> documentation for details).
-<P>
-A typical file has a MIME-type extension (<EM>e.g.</EM>, <SAMP>html</SAMP>),
-maybe an encoding extension (<EM>e.g.</EM>, <SAMP>gz</SAMP>), and of course a
-language extension (<EM>e.g.</EM>, <SAMP>en</SAMP>) when we have different
-language variants of this file.
-
-<P>
-Examples:
-<UL>
-<LI>foo.en.html
-<LI>foo.html.en
-<LI>foo.en.html.gz
-</UL>
-
-<P>
-Here some more examples of filenames together with valid and invalid
-hyperlinks:
-</P>
-
-<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0>
-<TR>
- <TH>Filename</TH>
- <TH>Valid hyperlink</TH>
- <TH>Invalid hyperlink</TH>
-</TR>
-<TR>
- <TD><EM>foo.html.en</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>-</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html</EM></TD>
- <TD>foo</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.en.gz</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>foo.gz<BR>
- foo.html.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html.gz</EM></TD>
- <TD>foo</TD>
- <TD>foo.html<BR>
- foo.html.gz<BR>
- foo.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.gz.html.en</EM></TD>
- <TD>foo<BR>
- foo.gz<BR>
- foo.gz.html</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.gz.en</EM></TD>
- <TD>foo<BR>
- foo.html<BR>
- foo.html.gz</TD>
- <TD>foo.gz</TD>
-</TR>
-</TABLE>
-
-<P>
-Looking at the table above you will notice that it is always possible to
-use the name without any extensions in an hyperlink (<EM>e.g.</EM>, <SAMP>foo</SAMP>).
-The advantage is that you can hide the actual type of a
-document rsp. file and can change it later, <EM>e.g.</EM>, from <SAMP>html</SAMP>
-to <SAMP>shtml</SAMP> or <SAMP>cgi</SAMP> without changing any
-hyperlink references.
-
-<P>
-If you want to continue to use a MIME-type in your hyperlinks (<EM>e.g.</EM>
-<SAMP>foo.html</SAMP>) the language extension (including an encoding extension
-if there is one) must be on the right hand side of the MIME-type extension
-(<EM>e.g.</EM>, <SAMP>foo.html.en</SAMP>).
-
-
-<H2>Note on Caching</H2>
-
-<P>
-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
-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. <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
-takes no arguments. It has no effect on requests from HTTP/1.1 clients.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
588 docs/manual/content-negotiation.html.en
View
@@ -1,588 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Content Negotiation</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Content Negotiation</H1>
-
-<P>
-Apache's support for content negotiation has been updated to meet 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 encoding. It is also implements a
-couple of features to give more intelligent handling of requests from
-browsers which send incomplete negotiation information. <P>
-
-Content negotiation is provided by the
-<A HREF="mod/mod_negotiation.html">mod_negotiation</A> module,
-which is compiled in by default.
-
-<HR>
-
-<H2>About Content Negotiation</H2>
-
-<P>
-A resource may be available in several different representations. For
-example, it might be available in different languages or different
-media types, or a combination. One way of selecting the most
-appropriate choice is to give the user an index page, and let them
-select. However it is often possible for the server to choose
-automatically. This works because browsers can send as part of each
-request information about what representations they prefer. For
-example, a browser could indicate that it would like to see
-information in French, if possible, else English will do. Browsers
-indicate their preferences by headers in the request. To request only
-French representations, the browser would send
-
-<PRE>
- Accept-Language: fr
-</PRE>
-
-<P>
-Note that this preference will only be applied when there is a choice
-of representations and they vary by language.
-<P>
-
-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 preferring GIF or JPEG over other media types, but also
-allowing any other media type as a last resort:
-
-<PRE>
- Accept-Language: fr; q=1.0, en; q=0.5
- 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
-</PRE>
-
-Apache 1.2 supports 'server driven' content negotiation, as defined in
-the HTTP/1.1 specification. It fully supports the Accept,
-Accept-Language, Accept-Charset and Accept-Encoding request headers.
-Apache 1.3.4 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>
-
-A <STRONG>resource</STRONG> is a conceptual entity identified by a URI
-(RFC 2396). An HTTP server like Apache 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, 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 <STRONG>negotiable</STRONG> and each of its
-representations is termed a <STRONG>variant</STRONG>. The ways in which the
-variants for a negotiable resource vary are called the
-<STRONG>dimensions</STRONG> of negotiation.
-
-<H2>Negotiation in Apache</H2>
-
-<P>
-In order to negotiate a resource, the server needs to be given
-information about each of the variants. This is done in one of two
-ways:
-
-<UL>
- <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which
- names the files containing the variants explicitly, or
- <LI> Using a 'MultiViews' search, where the server does an implicit
- filename pattern match and chooses from among the results.
-</UL>
-
-<H3>Using a type-map file</H3>
-
-<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 mime type
-<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 with a
-
-<PRE>
- AddHandler type-map var
-</PRE>
-
-in the server configuration file. See the comments in the sample config
-file for more details. <P>
-
-Type map files have an entry for each available variant; these entries
-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:
-
-<PRE>
- URI: foo
-
- URI: foo.en.html
- Content-type: text/html
- Content-language: en
-
- URI: foo.fr.de.html
- Content-type: text/html;charset=iso-8859-2
- Content-language: fr, de
-</PRE>
-
-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):
-
-<PRE>
- URI: foo
-
- URI: foo.jpeg
- Content-type: image/jpeg; qs=0.8
-
- URI: foo.gif
- Content-type: image/gif; qs=0.5
-
- URI: foo.txt
- Content-type: text/plain; qs=0.01
-</PRE>
-<P>
-
-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. 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.
-
-<P>
-The full list of headers recognized is:
-
-<DL>
- <DT> <CODE>URI:</CODE>
- <DD> uri of the file containing the variant (of the given media
- type, encoded with the given content encoding). These are
- interpreted as URLs relative to the map file; they must be on
- the same server (!), and they must refer to files to which the
- client would be granted access if they were to be requested
- directly.
- <DT> <CODE>Content-Type:</CODE>
- <DD> media type --- charset, level and "qs" parameters may be given. These
- are often referred to as MIME types; typical media types are
- <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
- language tag from RFC 1766 (<EM>e.g.</EM>, <CODE>en</CODE> for English,
- <CODE>kr</CODE> for Korean, <EM>etc.</EM>).
- <DT> <CODE>Content-Encoding:</CODE>
- <DD> If the file is compressed, or otherwise encoded, rather than
- containing the actual raw data, this says how that was done.
- Apache only recognizes encodings that are defined by an
- <A HREF="mod/mod_mime.html#addencoding">AddEncoding</A> directive.
- This normally includes the encodings <CODE>x-compress</CODE>
- for compress'd files, and <CODE>x-gzip</CODE> for gzip'd files.
- The <CODE>x-</CODE> prefix is ignored for encoding comparisons.
- <DT> <CODE>Content-Length:</CODE>
- <DD> The size of the file. Specifying content
- lengths in the type-map allows the server to compare file sizes
- without checking the actual files.
- <DT> <CODE>Description:</CODE>
- <DD> A human-readable textual description of the variant. If Apache cannot
- find any appropriate variant to return, it will return an error
- response which lists all available variants instead. Such a variant
- list will include the human-readable variant descriptions.
-</DL>
-
-<H3>Multiviews</H3>
-
-<P>
-<CODE>MultiViews</CODE> is a per-directory option, meaning it can be set with
-an <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.
-
-<P>
-The effect of <CODE>MultiViews</CODE> is as follows: if the server
-receives a request for <CODE>/some/dir/foo</CODE>, if
-<CODE>/some/dir</CODE> has <CODE>MultiViews</CODE> enabled, and
-<CODE>/some/dir/foo</CODE> does <EM>not</EM> exist, then the server reads the
-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.
-
-<P>
-<CODE>MultiViews</CODE> may also apply to searches for the file named by the
-<CODE>DirectoryIndex</CODE> directive, if the server is trying to
-index a directory. If the configuration files specify
-
-<PRE>
- DirectoryIndex index
-</PRE>
-
-then the server will arbitrate between <CODE>index.html</CODE>
-and <CODE>index.html3</CODE> if both are present. If neither are
-present, and <CODE>index.cgi</CODE> is there, the server will run it.
-
-<P>
-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
-QUERY_ARGS or PATH_INFO, the script is given an extremely high quality
-rating, and generally invoked; otherwise it is given an extremely low
-quality rating, which generally causes one of the other views (if any)
-to be retrieved.
-
-<H2>The Negotiation Methods</H2>
-
-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
-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 rest of this document explains the
-methods used for those interested.
-<P>
-
-There are two negotiation methods:
-
-<OL>
-
-<LI><STRONG>Server driven negotiation with the Apache
-algorithm</STRONG> is used in the normal case. The Apache algorithm is
-explained in more detail below. When this algorithm is used, Apache
-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 more detail below.
-
-<LI><STRONG>Transparent content negotiation</STRONG> is used when the
-browser specifically requests this through the mechanism defined in RFC
-2295. This negotiation method gives 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 variant selection algorithm' defined in RFC 2296. </UL>
-
-
-<H3>Dimensions of Negotiation</H3>
-
-<TABLE>
-<TR valign="top">
-<TH>Dimension
-<TH>Notes
-<TR valign="top">
-<TD>Media Type
-<TD>Browser indicates preferences with the Accept header field. Each item
-can have an associated quality factor. Variant description can also
-have a quality factor (the "qs" parameter).
-<TR valign="top">
-<TD>Language
-<TD>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.
-<TR valign="top">
-<TD>Encoding
-<TD>Browser indicates preference with the Accept-Encoding header field.
-Each item can have a quality factor.
-<TR valign="top">
-<TD>Charset
-<TD>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.
-</TABLE>
-
-<H3>Apache Negotiation Algorithm</H3>
-
-<P>
-Apache 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:
-
-<OL>
-<LI>First, for each dimension of the negotiation, check the appropriate
-<EM>Accept*</EM> header field and assign a quality to each
-variant. If the <EM>Accept*</EM> header for any dimension implies that this
-variant is not acceptable, eliminate it. If no variants remain, go
-to step 4.
-
-<LI>Select the 'best' variant by a process of elimination. Each of the
-following tests is applied in order. Any variants not selected at each
-test are eliminated. After each test, if only one variant remains,
-select it as the best match and proceed to step 3. If more than one
-variant remains, move on to the next test.
-
-<OL>
-<LI>Multiply the quality factor from the Accept header with the
- quality-of-source factor for this variant's media type, and select
- the variants with the highest value.
-
-<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 in the Accept-Language header (if present), or else
- else the order of languages in the <CODE>LanguagePriority</CODE>
- directive (if present).
-
-<LI>Select the variants with the highest 'level' media parameter
- (used to give the version of text/html media types).
-
-<LI>Select variants with the best charset media parameters,
- as given on the Accept-Charset header line. Charset ISO-8859-1
- is acceptable unless explicitly excluded. Variants with a
- <CODE>text/*</CODE> media type but not explicitly associated
- with a particular charset are assumed to be in ISO-8859-1.
-
-<LI>Select those variants which have associated
- charset media parameters that are <EM>not</EM> ISO-8859-1.
- If there are no such variants, select all variants instead.
-
-<LI>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
- and non-encoded variants, select only the unencoded variants.
- If either all variants are encoded or all variants are not encoded,
- select all variants.
-
-<LI>Select the variants with the smallest content length.
-
-<LI>Select the first variant of those remaining. This will be either the
- first listed in the type-map file, or when variants are read from
- the directory, the one whose file name comes first when sorted using
- ASCII code order.
-
-</OL>
-
-<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 negotiation (browsers and caches can use this
- information when caching the resource). End.
-
-<LI>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
- dimensions of variance.
-
-</OL>
-
-<H2><A NAME="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 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 Accept header information which would
-otherwise result in the selection of the wrong variant in many
-cases. If a browser sends full and correct information these fiddles
-will not be applied.
-<P>
-
-<H3>Media Types and Wildcards</H3>
-
-<P>
-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/" 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 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 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
-as:
-<PRE>
- Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
-</PRE>
-
-The explicit types have no quality factor, so they default to a
-preference of 1.0 (the highest). The wildcard */* is given
-a low preference of 0.01, so other types will only be returned if
-no variant matches an explicitly listed type.
-<P>
-
-If the Accept: header contains <EM>no</EM> q factors at all, Apache 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 Accept: header contains a q factor,
-these special values are <EM>not</EM> applied, so requests from browsers
-which send the correct information to start with work as expected.
-
-<H3>Variants with no Language</H3>
-
-<P>
-If some of the variants for a particular resource have a language
-attribute, and some do not, those variants with no language
-are given a very low language quality factor of 0.001.<P>
-
-The reason for setting this language quality factor for
-variant with no language to a very low value is to allow
-for a default variant which can be supplied if none of the
-other variants match the browser's language preferences.
-
-For example, consider the situation with three variants:
-
-<UL>
-<LI>foo.en.html, language en
-<LI>foo.fr.html, language en
-<LI>foo.html, no language
-</UL>
-
-<P>
-The meaning of a variant with no language is that it is
-always acceptable to the browser. If the request Accept-Language
-header includes either en or fr (or both) one of foo.en.html
-or foo.fr.html will be returned. If the browser does not list
-either en or fr as acceptable, foo.html will be returned instead.
-
-<H2>Extensions to Transparent Content Negotiation</H2>
-
-Apache 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 (RFC 2296) is extended to recognize encoded
-variants in the list, and to use them as candidate variants whenever
-their encodings are acceptable according to the Accept-Encoding
-request header. The RVSA/1.0 implementation does not round computed
-quality factors to 5 decimal places before choosing the best variant.
-
-<H2>Note on hyperlinks and naming conventions</H2>
-
-<P>
-If you are using language negotiation you can choose between
-different naming conventions, because files can have more than one
-extension, and the order of the extensions is normally irrelevant
-(see <A HREF="mod/mod_mime.html">mod_mime</A> documentation for details).
-<P>
-A typical file has a MIME-type extension (<EM>e.g.</EM>, <SAMP>html</SAMP>),
-maybe an encoding extension (<EM>e.g.</EM>, <SAMP>gz</SAMP>), and of course a
-language extension (<EM>e.g.</EM>, <SAMP>en</SAMP>) when we have different
-language variants of this file.
-
-<P>
-Examples:
-<UL>
-<LI>foo.en.html
-<LI>foo.html.en
-<LI>foo.en.html.gz
-</UL>
-
-<P>
-Here some more examples of filenames together with valid and invalid
-hyperlinks:
-</P>
-
-<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0>
-<TR>
- <TH>Filename</TH>
- <TH>Valid hyperlink</TH>
- <TH>Invalid hyperlink</TH>
-</TR>
-<TR>
- <TD><EM>foo.html.en</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>-</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html</EM></TD>
- <TD>foo</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.en.gz</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>foo.gz<BR>
- foo.html.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html.gz</EM></TD>
- <TD>foo</TD>
- <TD>foo.html<BR>
- foo.html.gz<BR>
- foo.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.gz.html.en</EM></TD>
- <TD>foo<BR>
- foo.gz<BR>
- foo.gz.html</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.gz.en</EM></TD>
- <TD>foo<BR>
- foo.html<BR>
- foo.html.gz</TD>
- <TD>foo.gz</TD>
-</TR>
-</TABLE>
-
-<P>
-Looking at the table above you will notice that it is always possible to
-use the name without any extensions in an hyperlink (<EM>e.g.</EM>, <SAMP>foo</SAMP>).
-The advantage is that you can hide the actual type of a
-document rsp. file and can change it later, <EM>e.g.</EM>, from <SAMP>html</SAMP>
-to <SAMP>shtml</SAMP> or <SAMP>cgi</SAMP> without changing any
-hyperlink references.
-
-<P>
-If you want to continue to use a MIME-type in your hyperlinks (<EM>e.g.</EM>
-<SAMP>foo.html</SAMP>) the language extension (including an encoding extension
-if there is one) must be on the right hand side of the MIME-type extension
-(<EM>e.g.</EM>, <SAMP>foo.html.en</SAMP>).
-
-
-<H2>Note on Caching</H2>
-
-<P>
-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
-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. <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
-takes no arguments. It has no effect on requests from HTTP/1.1 clients.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
177 docs/manual/custom-error.html
View
@@ -1,177 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Custom error responses</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Custom error responses</H1>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Additional functionality. Allows webmasters to configure the response of
- Apache to some error or problem.
-
- <P>Customizable responses can be defined to be activated in the
- event of a server detected error or problem.
-
- <P>e.g. if a script crashes and produces a "500 Server Error"
- response, then this response can be replaced with either some
- friendlier text or by a redirection to another URL (local or
- external).
- <P>
-
-<DT>Old behavior
-
- <DD>NCSA httpd 1.3 would return some boring old error/problem message
- which would often be meaningless to the user, and would provide no
- means of logging the symptoms which caused it.<BR>
-
- <P>
-
-<DT>New behavior
-
- <DD>The server can be asked to;
- <OL>
- <LI>Display some other text, instead of the NCSA hard coded messages, or
- <LI>redirect to a local URL, or
- <LI>redirect to an external URL.
- </OL>
-
- <P>Redirecting to another URL can be useful, but only if some information
- can be passed which can then be used to explain and/or log the
- error/problem
- more clearly.
-
- <P>To achieve this, Apache will define new CGI-like environment
- variables, <EM>e.g.</EM>
-
- <BLOCKQUOTE><CODE>
-REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
-REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712) <BR>
-REDIRECT_PATH=.:/bin:/usr/local/bin:/etc <BR>
-REDIRECT_QUERY_STRING= <BR>
-REDIRECT_REMOTE_ADDR=121.345.78.123 <BR>
-REDIRECT_REMOTE_HOST=ooh.ahhh.com <BR>
-REDIRECT_SERVER_NAME=crash.bang.edu <BR>
-REDIRECT_SERVER_PORT=80 <BR>
-REDIRECT_SERVER_SOFTWARE=Apache/0.8.15 <BR>
-REDIRECT_URL=/cgi-bin/buggy.pl <BR>
- </CODE></BLOCKQUOTE>
-
- <P>note the <CODE>REDIRECT_</CODE> prefix.
-
- <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE>
- will
- be passed to the new URL (assuming it's a cgi-script or a cgi-include).
- The
- other variables will exist only if they existed prior to the
- error/problem.
- <STRONG>None</STRONG> of these will be set if your ErrorDocument is an
- <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a
- scheme name
- like <CODE>http:</CODE>, even if it refers to the same host as the
- server).<P>
-
-<DT>Configuration
-
- <DD> Use of "ErrorDocument" is enabled for .htaccess files when the
- <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is
- allowed.
-
- <P>Here are some examples...
-
- <BLOCKQUOTE><CODE>
-ErrorDocument 500 /cgi-bin/crash-recover <BR>
-ErrorDocument 500 "Sorry, our script crashed. Oh dear<BR>
-ErrorDocument 500 http://xxx/ <BR>
-ErrorDocument 404 /Lame_excuses/not_found.html <BR>
-ErrorDocument 401 /Subscription/how_to_subscribe.html
- </CODE></BLOCKQUOTE>
-
- <P>The syntax is,
-
- <P><CODE><A HREF="mod/core.html#errordocument">ErrorDocument</A></CODE>
-&lt;3-digit-code&gt; action
-
- <P>where the action can be,
-
- <OL>
- <LI>Text to be displayed. Prefix the text with a quote (&quot;). Whatever
- follows the quote is displayed. <EM>Note: the (&quot;) prefix isn't
- displayed.</EM>
-
- <LI>An external URL to redirect to.
-
- <LI>A local URL to redirect to.
-
- </OL>
-</DL>
-
-<P><HR><P>
-
-<H2>Custom error responses and redirects</H2>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Apache's behavior to redirected URLs has been modified so that additional
- environment variables are available to a script/server-include.<P>
-
-<DT>Old behavior
-
- <DD>Standard CGI vars were made available to a script which has been
- redirected to. No indication of where the redirection came from was
- provided.
-
- <P>
-
-<DT>New behavior
- <DD>
-
-A new batch of environment variables will be initialized for use by a
-script which has been redirected to. Each new variable will have the
-prefix <CODE>REDIRECT_</CODE>. <CODE>REDIRECT_</CODE> environment
-variables are created from the CGI environment variables which existed
-prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>
-prefix, <EM>i.e.</EM>, <CODE>HTTP_USER_AGENT</CODE> becomes
-<CODE>REDIRECT_HTTP_USER_AGENT</CODE>. In addition to these new
-variables, Apache will define <CODE>REDIRECT_URL</CODE> and
-<CODE>REDIRECT_STATUS</CODE> to help the script trace its origin.
-Both the original URL and the URL being redirected to can be logged in
-the access log.
-
-</DL>
-<P>
-If the ErrorDocument specifies a local redirect to a CGI script, the script
-should include a "<SAMP>Status:</SAMP>" header field in its output
-in order to ensure the propagation all the way back to the client
-of the error condition that caused it to be invoked. For instance, a Perl
-ErrorDocument script might include the following:
-</P>
-<PRE>
- :
- print "Content-type: text/html\n";
- printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
- :
-</PRE>
-<P>
-If the script is dedicated to handling a particular error condition, such as
-<SAMP>404&nbsp;Not&nbsp;Found</SAMP>, it can use the specific code and
-error text instead.
-</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
177 docs/manual/custom-error.html.en
View
@@ -1,177 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Custom error responses</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Custom error responses</H1>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Additional functionality. Allows webmasters to configure the response of
- Apache to some error or problem.
-
- <P>Customizable responses can be defined to be activated in the
- event of a server detected error or problem.
-
- <P>e.g. if a script crashes and produces a "500 Server Error"
- response, then this response can be replaced with either some
- friendlier text or by a redirection to another URL (local or
- external).
- <P>
-
-<DT>Old behavior
-
- <DD>NCSA httpd 1.3 would return some boring old error/problem message
- which would often be meaningless to the user, and would provide no
- means of logging the symptoms which caused it.<BR>
-
- <P>
-
-<DT>New behavior
-
- <DD>The server can be asked to;
- <OL>
- <LI>Display some other text, instead of the NCSA hard coded messages, or
- <LI>redirect to a local URL, or
- <LI>redirect to an external URL.
- </OL>
-
- <P>Redirecting to another URL can be useful, but only if some information
- can be passed which can then be used to explain and/or log the
- error/problem
- more clearly.
-
- <P>To achieve this, Apache will define new CGI-like environment
- variables, <EM>e.g.</EM>
-
- <BLOCKQUOTE><CODE>
-REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
-REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712) <BR>
-REDIRECT_PATH=.:/bin:/usr/local/bin:/etc <BR>
-REDIRECT_QUERY_STRING= <BR>
-REDIRECT_REMOTE_ADDR=121.345.78.123 <BR>
-REDIRECT_REMOTE_HOST=ooh.ahhh.com <BR>
-REDIRECT_SERVER_NAME=crash.bang.edu <BR>
-REDIRECT_SERVER_PORT=80 <BR>
-REDIRECT_SERVER_SOFTWARE=Apache/0.8.15 <BR>
-REDIRECT_URL=/cgi-bin/buggy.pl <BR>
- </CODE></BLOCKQUOTE>
-
- <P>note the <CODE>REDIRECT_</CODE> prefix.
-
- <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE>
- will
- be passed to the new URL (assuming it's a cgi-script or a cgi-include).
- The
- other variables will exist only if they existed prior to the
- error/problem.
- <STRONG>None</STRONG> of these will be set if your ErrorDocument is an
- <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a
- scheme name
- like <CODE>http:</CODE>, even if it refers to the same host as the
- server).<P>
-
-<DT>Configuration
-
- <DD> Use of "ErrorDocument" is enabled for .htaccess files when the
- <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is
- allowed.
-
- <P>Here are some examples...
-
- <BLOCKQUOTE><CODE>
-ErrorDocument 500 /cgi-bin/crash-recover <BR>
-ErrorDocument 500 "Sorry, our script crashed. Oh dear<BR>
-ErrorDocument 500 http://xxx/ <BR>
-ErrorDocument 404 /Lame_excuses/not_found.html <BR>
-ErrorDocument 401 /Subscription/how_to_subscribe.html
- </CODE></BLOCKQUOTE>
-
- <P>The syntax is,
-
- <P><CODE><A HREF="mod/core.html#errordocument">ErrorDocument</A></CODE>
-&lt;3-digit-code&gt; action
-
- <P>where the action can be,
-
- <OL>
- <LI>Text to be displayed. Prefix the text with a quote (&quot;). Whatever
- follows the quote is displayed. <EM>Note: the (&quot;) prefix isn't
- displayed.</EM>
-
- <LI>An external URL to redirect to.
-
- <LI>A local URL to redirect to.
-
- </OL>
-</DL>
-
-<P><HR><P>
-
-<H2>Custom error responses and redirects</H2>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Apache's behavior to redirected URLs has been modified so that additional
- environment variables are available to a script/server-include.<P>
-
-<DT>Old behavior
-
- <DD>Standard CGI vars were made available to a script which has been
- redirected to. No indication of where the redirection came from was
- provided.
-
- <P>
-
-<DT>New behavior
- <DD>
-
-A new batch of environment variables will be initialized for use by a
-script which has been redirected to. Each new variable will have the
-prefix <CODE>REDIRECT_</CODE>. <CODE>REDIRECT_</CODE> environment
-variables are created from the CGI environment variables which existed
-prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>
-prefix, <EM>i.e.</EM>, <CODE>HTTP_USER_AGENT</CODE> becomes
-<CODE>REDIRECT_HTTP_USER_AGENT</CODE>. In addition to these new
-variables, Apache will define <CODE>REDIRECT_URL</CODE> and
-<CODE>REDIRECT_STATUS</CODE> to help the script trace its origin.
-Both the original URL and the URL being redirected to can be logged in
-the access log.
-
-</DL>
-<P>
-If the ErrorDocument specifies a local redirect to a CGI script, the script
-should include a "<SAMP>Status:</SAMP>" header field in its output
-in order to ensure the propagation all the way back to the client
-of the error condition that caused it to be invoked. For instance, a Perl
-ErrorDocument script might include the following:
-</P>
-<PRE>
- :
- print "Content-type: text/html\n";
- printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
- :
-</PRE>
-<P>
-If the script is dedicated to handling a particular error condition, such as
-<SAMP>404&nbsp;Not&nbsp;Found</SAMP>, it can use the specific code and
-error text instead.
-</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
1,153 docs/manual/developer/API.html
View
@@ -1,1153 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Apache API notes</TITLE>
-</HEAD>
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache API notes</H1>
-
-These are some notes on the Apache API and the data structures you
-have to deal with, <EM>etc.</EM> They are not yet nearly complete, but
-hopefully, they will help you get your bearings. Keep in mind that
-the API is still subject to change as we gain experience with it.
-(See the TODO file for what <EM>might</EM> be coming). However,
-it will be easy to adapt modules to any changes that are made.
-(We have more modules to adapt than you do).
-<P>
-
-A few notes on general pedagogical style here. In the interest of
-conciseness, all structure declarations here are incomplete --- the
-real ones have more slots that I'm not telling you about. For the
-most part, these are reserved to one component of the server core or
-another, and should be altered by modules with caution. However, in
-some cases, they really are things I just haven't gotten around to
-yet. Welcome to the bleeding edge.<P>
-
-Finally, here's an outline, to give you some bare idea of what's
-coming up, and in what order:
-
-<UL>
-<LI> <A HREF="#basics">Basic concepts.</A>
-<MENU>
- <LI> <A HREF="#HMR">Handlers, Modules, and Requests</A>
- <LI> <A HREF="#moduletour">A brief tour of a module</A>
-</MENU>
-<LI> <A HREF="#handlers">How handlers work</A>
-<MENU>
- <LI> <A HREF="#req_tour">A brief tour of the <CODE>request_rec</CODE></A>
- <LI> <A HREF="#req_orig">Where request_rec structures come from</A>
- <LI> <A HREF="#req_return">Handling requests, declining, and returning error
- codes</A>
- <LI> <A HREF="#resp_handlers">Special considerations for response handlers</A>
- <LI> <A HREF="#auth_handlers">Special considerations for authentication
- handlers</A>
- <LI> <A HREF="#log_handlers">Special considerations for logging handlers</A>
-</MENU>
-<LI> <A HREF="#pools">Resource allocation and resource pools</A>
-<LI> <A HREF="#config">Configuration, commands and the like</A>
-<MENU>
- <LI> <A HREF="#per-dir">Per-directory configuration structures</A>
- <LI> <A HREF="#commands">Command handling</A>
- <LI> <A HREF="#servconf">Side notes --- per-server configuration,
- virtual servers, <EM>etc</EM>.</A>
-</MENU>
-</UL>
-
-<H2><A NAME="basics">Basic concepts.</A></H2>
-
-We begin with an overview of the basic concepts behind the
-API, and how they are manifested in the code.
-
-<H3><A NAME="HMR">Handlers, Modules, and Requests</A></H3>
-
-Apache breaks down request handling into a series of steps, more or
-less the same way the Netscape server API does (although this API has
-a few more stages than NetSite does, as hooks for stuff I thought
-might be useful in the future). These are:
-
-<UL>
- <LI> URI -&gt; Filename translation
- <LI> Auth ID checking [is the user who they say they are?]
- <LI> Auth access checking [is the user authorized <EM>here</EM>?]
- <LI> Access checking other than auth
- <LI> Determining MIME type of the object requested
- <LI> `Fixups' --- there aren't any of these yet, but the phase is
- intended as a hook for possible extensions like
- <CODE>SetEnv</CODE>, which don't really fit well elsewhere.
- <LI> Actually sending a response back to the client.
- <LI> Logging the request
-</UL>
-
-These phases are handled by looking at each of a succession of
-<EM>modules</EM>, looking to see if each of them has a handler for the
-phase, and attempting invoking it if so. The handler can typically do
-one of three things:
-
-<UL>
- <LI> <EM>Handle</EM> the request, and indicate that it has done so
- by returning the magic constant <CODE>OK</CODE>.
- <LI> <EM>Decline</EM> to handle the request, by returning the magic
- integer constant <CODE>DECLINED</CODE>. In this case, the
- server behaves in all respects as if the handler simply hadn't
- been there.
- <LI> Signal an error, by returning one of the HTTP error codes.
- This terminates normal handling of the request, although an
- ErrorDocument may be invoked to try to mop up, and it will be
- logged in any case.
-</UL>
-
-Most phases are terminated by the first module that handles them;
-however, for logging, `fixups', and non-access authentication
-checking, all handlers always run (barring an error). Also, the
-response phase is unique in that modules may declare multiple handlers
-for it, via a dispatch table keyed on the MIME type of the requested
-object. Modules may declare a response-phase handler which can handle
-<EM>any</EM> request, by giving it the key <CODE>*/*</CODE> (<EM>i.e.</EM>, a
-wildcard MIME type specification). However, wildcard handlers are
-only invoked if the server has already tried and failed to find a more
-specific response handler for the MIME type of the requested object
-(either none existed, or they all declined).<P>
-
-The handlers themselves are functions of one argument (a
-<CODE>request_rec</CODE> structure. vide infra), which returns an
-integer, as above.<P>
-
-<H3><A NAME="moduletour">A brief tour of a module</A></H3>
-
-At this point, we need to explain the structure of a module. Our
-candidate will be one of the messier ones, the CGI module --- this
-handles both CGI scripts and the <CODE>ScriptAlias</CODE> config file
-command. It's actually a great deal more complicated than most
-modules, but if we're going to have only one example, it might as well
-be the one with its fingers in every place.<P>
-
-Let's begin with handlers. In order to handle the CGI scripts, the
-module declares a response handler for them. Because of
-<CODE>ScriptAlias</CODE>, it also has handlers for the name
-translation phase (to recognize <CODE>ScriptAlias</CODE>ed URIs), the
-type-checking phase (any <CODE>ScriptAlias</CODE>ed request is typed
-as a CGI script).<P>
-
-The module needs to maintain some per (virtual)
-server information, namely, the <CODE>ScriptAlias</CODE>es in effect;
-the module structure therefore contains pointers to a functions which
-builds these structures, and to another which combines two of them (in
-case the main server and a virtual server both have
-<CODE>ScriptAlias</CODE>es declared).<P>
-
-Finally, this module contains code to handle the
-<CODE>ScriptAlias</CODE> command itself. This particular module only
-declares one command, but there could be more, so modules have