ways:
<UL>
- <LI> Using a type map (i.e., a <CODE>*.var</CODE> file) which
+ <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which
names the files containing the variants explicitly
<LI> Or using a 'MultiViews' search, where the server does an implicit
filename pattern match, and chooses from among the results.
<CODE>text/html; level=3</CODE>.
<DT> <CODE>Content-language:</CODE>
<DD> The languages of the variant, specified as an Internet standard
- language code (e.g., <CODE>en</CODE> for English,
- <CODE>kr</CODE> for Korean, etc.).
+ language code (<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.
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, e.g. from <SAMP>html</SAMP>
+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 (e.g.
+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>).
ways:
<UL>
- <LI> Using a type map (i.e., a <CODE>*.var</CODE> file) which
+ <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which
names the files containing the variants explicitly
<LI> Or using a 'MultiViews' search, where the server does an implicit
filename pattern match, and chooses from among the results.
<CODE>text/html; level=3</CODE>.
<DT> <CODE>Content-language:</CODE>
<DD> The languages of the variant, specified as an Internet standard
- language code (e.g., <CODE>en</CODE> for English,
- <CODE>kr</CODE> for Korean, etc.).
+ language code (<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.
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, e.g. from <SAMP>html</SAMP>
+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 (e.g.
+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>).
more clearly.
<P>To achieve this, Apache will define new CGI-like environment
- variables, e.g.
+ variables, <EM>e.g.</EM>
<BLOCKQUOTE><CODE>
REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
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, i.e. <CODE>HTTP_USER_AGENT</CODE> becomes
+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.
more clearly.
<P>To achieve this, Apache will define new CGI-like environment
- variables, e.g.
+ variables, <EM>e.g.</EM>
<BLOCKQUOTE><CODE>
REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
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, i.e. <CODE>HTTP_USER_AGENT</CODE> becomes
+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.
<H1 ALIGN="CENTER">Apache API notes</H1>
These are some notes on the Apache API and the data structures you
-have to deal with, etc. They are not yet nearly complete, but
+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,
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> (i.e., a
+<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
A final note on the declared types of the arguments of some of these
commands: a <CODE>pool</CODE> is a pointer to a <EM>resource pool</EM>
structure; these are used by the server to keep track of the memory
-which has been allocated, files opened, etc., either to service a
+which has been allocated, files opened, <EM>etc.</EM>, either to service a
particular request, or to handle the process of configuring itself.
That way, when the request is over (or, for the configuration pool,
when the server is restarting), the memory can be freed, and the files
int header_only; /* HEAD request, as opposed to GET */
char *protocol; /* Protocol, as given to us, or HTTP/0.9 */
- char *method; /* GET, HEAD, POST, etc. */
- int method_number; /* M_GET, M_POST, etc. */
+ char *method; /* GET, HEAD, POST, <EM>etc.</EM> */
+ int method_number; /* M_GET, M_POST, <EM>etc.</EM> */
/* Info for logging */
* (the thing pointed to being the module's business).
*/
- void *per_dir_config; /* Options set in config files, etc. */
+ void *per_dir_config; /* Options set in config files, <EM>etc.</EM> */
void *request_config; /* Notes on *this* request */
};
a few exceptions:
<UL>
- <LI> If the request is to an imagemap, a type map (i.e., a
+ <LI> If the request is to an imagemap, a type map (<EM>i.e.</EM>, a
<CODE>*.var</CODE> file), or a CGI script which returned a
local `Location:', then the resource which the user requested
is going to be ultimately located by some URI other than what
<P>
One of the problems of writing and designing a server-pool server is
that of preventing leakage, that is, allocating resources (memory,
-open files, etc.), without subsequently releasing them. The resource
+open files, <EM>etc.</EM>), without subsequently releasing them. The resource
pool machinery is designed to make it easy to prevent this from
happening, by allowing resource to be allocated in such a way that
they are <EM>automatically</EM> released when the server is done with
</P>
<P>
The way this works is as follows: the memory which is allocated, file
-opened, etc., to deal with a particular request are tied to a
+opened, <EM>etc.</EM>, to deal with a particular request are tied to a
<EM>resource pool</EM> which is allocated for the request. The pool
is a data structure which itself tracks the resources in question.
</P>
Pool cleanups live until clear_pool() is called: clear_pool(a) recursively
calls destroy_pool() on all subpools of a; then calls all the cleanups for a;
then releases all the memory for a. destroy_pool(a) calls clear_pool(a)
-and then releases the pool structure itself. i.e. clear_pool(a) doesn't
+and then releases the pool structure itself. <EM>i.e.</EM>, clear_pool(a) doesn't
delete a, it just frees up all the resources and you can start using it
again immediately.
</P>
As a note --- if there is no per-directory merge function present, the
server will just use the subdirectory's configuration info, and ignore
-the parent's. For some modules, that works just fine (e.g., for the
+the parent's. For some modules, that works just fine (<EM>e.g.</EM>, for the
includes module, whose per-directory configuration information
consists solely of the state of the <CODE>XBITHACK</CODE>), and for
those modules, you can just not declare one, and leave the
{ "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
"a mime type followed by a file extension" },
{ "AddEncoding", add_encoding, NULL, OR_FILEINFO, TAKE2,
- "an encoding (e.g., gzip), followed by a file extension" },
+ "an encoding (<EM>e.g.</EM>, gzip), followed by a file extension" },
{ NULL }
};
</PRE>
<P>Finally, to take advantage of the DSO's API the executable program has to
resolve particular symbols from the DSO via <CODE>dlsym()</CODE> for later use
-inside dispatch tables etc. In other words: The executable program has to
+inside dispatch tables <EM>etc.</EM> In other words: The executable program has to
manually resolve every symbol it needs to be able to use it. The advantage of
such a mechanism is that optional program parts need not be loaded (and thus
do not spend memory) until they are needed by the program in question. When
<P>As of 1998 there are only a few software packages available which use the
DSO mechanism to actually extend their functionality at run-time: Perl 5 (via
-its XS mechanism and the DynaLoader module), Netscape Server, etc. Starting
+its XS mechanism and the DynaLoader module), Netscape Server, <EM>etc.</EM> Starting
with version 1.3, Apache joined the crew, because Apache already uses a module
concept to extend its functionality and internally uses a dispatch-list-based
approach to link external modules into the Apache core functionality. So,
<CODE>Configuration</CODE> <CODE>AddModule</CODE> commands at build-time.
For instance this way one is able to run different server instances
(standard & SSL version, minimalistic & powered up version
- [mod_perl, PHP3], etc.) with only one Apache installation.
+ [mod_perl, PHP3], <EM>etc.</EM>) with only one Apache installation.
<P>
<LI> The server package can be easily extended with third-party modules even
after installation. This is at least a great benefit for vendor package
maintainers who can create a Apache core package and additional packages
- containing extensions like PHP3, mod_perl, mod_fastcgi, etc.
+ containing extensions like PHP3, mod_perl, mod_fastcgi, <EM>etc.</EM>
<P>
<LI> Easier Apache module prototyping because with the DSO/<CODE>apxs</CODE>
pair you can both work outside the Apache source tree and only need an
<P>Finally, to take advantage of the DSO's API the executable program has to
resolve particular symbols from the DSO via <CODE>dlsym()</CODE> for later use
-inside dispatch tables etc. In other words: The executable program has to
+inside dispatch tables <EM>etc.</EM> In other words: The executable program has to
manually resolve every symbol it needs to be able to use it. The advantage of
such a mechanism is that optional program parts need not be loaded (and thus
do not spend memory) until they are needed by the program in question. When
<P>As of 1998 there are only a few software packages available which use the
DSO mechanism to actually extend their functionality at run-time: Perl 5 (via
-its XS mechanism and the DynaLoader module), Netscape Server, etc. Starting
+its XS mechanism and the DynaLoader module), Netscape Server, <EM>etc.</EM> Starting
with version 1.3, Apache joined the crew, because Apache already uses a module
concept to extend its functionality and internally uses a dispatch-list-based
approach to link external modules into the Apache core functionality. So,
<CODE>Configuration</CODE> <CODE>AddModule</CODE> commands at build-time.
For instance this way one is able to run different server instances
(standard & SSL version, minimalistic & powered up version
- [mod_perl, PHP3], etc.) with only one Apache installation.
+ [mod_perl, PHP3], <EM>etc.</EM>) with only one Apache installation.
<P>
<LI> The server package can be easily extended with third-party modules even
after installation. This is at least a great benefit for vendor package
maintainers who can create a Apache core package and additional packages
- containing extensions like PHP3, mod_perl, mod_fastcgi, etc.
+ containing extensions like PHP3, mod_perl, mod_fastcgi, <EM>etc.</EM>
<P>
<LI> Easier Apache module prototyping because with the DSO/<CODE>apxs</CODE>
pair you can both work outside the Apache source tree and only need an
includes character translations, differences in
contiguity of the two character sets, flags which
indicate which part of the HTTP protocol has to be
- converted and which part doesn't etc.
+ converted and which part doesn't <EM>etc.</EM>
<DT><CODE><STRONG>#ifdef _OSD_POSIX</STRONG></CODE>
<DD>Code which is needed for the BS2000 SIEMENS NIXDORF
mainframe platform only. This deals with include file
mixture of protocol related strings and non-protocol related
raw file data. HTTP protocol strings are always encoded in
ASCII (the GET request, any Header: lines, the chunking
- information etc.) whereas the file transfer parts (i.e., GIF
- images, CGI output etc.) should usually be just "passed through"
+ information <EM>etc.</EM>) whereas the file transfer parts (<EM>i.e.</EM>, GIF
+ images, CGI output <EM>etc.</EM>) should usually be just "passed through"
by the server. This separation between "protocol string" and
"raw data" is reflected in the server code by functions like
bgets() or rvputs() for strings, and functions like bwrite()
</LI><BR>
<LI>
- For Text documents (MIME types text/plain, text/html etc.),
+ For Text documents (MIME types text/plain, text/html <EM>etc.</EM>),
an implicit translation to ASCII can be used, or (if the
users prefer to store some documents in raw ASCII form for
faster serving, or because the files reside on a NFS-mounted
<LI>
Non-text documents are always served "binary" without conversion.
- This seems to be the most sensible choice for, .e.g., GIF/ZIP/AU
+ This seems to be the most sensible choice for, .<EM>e.g.</EM>, GIF/ZIP/AU
file types. This of course requires the user to copy them to the
mainframe host using the "rcp -b" binary switch.
</LI><BR>
<LI>
- Server parsed files are always assumed to be in native (i.e.,
+ Server parsed files are always assumed to be in native (<EM>i.e.</EM>,
EBCDIC) format as used on the machine, and are converted after
processing.
</LI><BR>
<H3 ALIGN=CENTER>Text Documents</H3>
<P>
The default assumption of the server is that Text Files
- (i.e., all files whose <SAMP>Content-Type:</SAMP> starts with
+ (<EM>i.e.</EM>, all files whose <SAMP>Content-Type:</SAMP> starts with
<SAMP>text/</SAMP>) are stored in the native character
set of the host, EBCDIC.
</P>
<P>
First edit <CODE>httpd.conf</CODE>. This sets up general attributes
-about the server: the port number, the user it runs as, etc. Next
+about the server: the port number, the user it runs as, <EM>etc.</EM> Next
edit the <CODE>srm.conf</CODE> file; this sets up the root of the
document tree, special functions like server-parsed HTML or internal
-imagemap parsing, etc. Finally, edit the <CODE>access.conf</CODE>
+imagemap parsing, <EM>etc.</EM> Finally, edit the <CODE>access.conf</CODE>
file to at least set the base cases of access.
<P>
<P>
First edit <CODE>httpd.conf</CODE>. This sets up general attributes
-about the server: the port number, the user it runs as, etc. Next
+about the server: the port number, the user it runs as, <EM>etc.</EM> Next
edit the <CODE>srm.conf</CODE> file; this sets up the root of the
document tree, special functions like server-parsed HTML or internal
-imagemap parsing, etc. Finally, edit the <CODE>access.conf</CODE>
+imagemap parsing, <EM>etc.</EM> Finally, edit the <CODE>access.conf</CODE>
file to at least set the base cases of access.
<P>
shows a breakdown of the vhost settings).
<DT><CODE>-t</CODE>
-<DD>Test the configuration file syntax (i.e., read all configuration files
+<DD>Test the configuration file syntax (<EM>i.e.</EM>, read all configuration files
and interpret them) but do not start the server. If the configuration contains
errors, display an error message and exit with a non-zero exit status,
otherwise display "Syntax OK" and terminate with a zero exit status.
shows a breakdown of the vhost settings).
<DT><CODE>-t</CODE>
-<DD>Test the configuration file syntax (i.e., read all configuration files
+<DD>Test the configuration file syntax (<EM>i.e.</EM>, read all configuration files
and interpret them) but do not start the server. If the configuration contains
errors, display an error message and exit with a non-zero exit status,
otherwise display "Syntax OK" and terminate with a zero exit status.
<H1 ALIGN="CENTER">Apache API notes</H1>
These are some notes on the Apache API and the data structures you
-have to deal with, etc. They are not yet nearly complete, but
+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,
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> (i.e., a
+<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
A final note on the declared types of the arguments of some of these
commands: a <CODE>pool</CODE> is a pointer to a <EM>resource pool</EM>
structure; these are used by the server to keep track of the memory
-which has been allocated, files opened, etc., either to service a
+which has been allocated, files opened, <EM>etc.</EM>, either to service a
particular request, or to handle the process of configuring itself.
That way, when the request is over (or, for the configuration pool,
when the server is restarting), the memory can be freed, and the files
int header_only; /* HEAD request, as opposed to GET */
char *protocol; /* Protocol, as given to us, or HTTP/0.9 */
- char *method; /* GET, HEAD, POST, etc. */
- int method_number; /* M_GET, M_POST, etc. */
+ char *method; /* GET, HEAD, POST, <EM>etc.</EM> */
+ int method_number; /* M_GET, M_POST, <EM>etc.</EM> */
/* Info for logging */
* (the thing pointed to being the module's business).
*/
- void *per_dir_config; /* Options set in config files, etc. */
+ void *per_dir_config; /* Options set in config files, <EM>etc.</EM> */
void *request_config; /* Notes on *this* request */
};
a few exceptions:
<UL>
- <LI> If the request is to an imagemap, a type map (i.e., a
+ <LI> If the request is to an imagemap, a type map (<EM>i.e.</EM>, a
<CODE>*.var</CODE> file), or a CGI script which returned a
local `Location:', then the resource which the user requested
is going to be ultimately located by some URI other than what
<P>
One of the problems of writing and designing a server-pool server is
that of preventing leakage, that is, allocating resources (memory,
-open files, etc.), without subsequently releasing them. The resource
+open files, <EM>etc.</EM>), without subsequently releasing them. The resource
pool machinery is designed to make it easy to prevent this from
happening, by allowing resource to be allocated in such a way that
they are <EM>automatically</EM> released when the server is done with
</P>
<P>
The way this works is as follows: the memory which is allocated, file
-opened, etc., to deal with a particular request are tied to a
+opened, <EM>etc.</EM>, to deal with a particular request are tied to a
<EM>resource pool</EM> which is allocated for the request. The pool
is a data structure which itself tracks the resources in question.
</P>
Pool cleanups live until clear_pool() is called: clear_pool(a) recursively
calls destroy_pool() on all subpools of a; then calls all the cleanups for a;
then releases all the memory for a. destroy_pool(a) calls clear_pool(a)
-and then releases the pool structure itself. i.e. clear_pool(a) doesn't
+and then releases the pool structure itself. <EM>i.e.</EM>, clear_pool(a) doesn't
delete a, it just frees up all the resources and you can start using it
again immediately.
</P>
As a note --- if there is no per-directory merge function present, the
server will just use the subdirectory's configuration info, and ignore
-the parent's. For some modules, that works just fine (e.g., for the
+the parent's. For some modules, that works just fine (<EM>e.g.</EM>, for the
includes module, whose per-directory configuration information
consists solely of the state of the <CODE>XBITHACK</CODE>), and for
those modules, you can just not declare one, and leave the
{ "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
"a mime type followed by a file extension" },
{ "AddEncoding", add_encoding, NULL, OR_FILEINFO, TAKE2,
- "an encoding (e.g., gzip), followed by a file extension" },
+ "an encoding (<EM>e.g.</EM>, gzip), followed by a file extension" },
{ NULL }
};
</PRE>
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
<P>
- $Revision: 1.128 $ ($Date: 1998/09/17 12:33:01 $)
+ $Revision: 1.129 $ ($Date: 1998/09/17 14:14:52 $)
</P>
<P>
The latest version of this FAQ is always available from the main
<P>
If the rule starts with <SAMP>/somedir/...</SAMP> make sure that really no
<SAMP>/somedir</SAMP> exists on the filesystem if you don't want to lead the
- URL to match this directory, i.e. there must be no root directory named
+ URL to match this directory, <EM>i.e.</EM>, there must be no root directory named
<SAMP>somedir</SAMP> on the filesystem. Because if there is such a
directory, the URL will not get prefixed with DocumentRoot. This behaviour
looks ugly, but is really important for some other aspects of URL
There is only one ugly solution: You have to surround the complete flag
argument by quotation marks (<SAMP>"[E=...]"</SAMP>). Notice: The argument
to quote here is not the argument to the E-flag, it is the argument of the
- Apache config file parser, i.e. the third argument of the RewriteRule here.
+ Apache config file parser, <EM>i.e.</EM>, the third argument of the RewriteRule here.
So you have to write <SAMP>"[E=any text with whitespaces]"</SAMP>.
</P>
<HR>
<LI>Apache does not allow ServerRoot settings inside a VirtualHost
container. There is only one global ServerRoot in Apache; any desired
changes in paths for virtual hosts need to be made with the explicit
- directives, eg. DocumentRoot, TransferLog, etc.
+ directives, eg. DocumentRoot, TransferLog, <EM>etc.</EM>
</OL>
ALT="[Needs graphics capability to display]"><BR>
All links in the document as well as links to the server's administrator
mail address, and even the name and port of the serving virtual host
-are inserted in the error document at "run-time", i.e., when the error
+are inserted in the error document at "run-time", <EM>i.e.</EM>, when the error
actually occurs.
</P>
based on the language suffixes and the client's preferences.
Any error situation with an error code <EM>not</EM> handled by a
custom document will be dealt with by the server in the standard way
- (i.e., a plain error message in english).
+ (<EM>i.e.</EM>, a plain error message in english).
<LI>Finally, the <A HREF="../mod/core.html#allowoverride">AllowOverride</A>
directive tells apache that it is not necessary to look for
a .htaccess file in the /errordocs directory: a minor speed
representation first.
<P>
So, in this situation it appears to be easier to define a fallback language
-(by copying or linking, e.g., the english version to a language-less version).
+(by copying or linking, <EM>e.g.</EM>, the english version to a language-less version).
Because the negotiation algorithm prefers "more specialized" variants over
"more generic" variants, these generic alternatives will only be chosen
when the normal negotiation did not succeed.
socket(s) to see if they have been closed by the server, and close their
side of the connection if the server has closed. This check need only
occur once every few seconds, and may even be detected by a OS signal
-on some systems (e.g., Win95 and NT clients have this capability, but
+on some systems (<EM>e.g.</EM>, Win95 and NT clients have this capability, but
they seem to be ignoring it).<P>
Apache <STRONG>cannot</STRONG> avoid these FIN_WAIT_2 states unless it
is a function called <CODE>lingering_close()</CODE> which was added
between 1.1 and 1.2. This function is necessary for the proper
handling of persistent connections and any request which includes
-content in the message body (e.g., PUTs and POSTs).
+content in the message body (<EM>e.g.</EM>, PUTs and POSTs).
What it does is read any data sent by the client for
a certain time after the server closes the connection. The exact
reasons for doing this are somewhat complicated, but involve what
<P>By using a <STRONG>cgi-script</STRONG> you can intercept various requests
and
-treat them specially, e.g. you might want to intercept <STRONG>POST</STRONG>
+treat them specially, <EM>e.g.</EM>, you might want to intercept <STRONG>POST</STRONG>
requests, so that the client isn't redirected to a script on the other
server which expects POST information (a redirect will lose the POST
information.) You might also want to use a CGI script if you don't
<P>The correct procedure is to move the logfile, then signal Apache to tell
it to reopen the logfiles.</P>
-<P>Apache is signaled using the <STRONG>SIGHUP</STRONG> (-1) signal. e.g.
+<P>Apache is signaled using the <STRONG>SIGHUP</STRONG> (-1) signal. <EM>e.g.</EM>
<BLOCKQUOTE><CODE>
mv access_log access_log.old<BR>
kill -1 `cat httpd.pid`
deliberate or accidental.<P>
All the CGI scripts will run as the same user, so they have potential to
-conflict (accidentally or deliberately) with other scripts e.g.
+conflict (accidentally or deliberately) with other scripts <EM>e.g.</EM>
User A hates User B, so he writes a script to trash User B's CGI
database. One program which can be used to allow scripts to run
as different users is <A HREF="../suexec.html">suEXEC</A> which is
<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A>,
<A HREF="#authname">AuthName</A>, <A HREF="#authtype">AuthType</A>,
<A HREF="mod_auth.html#authuserfile">AuthUserFile</A>,
-<A HREF="#require">require</A>, etc.).
+<A HREF="#require">require</A>, <EM>etc.</EM>).
<DT>FileInfo
<DD>
<!--%plaintext <?INDEX {\tt FileInfo} override> -->
<A HREF="mod_mime.html#addtype">AddType</A>,
<A HREF="#defaulttype">DefaultType</A>,
<A HREF="#errordocument">ErrorDocument</A>,
-<A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>, etc.).
+<A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>, <EM>etc.</EM>).
<DT>Indexes
<DD>
<!--%plaintext <?INDEX {\tt Indexes} override> -->
<A HREF="mod_autoindex.html#headername">HeaderName</A>,
<A HREF="mod_autoindex.html#indexignore">IndexIgnore</A>,
<A HREF="mod_autoindex.html#indexoptions">IndexOptions</A>,
-<A HREF="mod_autoindex.html#readmename">ReadmeName</A>, etc.).
+<A HREF="mod_autoindex.html#readmename">ReadmeName</A>, <EM>etc.</EM>).
<DT>Limit
<DD>
<!--%plaintext <?INDEX {\tt Limit} override> -->
</TABLE>
<P>When a particular level is specified, messages from all other levels
-of higher significance will be reported as well. E.g., when
+of higher significance will be reported as well. <EM>E.g.</EM>, when
<CODE>LogLevel info</CODE> is specified, then messages with log levels of
<CODE>notice</CODE> and <CODE>warn</CODE> will also be posted.
<P>
<A HREF="../vhosts/index.html">name-based virtual hosts</A>.<P>
Although <EM>addr</EM> can be hostname it is recommended that you always use
-an IP address, e.g.
+an IP address, <EM>e.g.</EM>
<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44</CODE></BLOCKQUOTE>
for that address).<P>
Optionally you can specify a port number on which the name-based
-virtual hosts should be used, e.g.
+virtual hosts should be used, <EM>e.g.</EM>
<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44:8080</CODE></BLOCKQUOTE>
(See also <A HREF="#usecanonicalname">UseCanonicalName</A>.)<P>
Port 80 is one of Unix's special ports. All ports numbered
-below 1024 are reserved for system use, i.e. regular (non-root) users cannot
+below 1024 are reserved for system use, <EM>i.e.</EM>, regular (non-root) users cannot
make use of them; instead they can only use higher port numbers.
To use port 80, you must start the server from the root account.
After binding to the port and before accepting requests, Apache will change
The ServerAdmin sets the e-mail address that the server includes in any
error messages it returns to the client.<P>
-It may be worth setting up a dedicated address for this, e.g.
+It may be worth setting up a dedicated address for this, <EM>e.g.</EM>
<BLOCKQUOTE><CODE>ServerAdmin www-admin@foo.bar.com</CODE></BLOCKQUOTE>
as users do not always mention that they are talking about the server!<P><HR>
<DL>
<DT><CODE>ServerTokens Min[imal]</CODE>
</DT>
- <DD>Server sends (e.g.): <SAMP>Server: Apache/1.3.0</SAMP>
+ <DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0</SAMP>
</DD>
<DT><CODE>ServerTokens OS</CODE>
</DT>
- <DD>Server sends (e.g.): <SAMP>Server: Apache/1.3.0 (Unix)</SAMP>
+ <DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0 (Unix)</SAMP>
</DD>
<DT><CODE>ServerTokens Full</CODE> (or not specified)
</DT>
- <DD>Server sends (e.g.): <SAMP>Server: Apache/1.3.0 (Unix) PHP/3.0
+ <DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0 (Unix) PHP/3.0
MyMod/1.2</SAMP>
</DD>
</DL>
Examples:
</P>
<PRE>
- Script GET /cgi-bin/search #e.g. for <ISINDEX>-style searching
+ Script GET /cgi-bin/search #<EM>e.g.</EM> for <ISINDEX>-style searching
Script PUT /~bob/put.cgi
</PRE>
script.
<H2>Usage</H2>
In the server configuration file, define a new mime type called
-<CODE>httpd/send-as-is</CODE> e.g.
+<CODE>httpd/send-as-is</CODE> <EM>e.g.</EM>
<BLOCKQUOTE><CODE>AddType httpd/send-as-is asis</CODE></BLOCKQUOTE>
this defines the <CODE>.asis</CODE> file extension as being of the new
<CODE>httpd/send-as-is</CODE> mime type. The contents of any file with a
<H2>Summary</H2>
-It does access control in a manner similar to anonymous-ftp sites; i.e.
+It does access control in a manner similar to anonymous-ftp sites; <EM>i.e.</EM>
have a 'magic' user id 'anonymous' and the email address as a password.
These email addresses can be logged.
<P>
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> AddAltByType <EM>string MIME-type MIME-type...</EM><BR>
+><STRONG>Syntax:</STRONG></A> AddAltByType <EM>string MIME-type MIME-type
+ ...</EM><BR>
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> AddIconByEncoding <EM>icon MIME-encoding MIME-encoding
-...</EM><BR>
+><STRONG>Syntax:</STRONG></A> AddIconByEncoding <EM>icon MIME-encoding
+ MIME-encoding ...</EM><BR>
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> AddIconByType <EM>icon MIME-type MIME-type ...</EM><BR>
+><STRONG>Syntax:</STRONG></A> AddIconByType <EM>icon MIME-type MIME-type
+ ...</EM><BR>
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<!--#include virtual="footer.html" -->
</BODY>
</HTML>
-
<P>This module implements the <A
HREF="http://www.microsoft.com/win32dev/apiext/isapimrg.htm">ISAPI
- Extension</A> API. It allows Internet Server Applications (i.e., ISAPI
+ Extension</A> API. It allows Internet Server Applications (<EM>i.e.</EM>, ISAPI
Extensions) to be used with Apache for Windows.
<H2>Usage</H2>
Be careful with the <EM>filename</EM> arguments: They have to literally
match the filesystem path Apache's URL-to-filename translation handlers
create. We cannot compare inodes or other stuff to match paths through
- symbolic links etc. because that again would cost extra <CODE>stat()</CODE>
+ symbolic links <EM>etc.</EM> because that again would cost extra <CODE>stat()</CODE>
system calls which is not acceptable. This module may or may not work
with filenames rewritten by <CODE>mod_alias</CODE> or
<CODE>mod_rewrite</CODE>... it is an experiment after all.
</DL>
As a degenerate case, a <EM>SubNet</EM> with 32 valid bits is the
equivalent to an <EM>IPAddr</EM>, while a <EM>SubNet</EM> with zero
- valid bits (e.g., 0.0.0.0/0) is the same as the constant
+ valid bits (<EM>e.g.</EM>, 0.0.0.0/0) is the same as the constant
<EM>_Default_</EM>, matching any IP address.
<!-- ===================== IPAddr ======================= -->
Sets the name of the directory to contain cache files; this must be
writable by the httpd server.
-(see the <A HREF="core.html#user"><CODE>User</CODE></A> directive</A>).<BR>
+(see the <A HREF="core.html#user"><CODE>User</CODE></A> directive).<BR>
Setting <CODE>CacheRoot</CODE> enables proxy cacheing; without defining
a <CODE>CacheRoot</CODE>, proxy functionality will be available
if <CODE>ProxyRequests</CODE> are set to <CODE>On</CODE>, but no
then the API intends for it.
<P>
<LI>Unbelievably mod_rewrite provides URL manipulations in per-directory
- context, i.e. within <CODE>.htaccess</CODE> files, although these are
+ context, <EM>i.e.</EM>, within <CODE>.htaccess</CODE> files, although
+ these are
reached a very long time after the URLs were translated to filenames (this
has to be this way, because <CODE>.htaccess</CODE> files stay in the
filesystem, so processing has already been reached this stage of
if conditions exists, it starts an inner loop for processing them in order
they are listed. For conditions the logic is different: We don't match a
pattern against the current URL. Instead we first create a string
-<EM>TestString</EM> by expanding variables, back-references, map lookups, etc.
+<EM>TestString</EM> by expanding variables, back-references, map lookups, <EM>etc.</EM>
and then we try to match <EM>TestPattern</EM> against it. If the pattern
doesn't match, the complete set of conditions and the corresponding rule fails.
If the pattern matches, then the next condition is processed until no more
<A
HREF="directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> <CODE>RewriteEngine</CODE> {<CODE>on,off</CODE>}<BR>
+><STRONG>Syntax:</STRONG></A>
+ <CODE>RewriteEngine</CODE> {<CODE>on,off</CODE>}<BR>
<A
HREF="directive-dict.html#Default"
REL="Help"
-><STRONG>Default:</STRONG></A> <STRONG><CODE>RewriteEngine off</CODE></STRONG><BR>
+><STRONG>Default:</STRONG></A>
+ <STRONG><CODE>RewriteEngine off</CODE></STRONG><BR>
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A>
+ server config, virtual host, directory, .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
<P>
<TABLE WIDTH="70%" BORDER=0 BGCOLOR="#E0E0F0" CELLSPACING=0 CELLPADDING=10>
<TR><TD>
-<STRONG>Notice</STRONG>: To disable the logging of rewriting actions it is not recommended
-to set <EM>Filename</EM>
+<STRONG>Notice</STRONG>: To disable the logging of rewriting actions it is
+not recommended to set <EM>Filename</EM>
to <CODE>/dev/null</CODE>, because although the rewriting engine does
not create output to a logfile it still creates the logfile
-output internally. <STRONG>This will slow down the server with no advantage to the
-administrator!</STRONG>
+output internally. <STRONG>This will slow down the server with no advantage
+to the administrator!</STRONG>
To disable logging either remove or comment out the
<CODE>RewriteLog</CODE> directive or use <CODE>RewriteLogLevel 0</CODE>!
</TD></TR>
<A
HREF="directive-dict.html#Default"
REL="Help"
-><STRONG>Default:</STRONG></A> <STRONG><CODE>RewriteLogLevel 0</CODE></STRONG><BR>
+><STRONG>Default:</STRONG></A> <STRONG><CODE>RewriteLogLevel 0</CODE></STRONG>
+<BR>
<A
HREF="directive-dict.html#Context"
REL="Help"
><STRONG>Compatibility:</STRONG></A> Apache 1.2<BR>
<P>
-The <CODE>RewriteLogLevel</CODE> directive set the verbosity level of the rewriting
+The <CODE>RewriteLogLevel</CODE> directive set the verbosity level of the
+rewriting
logfile. The default level 0 means no logging, while 9 or more means
that practically all actions are logged.
<P>
<TABLE WIDTH="70%" BORDER=0 BGCOLOR="#E0E0F0" CELLSPACING=0 CELLPADDING=10>
<TR><TD>
-<STRONG>Notice:</STRONG> Using a high value for <EM>Level</EM> will slow down your Apache
+<STRONG>Notice:</STRONG> Using a high value for <EM>Level</EM> will slow down
+your Apache
server dramatically! Use the rewriting logfile only for debugging or at least
at <EM>Level</EM> not greater than 2!
</TD></TR>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> <CODE>RewriteMap</CODE> <EM>MapName</EM> <EM>MapType</EM><CODE>:</CODE><EM>MapSource</EM><BR>
+><STRONG>Syntax:</STRONG></A> <CODE>RewriteMap</CODE> <EM>MapName </EM>
+ <EM>MapType</EM><CODE>:</CODE><EM>MapSource</EM><BR>
<A
HREF="directive-dict.html#Default"
REL="Help"
<UL>
<LI><STRONG>Standard Plain Text</STRONG><BR>
- MapType: <CODE>txt</CODE>, MapSource: Unix filesystem path to valid regular file
+ MapType: <CODE>txt</CODE>, MapSource: Unix filesystem path to valid regular
+ file
<P>
This is the standard rewriting map feature where the <EM>MapSource</EM> is
a plain ASCII file containing either blank lines, comment lines (starting
<P>
<LI><STRONG>Randomized Plain Text</STRONG><BR>
- MapType: <CODE>rnd</CODE>, MapSource: Unix filesystem path to valid regular file
+ MapType: <CODE>rnd</CODE>, MapSource: Unix filesystem path to valid regular
+ file
<P>
- This is identical to the Standard Plain Text variant above but with a special
+ This is identical to the Standard Plain Text variant above but with a
+ special
post-processing feature: After looking up a value it is parsed according
- to contained ``<CODE>|</CODE>'' characters which have the meaning of ``or''. Or
+ to contained ``<CODE>|</CODE>'' characters which have the meaning of
+ ``or''. Or
in other words: they indicate a set of alternatives from which the actual
- returned value is chosen randomly. Although this sounds crazy and useless, it
+ returned value is chosen randomly. Although this sounds crazy and useless,
+ it
was actually designed for load balancing in a reverse proxy situation where
the looked up values are server names.
Example:
<P>
<LI><STRONG>Hash File</STRONG><BR>
- MapType: <CODE>dbm</CODE>, MapSource: Unix filesystem path to valid regular file
+ MapType: <CODE>dbm</CODE>, MapSource: Unix filesystem path to valid
+ regular file
<P>
Here the source is a binary NDBM format file containing the same contents
as a <EM>Plain Text</EM> format file, but in a special representation
</UL>
<P>
<LI><STRONG>External Rewriting Program</STRONG><BR>
- MapType: <CODE>prg</CODE>, MapSource: Unix filesystem path to valid regular file
+ MapType: <CODE>prg</CODE>, MapSource: Unix filesystem path to valid
+ regular file
<P>
Here the source is a Unix program, not a map file. To create it you can use
the language of your choice, but the result has to be a run-able Unix
executable (<EM>i.e.</EM>, either object-code or a script with the
- magic cookie trick '<CODE>#!/path/to/interpreter</CODE>' as the first line).
+ magic cookie trick '<CODE>#!/path/to/interpreter</CODE>' as the first
+ line).
<P>
This program gets started once at startup of the Apache servers and then
communicates with the rewriting engine over its <CODE>stdin</CODE> and
<CODE>stdout</CODE> file-handles. For each map-function lookup it will
receive the key to lookup as a newline-terminated string on
<CODE>stdin</CODE>. It then has to give back the looked-up value as a
- newline-terminated string on <CODE>stdout</CODE> or the four-character string
- ``<CODE>NULL</CODE>'' if it fails (<EM>i.e.</EM>, there is no corresponding value
+ newline-terminated string on <CODE>stdout</CODE> or the four-character
+ string ``<CODE>NULL</CODE>'' if it fails (<EM>i.e.</EM>, there is no
+ corresponding value
for the given key). A trivial program which will implement a 1:1 map
(<EM>i.e.</EM>, key == value) could be:
<P>
if this program hangs it will lead to a hang of the Apache server
when the rule occurs.
<LI>Avoid one common mistake: never do buffered I/O on <CODE>stdout</CODE>!
- This will cause a deadloop! Hence the ``<CODE>$|=1</CODE>'' in the above
- example...
+ This will cause a deadloop! Hence the ``<CODE>$|=1</CODE>'' in the
+ above example...
<LI>Use the <SAMP>RewriteLock</SAMP> directive to define a lockfile
mod_rewrite can use to synchronize the communication to the program.
Per default no such synchronization takes place.
The <CODE>RewriteMap</CODE> directive can occur more than once. For each
mapping-function use one <CODE>RewriteMap</CODE> directive to declare its
-rewriting mapfile. While you cannot <STRONG>declare</STRONG> a map in per-directory
-context it is of course possible to <STRONG>use</STRONG> this map in per-directory
-context.
+rewriting mapfile. While you cannot <STRONG>declare</STRONG> a map in
+per-directory context it is of course possible to <STRONG>use</STRONG>
+this map in per-directory context.
<P>
<TABLE WIDTH="70%" BORDER=0 BGCOLOR="#E0E0F0" CELLSPACING=0 CELLPADDING=10>
<TR><TD>
-<STRONG>Notice:</STRONG> For plain text and DBM format files the looked-up keys are cached in-core
+<STRONG>Notice:</STRONG> For plain text and DBM format files the looked-up
+keys are cached in-core
until the <CODE>mtime</CODE> of the mapfile changes or the server does a
restart. This way you can have map-functions in rules which are used
-for <STRONG>every</STRONG> request. This is no problem, because the external lookup
-only happens once!
+for <STRONG>every</STRONG> request. This is no problem, because the
+external lookup only happens once!
</TD></TR>
</TABLE>
<A
HREF="directive-dict.html#Default"
REL="Help"
-><STRONG>Default:</STRONG></A> <EM>default is the physical directory path</EM><BR>
+><STRONG>Default:</STRONG></A> <EM>default is the physical directory path</EM>
+<BR>
<A
HREF="directive-dict.html#Context"
REL="Help"
The <CODE>RewriteBase</CODE> directive explicitly sets the base URL for
per-directory rewrites. As you will see below, <CODE>RewriteRule</CODE> can be
used in per-directory config files (<CODE>.htaccess</CODE>). There it will act
-locally, i.e. the local directory prefix is stripped at this stage of
+locally, <EM>i.e.</EM>, the local directory prefix is stripped at this stage of
processing and your rewriting rules act only on the remainder. At the end
it is automatically added.
<P>
<TABLE WIDTH="70%" BORDER=0 BGCOLOR="#E0E0F0" CELLSPACING=0 CELLPADDING=10>
<TR><TD>
-<STRONG>Notice:</STRONG> If your webserver's URLs are <STRONG>not</STRONG> directly
-related to physical file paths, you have to use <CODE>RewriteBase</CODE> in every
+<STRONG>Notice:</STRONG> If your webserver's URLs are <STRONG>not</STRONG>
+directly related to physical file paths, you have to use
+<CODE>RewriteBase</CODE> in every
<CODE>.htaccess</CODE> files where you want to use <CODE>RewriteRule</CODE>
directives.
</TD></TR>
<TR><TD><PRE>
#
# /abc/def/.htaccess -- per-dir config file for directory /abc/def
-# Remember: /abc/def is the physical path of /xyz, i.e. the server
-# has a 'Alias /xyz /abc/def' directive e.g.
+# Remember: /abc/def is the physical path of /xyz, <EM>i.e.</EM>, the server
+# has a 'Alias /xyz /abc/def' directive <EM>e.g.</EM>
#
RewriteEngine On
</TABLE>
<P>
-In the above example, a request to <CODE>/xyz/oldstuff.html</CODE> gets correctly
+In the above example, a request to <CODE>/xyz/oldstuff.html</CODE>
+gets correctly
rewritten to the physical file <CODE>/abc/def/newstuff.html</CODE>.
<P>
/xyz/oldstuff.html
Internal Processing:
- /xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias)
- /abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule)
- /abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase)
- /xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias)
+ /xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias)
+ /abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule)
+ /abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase)
+ /xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias)
Result:
/abc/def/newstuff.html
<A
HREF="directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> <CODE>RewriteCond</CODE> <EM>TestString</EM> <EM>CondPattern</EM><BR>
+><STRONG>Syntax:</STRONG></A> <CODE>RewriteCond</CODE> <EM>TestString</EM>
+ <EM>CondPattern</EM><BR>
<A
HREF="directive-dict.html#Default"
REL="Help"
<A
HREF="directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="directive-dict.html#Override"
REL="Help"
directives.
The following rewriting rule is only used if its pattern matches the current
-state of the URI <STRONG>and</STRONG> if these additional conditions apply, too.
+state of the URI <STRONG>and</STRONG> if these additional conditions apply
+too.
<P>
<EM>TestString</EM> is a string which can contains the following
expanded constructs in addition to plain text:
<UL>
-<LI><STRONG>RewriteRule backreferences</STRONG>: These are backreferences of the form
+<LI><STRONG>RewriteRule backreferences</STRONG>: These are backreferences of
+ the form
<BLOCKQUOTE><STRONG>
<CODE>$N</CODE>
<CODE>%N</CODE>
</STRONG></BLOCKQUOTE>
-(1 <= N <= 9) which provide access to the grouped parts (parenthesis!) of the
-pattern from the last matched <CODE>RewriteCond</CODE> directive in the current
-bunch of conditions.
+(1 <= N <= 9) which provide access to the grouped parts (parenthesis!) of
+the pattern from the last matched <CODE>RewriteCond</CODE> directive in the
+current bunch of conditions.
<P>
<LI><STRONG>Server-Variables</STRONG>: These are variables
<OL>
<LI>The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same
-value, i.e. the value of the <CODE>filename</CODE> field of the internal
-<CODE>request_rec</CODE> structure of the Apache server. The first name is just the
+value, <EM>i.e.</EM>, the value of the <CODE>filename</CODE> field of
+the internal
+<CODE>request_rec</CODE> structure of the Apache server. The first name is
+just the
commonly known CGI variable name while the second is the consistent
counterpart to REQUEST_URI (which contains the value of the <CODE>uri</CODE>
field of <CODE>request_rec</CODE>).
<P>
<LI>There is the special format: <CODE>%{ENV:variable}</CODE> where
<EM>variable</EM> can be any environment variable. This is looked-up via
-internal Apache structures and (if not found there) via <CODE>getenv()</CODE> from
-the Apache server process.
+internal Apache structures and (if not found there) via <CODE>getenv()</CODE>
+from the Apache server process.
<P>
<LI>There is the special format: <CODE>%{HTTP:header}</CODE> where
</OL>
<P>
-<EM>CondPattern</EM> is the condition pattern, i.e. a regular expression
-which gets applied to the current instance of the <EM>TestString</EM>, i.e.
-<EM>TestString</EM> gets evaluated and then matched against
+<EM>CondPattern</EM> is the condition pattern, <EM>i.e.</EM>, a regular
+expression
+which gets applied to the current instance of the <EM>TestString</EM>,
+<EM>i.e.</EM>, <EM>TestString</EM> gets evaluated and then matched against
<EM>CondPattern</EM>.
<P>
decreases your servers performance!
<P>
<LI>'<STRONG>-U</STRONG>' (is existing URL via subrequest)<BR>
-Checks if <EM>TestString</EM> is a valid URL and accessible via all the server's
+Checks if <EM>TestString</EM> is a valid URL and accessible via all the
+server's
currently-configured access controls for that path. This uses an internal
subrequest to determine the check, so use it with care because it decreases
-your servers performance!
+your server's performance!
</UL>
<P>
<TABLE WIDTH="70%" BORDER=0 BGCOLOR="#E0E0F0" CELLSPACING=0 CELLPADDING=10>
<UL>
<LI>'<STRONG><CODE>nocase|NC</CODE></STRONG>' (<STRONG>n</STRONG>o <STRONG>c</STRONG>ase)<BR>
- This makes the condition test case-insensitive, i.e. there is
+ This makes the condition test case-insensitive, <EM>i.e.</EM>, there is
no difference between 'A-Z' and 'a-z' both in the expanded
<EM>TestString</EM> and the <EM>CondPattern</EM>.
<P>
Interpretation: If you use Netscape Navigator as your browser (which identifies
itself as 'Mozilla'), then you get the max homepage, which includes
-Frames, etc. If you use the Lynx browser (which is Terminal-based), then you
-get the min homepage, which contains no images, no tables, etc. If you
+Frames, <EM>etc.</EM> If you use the Lynx browser (which is Terminal-based), then you
+get the min homepage, which contains no images, no tables, <EM>etc.</EM> If you
use any other browser you get the standard homepage.
</BLOCKQUOTE>
<STRONG>Escaping:</STRONG>
<STRONG><CODE>\</CODE></STRONG>char escape that particular char
- (for instance to specify the chars "<CODE>.[]()</CODE>" etc.)
+ (for instance to specify the chars "<CODE>.[]()</CODE>" <EM>etc.</EM>)
</PRE>
</TD>
</TR>
local regex(3) manpage or its <CODE>src/regex/regex.3</CODE> copy in the
Apache 1.3 distribution. When you are interested in more detailed and deeper
information about regular expressions and its variants (POSIX regex, Perl
-regex, etc.) have a look at the following dedicated book on this topic:
+regex, <EM>etc.</EM>) have a look at the following dedicated book on this topic:
<BLOCKQUOTE>
<EM>Mastering Regular Expressions</EM><BR>
<P>
There is a special substitution string named '<CODE>-</CODE>' which means:
<STRONG>NO substitution</STRONG>! Sounds silly? No, it is useful to provide rewriting
-rules which <STRONG>only</STRONG> match some URLs but do no substitution, e.g. in
+rules which <STRONG>only</STRONG> match some URLs but do no substitution, <EM>e.g.</EM>, in
conjunction with the <STRONG>C</STRONG> (chain) flag to be able to have more than one
pattern to be applied before a substitution occurs.
one of the following symbolic names: <CODE>temp</CODE> (default), <CODE>permanent</CODE>,
<CODE>seeother</CODE>.
Use it for rules which should
- canonicalize the URL and gives it back to the client, e.g. translate
+ canonicalize the URL and gives it back to the client, <EM>e.g.</EM>, translate
``<CODE>/~</CODE>'' into ``<CODE>/u/</CODE>'' or always append a slash to
<CODE>/u/</CODE><EM>user</EM>, etc.<BR>
<P>
the rewriting you also have to provide the 'L' flag.
<P>
<LI>'<STRONG><CODE>forbidden|F</CODE></STRONG>' (force URL to be <STRONG>f</STRONG>orbidden)<BR>
- This forces the current URL to be forbidden, i.e. it immediately sends
+ This forces the current URL to be forbidden, <EM>i.e.</EM>, it immediately sends
back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction with
appropriate RewriteConds to conditionally block some URLs.
<P>
<LI>'<STRONG><CODE>gone|G</CODE></STRONG>' (force URL to be <STRONG>g</STRONG>one)<BR>
- This forces the current URL to be gone, i.e. it immediately sends back a
+ This forces the current URL to be gone, <EM>i.e.</EM>, it immediately sends back a
HTTP response of 410 (GONE). Use this flag to mark no longer existing
pages as gone.
<P>
language. Use this flag to prevent the currently rewritten URL from being
rewritten further by following rules which may be wrong. For
example, use it to rewrite the root-path URL ('<CODE>/</CODE>') to a real
- one, e.g. '<CODE>/e/www/</CODE>'.
+ one, <EM>e.g.</EM>, '<CODE>/e/www/</CODE>'.
<P>
<LI>'<STRONG><CODE>next|N</CODE></STRONG>' (<STRONG>n</STRONG>ext round)<BR>
Re-run the rewriting process (starting again with the first rewriting
rule). Here the URL to match is again not the original URL but the URL
from the last rewriting rule. This corresponds to the Perl
<CODE>next</CODE> command or the <CODE>continue</CODE> command from the C
- language. Use this flag to restart the rewriting process, i.e. to
+ language. Use this flag to restart the rewriting process, <EM>i.e.</EM>, to
immediately go to the top of the loop. <BR>
<STRONG>But be careful not to create a deadloop!</STRONG>
<P>
<LI>'<STRONG><CODE>chain|C</CODE></STRONG>' (<STRONG>c</STRONG>hained with next rule)<BR>
This flag chains the current rule with the next rule (which itself can
- also be chained with its following rule, etc.). This has the following
- effect: if a rule matches, then processing continues as usual, i.e. the
+ also be chained with its following rule, <EM>etc.</EM>). This has the following
+ effect: if a rule matches, then processing continues as usual, <EM>i.e.</EM>, the
flag has no effect. If the rule does <STRONG>not</STRONG> match, then all following
chained rules are skipped. For instance, use it to remove the
``<CODE>.www</CODE>'' part inside a per-directory rule set when you let an
of the internal <CODE>request_rec</CODE> structure to the value
of the <CODE>filename</CODE> field. This flag is just a hack to be able
to post-process the output of <CODE>RewriteRule</CODE> directives by
- <CODE>Alias</CODE>, <CODE>ScriptAlias</CODE>, <CODE>Redirect</CODE>, etc. directives
+ <CODE>Alias</CODE>, <CODE>ScriptAlias</CODE>, <CODE>Redirect</CODE>, <EM>etc.</EM> directives
from other URI-to-filename translators. A trivial example to show the
semantics:
If you want to rewrite <CODE>/abc</CODE> to <CODE>/def</CODE> via the rewriting
Alias /def /ghi
</PRE>
If you omit the <CODE>PT</CODE> flag then <CODE>mod_rewrite</CODE>
- will do its job fine, i.e. it rewrites <CODE>uri=/abc/...</CODE> to
+ will do its job fine, <EM>i.e.</EM>, it rewrites <CODE>uri=/abc/...</CODE> to
<CODE>filename=/def/...</CODE> as a full API-compliant URI-to-filename
translator should do. Then <CODE>mod_alias</CODE> comes and tries to do a
URI-to-filename transition which will not work.
<CODE>$N</CODE> and <CODE>%N</CODE> which will be expanded. You can use this flag
more than once to set more than one variable. The variables can be later
dereferenced at a lot of situations, but the usual location will be from
- within XSSI (via <CODE><!--#echo var="VAR"--></CODE>) or CGI (e.g.
+ within XSSI (via <CODE><!--#echo var="VAR"--></CODE>) or CGI (<EM>e.g.</EM>
<CODE>$ENV{'VAR'}</CODE>). But additionally you can also dereference it in a
following RewriteCond pattern via <CODE>%{ENV:VAR}</CODE>. Use this to strip
but remember information from URLs.
<P>
Notice: These variables hold the URI/URL <EM>as they were initially
-requested</EM>, i.e. in a state <EM>before</EM> any rewriting. This is
+requested</EM>, <EM>i.e.</EM>, in a state <EM>before</EM> any rewriting. This is
important because the rewriting process is primarily used to rewrite logical
URLs to physical pathnames.
<UL>
-<LI> Run vmstat to check memory usage, page/swap rates, etc.
+<LI> Run vmstat to check memory usage, page/swap rates, <EM>etc.</EM>
<LI> Run netstat -m to check mbuf usage
From conf/httpd.conf-dist:
<PRE>
-# Limit on total number of servers running, i.e., limit on the number
+# Limit on total number of servers running, <EM>i.e.</EM>, limit on the number
# of clients who can simultaneously connect --- if this limit is ever
# reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW.
# It is intended mainly as a brake to keep a runaway server from taking
relative, of course - but if you are seeing more than a couple hits
per second on a sustained basis you should consult the pointers on
this page. In general the suggestions involve how to tune your kernel
-for the heavier TCP load, hardware/software conflicts that arise, etc.
+for the heavier TCP load, hardware/software conflicts that arise, <EM>etc.</EM>
<UL>
<LI><A HREF="#AUX">A/UX (Apple's UNIX)</A>
you want Apache to automatically start when you machine boots, and to
keep Apache running when you log-off.
- <LI>From a <A ref="#cmdline">console window</A>. This is the only option available for
+ <LI>From a <A HREF="#cmdline">console window</A>. This is the only option
+ available for
Windows 95 users.
</UL>
</PRE>
<P>Information on <A HREF="mod/mod_so.html#creating">creating loadable
modules</A> is also available.</P>
- <LI><P>Apache can also load ISAPI Extensions (i.e., Internet Server
+ <LI><P>Apache can also load ISAPI Extensions (<EM>i.e.</EM>, Internet Server
Applications), such as those used by Microsoft's IIS, and other
Windows servers. <A HREF="mod/mod_isapi.html">More information
is available.</A>
<P>Compiling Apache requires Microsoft Visual C++ 5.0 to be properly
installed. It is easiest to compile with the command-line tools
- (nmake, etc...). Consult the VC++ manual to determine how to install
+ (nmake, <EM>etc.</EM>..). Consult the VC++ manual to determine how to install
them.</P>
<P>First, unpack the Apache distribution into an appropriate
number for the request. The request is only caught if the port number
to which the client sent the request matches the port number of your
<CODE>_default_</CODE> vhost which is your standard <CODE>Port</CODE>
- by default. A wildcard port can be specified (i.e.
+ by default. A wildcard port can be specified (<EM>i.e.</EM>
<CODE>_default_:*</CODE>) to catch requests to any available port.
<P>
<LI>A <CODE>_default_</CODE> vhost or the main_server is <EM>never</EM>
matched for a request with an unknown or missing <CODE>Host:</CODE> header
field if the client connected to an address (and port) which is used
- for name-based vhosts, e.g. in a <CODE>NameVirtualHost</CODE> directive.
+ for name-based vhosts, <EM>e.g.</EM>, in a <CODE>NameVirtualHost</CODE> directive.
<P>
<LI>You should never specify DNS names in <CODE>VirtualHost</CODE>
<LI><STRONG>Setup 1:</STRONG>
Catching <EM>every</EM> request to any unspecified IP address and port,
- i.e. an address/port combination that is not used for any other
+ <EM>i.e.</EM>, an address/port combination that is not used for any other
virtual host.
<P>
<STRONG>Server configuration:</STRONG>
the sub1-vhost if the client sent no <CODE>Host:</CODE> header. <BR>
The <CODE>RewriteRule</CODE> directives are used to make sure that
a client which sent a correct <CODE>Host:</CODE> header can use
- both URL variants, i.e. with or without URL prefix.
+ both URL variants, <EM>i.e.</EM>, with or without URL prefix.
</BLOCKQUOTE>
</UL>
<CODE>private.foo.com</CODE>, if they send a <CODE>Host:
private.foo.com</CODE> header. It is important to note that this
condition exists only if you only implement this policy at the IP
-layer - all security controls used by Apache (
i.e., <A
-HREF="../mod/mod_access.html">allow, deny from,</A> etc.) are consistently
+layer - all security controls used by Apache (
<EM>i.e.</EM>, <A
+HREF="../mod/mod_access.html">allow, deny from,</A> <EM>etc.</EM>) are consistently
respected.
<H2>Compatibility with Older Browsers</H2>
projects / apache / commitdiff