Revision [7809]
This is an old revision of HtaccessConfig made by JavaWoman on 2005-05-03 08:19:32.
Configuration via .htaccess
See also:
Documentation: HtaccessConfigInfo.For documentation of what the current .htaccess files do, see HtaccessConfigInfo; here, we're going to look at what the main .htaccess file might do for us - while also getting rid of the separate .htaccess files in subdirectories.
Each item has a "Prerequisite" box: this specifies what is required in Apache's main configuration (httpd.conf) for the current or higher directory to enable the proposed directive(s) in the .htaccess file. Multiple items imply 'or': one of these must be specified to enable it.
This page assumes we're working on Apache; other web servers may have similar mechanisms to exploit (even may use .htaccess files for that) but we're not dealing with that here.
Users working with a different webserver are welcome to add their own equivalent methods to this page or a separate one for their webserver!
this page is still a stub - more content to follow...
Efficiency
Default Apache behavior
Normally an Apache server has a DirectoryIndex directive in its server configuration (httpd.conf) that tells it which "index" file(s) to look for, in what order, when a user agent makes a request for a directory. Each of the file names specified will be tried in turn; if none of them is found (or none are defined), the directory content will be shown (if enabled) or a '403 Forbidden' response will be given if directory browsing is disabled (see Security options below).Getting to Wikka's main file: wikka.php
Wikka runs operates completely through wikka.php, and it comes with an index.php file in its installation directory which does nothing but redirect to wikka.php - which in its turn will redirect to the declared home page if not given a page parameter. The problem with this method is that it assumes that Apache's configured search path actually contains not just the standard index.html but also index.php - not guaranteed to be the case! But even if it is, going first to index.php only to be redirected to wikka.php is rather ineffcient, because it means three browser requests just to get at the home page when it's requesting the installation directory.Making it more efficient
Prerequisite:
If .htaccess is not enabled on the server, we'll still need that index.php page redirecting to wikka.php (and hope it is declared in the Apache configuration as one of the directory index files to look for) - so we'll have to keep it. But if it is enabled we can save one browser roundtrip by telling Apache to go looking directly for wikka.php when a directory is requested - instead of going through its declared search path until it stumbles onto index.html which does exist in the directory. This will do it:- AllowOverride Indexes
- AllowOverride All
DirectoryIndex wikka.php
Security options
Combating referrer spam
Preventing directories from being browsed
see also Directory requests below!Directory requests
Friendly URLs
Side effects to be aware of
Putting it all together
Extra measures outside of .htaccess files
All of the above is dependent on .htaccess configuration being enabled - which we cannot be certain of. But some of the mechanisms can be mimicked without that. This section looks at what we can do without having .htaccess available.
Installation
The current WikkaInstallation installation and update instructions tell the WikiAdmin to go to the installation directory with the browser. Since we cannot be sure that .htaccess configuration is enabled or that index.php is in the Apache index search path, this may not actually work. The instruction should be to go to the wikka.php file in that directory instead.Directory index
As pointed out above, the file name index.php will not necessarily be declared in Apache's standard DirectoryIndex directive. If this is the case, a browser may actually end up showing the content of the Wikka installation directory - especially since .htaccess configuration is also not guaranteed to be enabled and whatever we put in there to prevent directory browsing may be ineffective. On the other hand, index.html is practically guaranteed to be in the index search path. We could add a minimal index.html file that does a "meta redirect" and - for browsers and search engines that don't support this - provides a link to wikka.php as well:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Redirect to home page</title>
<meta http-equiv="refresh" content="0; url=wikka.php" />
</head>
<body>
<h1>Redirect to home page</h1>
<p>If your browser doesn't automatically redirect, follow this link to take you to the <a href="wikka.php">home page</a></p>
</body>
</html>
<html>
<head>
<title>Redirect to home page</title>
<meta http-equiv="refresh" content="0; url=wikka.php" />
</head>
<body>
<h1>Redirect to home page</h1>
<p>If your browser doesn't automatically redirect, follow this link to take you to the <a href="wikka.php">home page</a></p>
</body>
</html>
Note that we don't make any assumptions about the name of the Wikka site; of course a WikiAdmin can edit the file to reflect the name but we can't do it dynamically: this is a static HTML file.
It's entirely possible that the (root) directory where Wikka is installed already contains an index.html file. To prevent blindly overwriting that file, our file should not come as a physical file in the installation archive, but be generated dynamically from the installer program. The installer can detect the pre-existence of an index.html file and ask the WikiAdmin permission for overwriting it (and renaming the original as a backup!). And when we are generating the file from the installer, we can also insert the name of the Wikka site, giving a warning to the WikiAdmin that this file must be edited if the name is changed in the configuration at some point. (A future user interface for maintaining the configuration could do this automatically, of course.)
CategoryDevelopment
