Monday, January 31, 2011

Although we declare that Ape is delivering .htaccess on IIS 7, we want to remind that .htaccess on IIS 6 is also available. If you are missing so easy and readable mod_rewrite or mod_proxy on your IIS server, we offer you a worthy solution – Helicon Ape product.Please notice that support of .htaccess on IIS 6 is somewhat limited, so please consult the Compatibility chart (http://www.helicontech.com/ape/doc/compatibility.htm) to see if required functionality is supported. As you could see, even on IIS 6 mod_rewrite and mod_proxy are available nearly in their full.Mod_rewrite is a perfect flexible URL transformation tool often lacked especially by IIS 6 users as Microsoft doesn’t provide an alternative to it. Helicon Ape mod_rewrite offers extensive map files support, database mappings, vast rewriting capabilities and more.In its turn, IIS6 accompanied by mod_proxy may serve as forward as well as reverse proxy server allowing to provide Internet access to firewall-protected internal clients and to provide Internet access to a server protected by firewall consequently. The detailed insight into this matter is given here (http://www.helicontech.com/articles/mod_proxy-proxy-server-inside-iis/)A detailed guide on how to install Helicon Ape for IIS 6 server and enable necessary modules is posted on our blog (http://www.helicontech.com/articles/using-helicon-ape-under-iis6-windows-server-2003/). The article also advises on how to test mod_rewrite and mod_proxy operation on IIS 6.This article covers the use of mod_rewrite and mod_proxy modules on IIS6-driven web-servers as they are considered the most demanded and frequently used modules on Apache, so having them in one .htaccess right on your IIS 6 server not only lets you shift your configs from Apache without modification, but also extend your IIS in a helpful and efficient way.

Tuesday, January 25, 2011

Friday, January 14, 2011

This article is the anticipated sequel of “Exploding myths about mod_rewrite. Part 1” published more than a year ago. In this two-volume work (which may well become a three-volume one soon) we try to thoroughly explain each tiny issue/option of Helicon Ape mod_rewrite (also true for Apache) to give you all the knowledge necessary to master it in its full. Part 2 devotes itself to contexts processing order.So, let’s start the story…

***Now let’s make it more complicated—we’ll have the rules in the root folder and in Directory1. The processing order then becomes:

1. /.htaccess

DirectiveA

2. /Directory1/.htaccess

DirectiveB

Picture 4. Processing order in case of several .htaccess files

For the request to http://localhost/index.html only the first context is applied, while for http://localhost/Directory1/index.html (and other requests to deeper subfolders) the merged context 1+2 is executed. In our case it’s:

DirectiveADirectiveB

Thus, the child context complements and refines the parent one (but not the server one). This is true for nearly all Apache/Ape modules EXCEPT mod_rewrite. It’s one of a kind and behaves differently.mod_rewrite behavior

Historically, or for convenience purposes, mod_rewrite contexts do not complement but COMPLETELY OVERRIDE each other. So, if we have two configs

1. /.htaccess

RewriteRule a b

2. /Directory1/.htaccess

RewriteRule b с

the resulting config to be applied to the request will be

RewriteRule b c

and NOT

RewriteRule a bRewriteRule b с

which may be unobvious for newbies.

For experts! mod_rewrite has an option allowing to change this behavior and inherit the parent rules:

1. /.htaccess

RewriteRule a b

2. /Directory1/.htaccess

# inherit parent rules RewriteOptions inherit RewriteRule b с

makes up the following merged config:

RewriteRule b с # parent rules are appended to the end of the merged config! RewriteRule a b

section

section is equivalent in meaning to writing rules in the .htaccess located inside this directory. The only difference is that lives in httpd.conf.If there are both section and .htaccess for the same directory, they are merged; if the directives inside them interfere, the .htaccess directives are preferred.

Picture 5. Processing order when there are both .htaccess and for the same location

Let’s see how the configs are merged for the request to http://localhost/Directory1/Directory2/index.html if each directory has both section and corresponding .htaccess file.

Picture 6. Processing order when there are several .htaccess files and several sections which are applicable for the same request

httpd.conf

DirectiveDirectoryA

DirectiveDirectoryB

DirectiveDirectoryС

/.htaccess

DirectiveA

/Directory1/.htaccess

DirectiveB

/Directory1/Directory2/.htaccess

DirectiveC

The following logics is applied to form the merged config:

1. First to execute is httpd.conf except for tagged sections: 2. Distributed config is built up from the following parts: a. empty context is created; b. requested URL is divided into parts like: / /Directory1/ /Directory1/Directory2/ c. physical path is defined for each virtual directory: / —> C:/inetpub/wwwroot/ /Directory1/ —> C:/inetpub/wwwroot/ Directory1/ /Directory1/Directory2/—> C:/inetpub/wwwroot/ Directory1/ Directory2/ d. corresponding section is found for each path; e. corresponding .htaccess is found for each path

Usually directives’ order is not so important, but not in case with mod_rewrite; that’s why understanding the principles of configs merging may dramatically reduce development and debugging times.

Note! sections are applied not to all parts of the request (see above) but only to the deepest part, and all matches are searched for, for example, if there are two sections:

and

then both of them get into the merged config.

directive

One should remember that everything written inside server context is applied to all requests and for all sites. Sometimes it may be necessary to limit the scope of directive to one or several sites and that’s the case to use section. can reside in httpd.conf only. It is merged with server config, i.e. complements it. In case of both .htaccess and section for the specific location, the latter has higher priority and can reject server settings for the specific site (in our case localhost).

#httpd.confServerDirectiveVirtualHostDirectiveA

Note! mod_rewrite offers another way to restrict scope for the rules to specific host – RewriteCond %{HTTP_HOST}.The difference is that RewriteCond %{HTTP_HOST} must appear before each RewriteRule, while groups all rules for localhost together and affects all of them. Compare:

On the other hand, the limitation of is that it can’t be used in .htaccess.

Picture 7. Processing order when section is present in httpd.conf

Note! sections are NOT merged together – if there are several s matching the request, the one with the best match is applied. E.g.:

For request to localhost:80/page.html the second line will be executed, whereas for localhost/page.html the first one will fire.

If section is specified inside (which is possible), the processing order is as follows: section of the main server config is accounted first, then inside and after all – .htaccess.

Thus, the use of section outside will lead to application of its () rules to all sites (in case they use this shared folder).

Picture 8. Processing order when there are and sections as well as .htaccess and sections

These two behave similar to but are used for file names, not for the full path.E.g., for http://localhost/Directory1/index.html#top they will find the correspondence in file system C:\inetpub\wwwroot\Directory1\index.html and will merge all sections valid for this file name (e.g. and will be merged).Note! and may reside in .htaccess as well! and sections

Are applied to the corresponding virtual path, which for http://localhost/Directory1/index.html#top is /Directory1/index.html.Summary

Since build 3.0.0.50 Helicon Ape offers a web interface for the load balancer.

Web interface illustrates the current state of load balancers and their nodes.

load balancer web interface

The following info is shown for the balancer nodes:

* Worker URL; * Route: name of balancer member; * RouteRedir: name of the node to redirect requests to in case of inaccessibility; * Factor: mamber relative weight; * Status: state of member; * Elected: how many times the node was chosen to process request, i.e. practically the number of processed requests; * Transmitted: number of bytes sent to the node; * Received: number of bytes received from the node; * EMA ResponseTime: exponential moving average of response time * Status TTL: period of time for which the node is excluded from the balancing process due to inaccessibility.

Please pay attention that the URL to which the handler is mapped must be secured from unauthorized access. For instance, the access must be granted for local machine only (see example above) or basic/digest authorization must be enabled.

Feel free to try our web interface for the load balancer to facilitate control and get comprehensible statistics for any node and any balancer.

Goal

To improve stability (resistance to failures) and speed the application will run on internal servers (app1.site.com & app2.site.com) which will distribute requests between themselves. In case one server is down (scheduled maintenance, upgrade, breakdown), all requests will be directed to another server.

Requests between the servers are distributed based on the response time value. I.e. the quicker back-end returns responses (better copes with the load), the more requests it will get.

The application uses sessions, so if the request contains the cookie with session id, this request must be assigned to the back-end which initiated this session. The cookie is of the following format [session_data]![backend_id].

Static content is also shared between two internal servers (static1.site.com & static2.site.com) so they need to distribute it among themselves as well.