Wikka Documentation : HtaccessConfigInfo

• HomePage
• PageIndex Index
• RecentChanges
• TextSearch Search
• UserSettings Login/Register
• Search:
• Your hostname is ec2-3-95-37-22.compute-1.amazonaws.com

Wikka Documentation

---

.htaccess Configuration Documentation

applies to Wikka 1.1.6.0 (and 1.1.5.1 and 1.1.53)

This is the documentation page for how Wikka manages server configuration via .htaccess files. This applies only to Wikka installed on an Apache webserver.
Each documented directive (or group of directives) 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 bulleted items (list) imply 'or': one of these must be specified to enable the directive in an .htaccess file.
Note that the AllowOverride directives mentioned must be located in a <Directory> section for the directory Wikka is installed in or a higher one.

Wikka on Apache

Wikka "assumes" it will be installed on an Apache web server. Although it's perfectly possible to install Wikka on other web servers (as long as PHP is installed), Wikka comes with a number of .htaccess configuration files for use with Apache. This page serves as an explanation of the function of these files and how they work.
If you control your own server and are able to use the httpd.conf file for server configuration, using this is preferable over using .htaccess files. This page does not explain how to do that but if you have sufficient Apache knowledge you can use this page as a guideline for what to add to your configuration to achieve the same functionality.

Wikka on other web servers

With other web servers than Apache these files will generally be ignored: to implement their function you'll have to do your own configuration. The documentation on this page can serve as a guideline but we cannot directly help you configure Wikka for another web server.
Users running Wikka on other webservers than Apache are welcome to add documentation for that to this page or on a separate page on this site!

What is an .htaccess file?

The Apache web server is normally configured by means of a file called httpd.conf; this file can contain configuration directives for the server in general, as well as for specific directories and files. If you have installed your website (or Wikka) on a hosted server, you generally do not have access to your own httpd.conf file. A web host may allow their customers some configuration for their own sites though by enabling the use of .htaccess files in their own directories; many don't though. Not every kind of server configuration can be done via .htaccess - but a number of very useful things can, and Wikka tries to take advantage of that. For instance, you can use it for some security, and to enable "pretty" (and more search-engine-friendly) URLs.

Wikka installs a number of .htaccess files. These will be effective only if:

1. Wikka is installed on an Apache server

