Module mod_rewrite Part 1

You probably met the term "mod_rewrite" on the network. For our readers who are not fully acquainted with this module of the Apache web server, as well as for those who hear about it for the first time, I will try to tell more about this module in this publication (in several parts).

The mod_rewrite module is the Apache web server program module (note that it will not run under other web servers!). Its primary function is the manipulation of actions with the URL. The module is very versatile and versatile, so I will try to show here a lot of real examples.

Mod_rewrite is a great module that provides a "rule-based mechanism for dynamically changing the requested URLs." This is really a powerful tool, and therefore, its knowledge is fundamentally important if you want to become a genuine web master or web programmer. Not so much in principle, whether you will use it in your work, how important it is that you know what it can do, and you can tell your boss about it when there is a desire to do something strange with the web server.

However, you need to be very careful and even meticulous when working with this module! Some errors that you are able to tolerate can lead to a logical loop, causing an uninterrupted 100% load of the CPU (CPU).

In order not to seem lengthy in reasoning, I will give some very simple examples.

Before we can get started, you'll need to check whether the module is installed on your web server or not.

There are several ways to check this:

1. Ask your system administrator whether he (or she) knows about the presence of this module on the web server. They really need to know, but as practice shows - there are also not very well-versed sysadmins ...
   Do not strain others: if you use your web server with hundreds of other domains, your actions can wake up some sleeping dogs, as using mod_rewrite will always involve some increased CPU load.
2. Check your Apache configuration file (httpd.conf) if you have access to it. One possible standard path can be:
   /etc/httpd/httpd.conf
   However, your path may obviously be different from this.
3. Check the operation of your server with the examples below. If the server works without errors - mod_rewrite is really installed on your system. If not, you will receive the following message when you request any web page from your server: "Internal Server Error"

Also, you will see this entry in the "error.log" file:
"Invalid command 'RewriteEngine', perhaps mis-spelled or defined by a module not included in the server configuration."

Now let's dig deeper and see the first practical example.

Suppose that you will use mod_rewrite only for your own site, that is, not as a generalized cross-server installation.

For our example, you will need to use the .htaccess file.

.htaccess file

To use this method, you must upload a file called ".htaccess" (please pay attention to the dot at the beginning of the file name!) To the server folder with which you will work. This can be done via telnet or ftp. (Warning: .htaccess should be loaded in "ASCII mode", that is not in binary mode!)

If you already have a ".htaccess" file, for example with the following entries: Options Includes +ExecCGI AddType text/x-server-parsed-html .html

Then simply add our sample code to the existing one from the bottom (Important: edit your .htaccess file in an ASCII editor such as Notepad).

The first two entries will start the module itself: RewriteEngine on Options +FollowSymlinks

Tip: the "RewriteEngine off" entry will override any subsequent commands. This is a very useful feature: instead of having to comment on all the subsequent lines, all you have to do is set the "off".

If your system administrator prohibits you from using "Options + FollowSymlinks", you will not be able to restrict the use of mod_rewrite for individual directories, instead the changes will apply to the entire server.

The following required entry is: RewriteBase /

"/" Is the root (main) URL. If you have any other URL, you can specify this in this directive, however "/" is usually equivalent to the address "http: //domain.ru".

And now, gentlemen, let's move on to more interesting records!

Suppose that you want to protect your .htaccess file from unauthorized access. On some servers, you can easily read this file simply by entering the URL of the following format into the address field of your browser: http://www.domain.com/.htaccess - a serious omission of protection, because the content of your .htaccess can show important information about the settings and Settings of your site to a person who knows how to apply this knowledge against you.

To block this access, write the following: RewriteRule ^.htaccess$ - [F]

This rule translates as follows:

If someone tries to access the .htaccess file, the system should generate an HTTP response of 403 or 403 Forbidden - You do not have permission to access /.htaccess on this server error code.

The .htaccess $ construct in this regular expression means:

^ - the anchor of the beginning of the line
$ Is the end of line anchor
. - in regular expressions, the dot "." Denotes a meta-symbol and must be protected by a backslash if you still want to use the actual point.

The file name must be exactly between the start and end anchors. This will ensure that only this particular file name and no other will generate an error code.

[F] - a special "forbidding" flag (forbidden).

In this example, the file ".htaccess" will now consist of the RewriteEngine on Options +FollowSymlinks RewriteBase / RewriteRule ^.htaccess$ - [F] lines: RewriteEngine on Options +FollowSymlinks RewriteBase / RewriteRule ^.htaccess$ - [F]

If we add our code (in the examples) to the existing ".htaccess" file, we get the following construction: Options Includes +ExecCGI AddType text/x-server-parsed-html .html RewriteEngine on
Options +FollowSymlinks RewriteBase / RewriteRule ^.htaccess$ - [F] Options Includes +ExecCGI AddType text/x-server-parsed-html .html RewriteEngine on
Options +FollowSymlinks RewriteBase / RewriteRule ^.htaccess$ - [F]

This introduction only covers the basics required to work with the mod_rewrite module. In the second part of this series of training articles I will try to explain the use of various conditions in the configuration of the module.