From: Ralf S. Engelschall
- $Revision: 1.83 $ ($Date: 1997/07/08 15:56:30 $)
+ $Revision: 1.84 $ ($Date: 1997/07/25 10:25:46 $)
The latest version of this FAQ is always available from the main
@@ -77,6 +77,8 @@
+
+
- Apache is run on over 400,000 Internet servers (as of April 1997). It has
+ Apache is run on over 500,000 Internet servers (as of July 1997). It has
been tested thoroughly by both developers and users. The Apache Group
maintains rigorous standards before releasing new versions of their
server, and our server runs without a hitch on over one third of all
@@ -572,6 +601,39 @@
Apache Server Frequently Asked Questions
@@ -310,7 +339,7 @@
How thoroughly tested is Apache?
@@ -204,6 +206,9 @@
+
+ RewriteEngine on
+ RewriteBase /~foo/bar/
+ RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]
+
+
+- For an explaination on how to implement these restrictions, see + For an explanation on how to implement these restrictions, see + Apache Week's + articles on + Using User Authentication + or + DBM User Authentication. +
++ This variable is set and thus available in SSI or CGI scripts if and + only if the requested document was protected by access + authentication. For an explanation on how to implement these restrictions, + see Apache Week's @@ -1574,6 +1659,13 @@ HREF="http://www.apacheweek.com/features/dbmauth" >DBM User Authentication.
++ Hint: When using a CGI script to receive the data of a HTML FORM + notice that protecting the document containing the FORM is not + sufficient to provide REMOTE_USER to the CGI script. You have + to protect the CGI script, too. Or alternatively only the CGI script (then + authentication happens only after filling out the form). +
+ There is a collection of + Practical Solutions for URL-Manipulation + where you can + find all typical solutions the author of + mod_rewrite + currently knows of. If you have more + interesting rulesets which solve particular problems not currently covered in + this document, send it to + Ralf S. Engelschall + for inclusion. The + other webmasters will thank you for avoiding the reinvention of the wheel. +
++ There is an article from + Ralf S. Engelschall + about URL-manipulations based on + mod_rewrite + in the "iX Multiuser Multitasking Magazin" issue #12/96. The + german (original) version + can be read online at + http://www.heise.de/ix/artikel/9612149/, + the english (translated) version can be found at + http://www.heise.de/ix/artikel/E/9612149/. +
++ Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful + module which can help you in really all aspects of URL rewriting, so + it can be no trivial module per definition. To accomplish its hard job it + uses software leverage and makes use of a powerful regular expression + library by Henry Spencer which is an integral part of Apache since its + version 1.2. And regular expressions itself can be difficult to newbies, + while providing the most flexible power to the advanced hacker. +
++ On the other hand mod_rewrite has to work inside the Apache API environment + and needs to do some tricks to fit there. For instance the Apache API as of + 1.x really was not designed for URL rewriting at the .htaccess + level of processing. Or the problem of multiple rewrites in sequence, which + is also not handled by the API per design. To provide this features + mod_rewrite has to do some special (but API compliant!) handling which leads + to difficult processing inside the Apache kernel. While the user usually + doesn't see anything of this processing, it can be difficult to find + problems when some of your RewriteRules seem not to work. +
++ Use "RewriteLog somefile" and + "RewriteLogLevel 9" and have a precise look at the + steps the rewriting engine performs. This is really the only one and best + way to debug your rewriting configuration. +
++ If the rule starts with /somedir/... make sure that really no + /somedir 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 + somedir 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 + rewriting. +
++ You can't! The reason is: First, case translations for arbitrary length URLs + cannot be done via regex patterns and corresponding substitutions. One need + a per-character pattern like sed/Perl tr|..|..| feature. Second, just + making URLs always upper or lower case will not resolve the complete problem + of case-INSENSITIVE URLs, because actually the URLs had to be rewritten to + the correct case-variant residing on the filesystem because in later + processing Apache needs to access the file. And Unix filesystem is always + case-SENSITIVE. +
+
+ But there is a module named mod_speling.c
(yes, it is named
+ this way!) out there on the net. Try this one.
+
+ Because you have to enable the engine for every virtual host explicitly due + to security concerns. Just add a "RewriteEngine on" to your + virtual host configuration parts. +
++ There is only one ugly solution: You have to surround the complete flag + argument by quotation marks ("[E=...]"). 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. + So you have to write "[E=any text with whitespaces]". +
+