1. The server is configured to allow the use of .htaccess files for the directives we use here. (If not, you may try convincing your host to allow it for you, armed with the documentation on this page to convince them why it's important. See the 'Prerequisite' boxes for what is needed in the main Apache configuration.)

The .htaccess files distributed with Wikka

As of version 1.1.6.0 Wikka installs the following .htaccess files:

In the installation directory:

Version 1.1.5.1 and 1.1.5.3 had the same .htaccess file.

In a number of subdirectories (where [wikka] stands for the Wikka installation directory):

• [wikka]/css/

• [wikka]/images/

• [wikka]/3dparty/plugins/freemind/

• [wikka]/3dparty/plugins/wikiedit/

These all have the same content:

Version 1.1.5.1 and 1.1.5.3 do not have a 3rdparty directory; the corresponding .htaccess files are found in [wikka]/freemind/ and [wikka]/wikiedit2/.

The main .htaccess file

The file provides two main functions:

• A mechanism to prevent (some) referrer spam (see also WikkaSpamFighting)

• A mechanism for "friendly" URLs (friendly for humans as well as friendly for (some) search engines)

Combating referrer spam

This is handled by the following directives (local line numbers added for easy reference):

When a browser (or other user agent) makes a server request, it may send along a "referrer" in a HTTP header; normally this indicates the page where a link to the requested page was found. Spammers can fake the referrer hoping that a referrer list on the site will provide a link back to the (fake) referrer URL.

• Line 1: The SetEnvIfNoCase directive tries to match a substring in a referrer: the expression between brackets is a series of possible substrings to look for, separated by pipe characters ('|'). If a (case-insensitive) match is found the environment variable BadReferrer is set.

• Line 2: order tells Apache to evaluate any "deny" directives first, and allow access to whatever does not match

• Line 3: deny denies access if the environment variable BadReferrer is set (as a result of the directive on line 1): the server will then return a '403 Access forbidden' response. If the variable isn't set access is allowed.

Do note that sending a '403' response will not prevent the referrer spam turning up in the server logs (if it is repeated); it merely prevents it from showing up in the referrers that Wikka logs since they won't make it that far.

To make effective use of this mechanism, you should regularly check the referrers to your site, and use this to update the substrings list between brackets. The current list is rather old, and bound to be not very effective any more: it will help only if it is kept up-to-date with actual (undesirable) referrers you find on your Wikka site. Note that the substrings need only be in lowercase since the matching is case-insensitive (thus having both 'xxx' and 'XXX' is superfluous)!

Friendly URLs

For "Friendly URLs" Wikka makes use of the mod_rewrite module of Apache that rewrites requested URLs on the fly. This is an extension module, meaning that it needs to be explicitly enabled in the main Apache configuration. If you control your Apache configuration, make sure it is enabled. If you don't (as on most hosted accounts), ask your host if mod_rewrite is enabled.
Currently there is no known method to simply detect directly whether mod_rewrite is available.
Of course configuration via .htaccess files needs to be enabled as well for Wikka to be able to use mod_rewrite configured in the main .htaccess file.

Wikka needs to know you want to use URL rewriting

See ModRewrite for how to tell Wikka whether it should assume URL rewriting.

Apache should not execute what it doesn't support

Since the directives used by mod_rewrite will result in a '500 server error' when mod_rewrite is not enabled, the statements are enclosed in an IfModule section so Apache will only try to to execute them when mod_rewrite is enabled:

Turning on the engine

The block starts with actually turning the rewrite engine on:

In some cases, the rewrite engine may already be turned on in the main Apache configuration. You cannot turn it on again: Apache will generate a 500 server error in this case. If you get this error, try disabling this one statement by commenting it out (put a # in front of it). See also ServerErrorWorkaround.

Handling directories

The first step is to ensure that directories have a URL that actually ends in a slash (required for directories):

Let's see what it does:

• The first statement with RewriteCond sets a condition for the actual rewriting: the RewriteRule on the second line will be executed only if the condition evaluates to true. The expression %{REQUEST_FILENAME} translates the requested URL to a full path on the local file system: that way Apache can use the file system to determine whether the requested path is actually a directory: -d here means "is a directory".
  A RewriteCond condition always applies to only a single RewriteRule statement, but there can multiple conditions (which all must be true) for a RewriteRule.

• When the requested URL actually is a directory, the RewriteRule will be applied. The first part is a regular expression (applied to the part of the URL that is within the directory where the .htaccess file is located!) that looks whether the the path does not contain a slash or a dot and does not end in a slash (as it should for a directory). If there is a match, the second part appends a slash: $1 is a "backreference" which simply copies the string that was matched by the regular expression and a slash is appended to that.

The result of this is that the browser will receive a "301 moved permanently" response from the server, with a Location: header to tell it where to look - the result of the rewrite rule. The browser will then (have to) make a new request for the directory, this time with the slash added at the end.

If you're thinking this has nothing to do with "friendly URLs" you're right. :) But it's there so it gets documented here...
There are actually several problems with this part of the current .htaccess file as distributed with Wikka 1.1.6.0 (and earlier); see the development page for more about this.

Friendly URLs (at last)

Here's the beef, just one, but one really important, statement:

Here it's important to know that before Apache starts working with a URL in mod_rewrite it strips off any query string (the part that starts with a ?) and remembers it for later use. The regular expression we use here simply matches the whole string (again - within the directory where the .htaccess is sitting) and then appends it ($1) to wikka.php?wakka= which is the format that Wikak needs internally. What if there was a query string already? We tell Apache to append it again with the QSA flag (Query String Append) and Apache is clever enough not to use a question mark if there is already one in the resulting URL. Finally, we tell Apache that this is the last rule to apply by means of the L flag.

The .htaccess files in the subdirectories

When a browser renders a page, it will first request the URL for the page from the server, and then does an additional request for any files that are embedded or needed for rendering such as images, stylesheets, JavaScript files and applets. But because we are rewriting the URLs the browser requests for these extra resources will also get treated by the rewrite engine.

If we don't prevent this from happening, the rewriting will result in URLs that no longer point to the actual files (when they did in the first place). We must tell Apache to not use URL rewriting for these files. This is easy, since they are in separate directories: the .htaccess file placed in these directories simply tells Apache to turn off the rewriting engine here:

(again wrapped in an appropriate IfModule section so that the statement will be executed only if the mod_rewrite module is actually enabled). URLs pointing to files in these directories now won't be rewritten.

---

CategoryDocumentation

• [Source]
• [History]
• 2005-07-07 19:26:12
• Public page
• Your hostname is ec2-3-95-37-22.compute-1.amazonaws.com

Valid XHTML :: Valid CSS: :: Powered by WikkaWiki