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.
Attention! Helicon Tech Blog has moved to www.helicontech.com/articles/
Monday, January 31, 2011
Tuesday, January 25, 2011
Friday, January 14, 2011
Exploding myths about mod_rewrite. Part 2.
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…
Request processing contexts
In the simplest case there are only two request processing contexts:
1. server context (httpd.conf), and
2. “root folder” context (.htaccess)
Server context is executed first and after that, if further processing is allowed (no redirect or proxy happened), root folder config is processed (if present).
server-wide directive
Picture 1. Server-wide configuration (httpd.conf)
per-site directive
Picture 2. Per-site configuration (.htaccess)
Picture 3. Processing order for the configs on Pictures 1 and 2
***
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:
DirectiveA
DirectiveB
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 b
RewriteRule 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
The resulting sequence of directives will be:
DirectiveDirectoryA
DirectiveA
DirectiveDirectoryB
DirectiveB
DirectiveDirectoryC
DirectiveC
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.conf
ServerDirective
VirtualHostDirectiveA
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:
RewriteCond %{HTTP_HOST} localhost
RewriteRule . index.php [L]
RewriteCond %{HTTP_HOST} localhost
RewriteRule about$ about.php [L]
and
RewriteRule . index.php [L]
RewriteRule about$ about.php [L]
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
Let’s now put it all together. Here’s the final sequence of sections:
1. httpd.conf
2. httpd.conf
3. .htaccess
4. .htaccess
5. httpd.conf
6. httpd.conf
7. httpd.conf
8. httpd.conf
9. httpd.conf
10. httpd.conf
11. httpd.conf
12. httpd.conf
13. httpd.conf
14. httpd.conf
***
Seems every aspect of configs processing has been covered. We understand that this article may look somewhat sophisticated, but we are sure there are enthusiasts who’ll find it helpful.
So, let’s start the story…
Request processing contexts
In the simplest case there are only two request processing contexts:
1. server context (httpd.conf), and
2. “root folder” context (.htaccess)
Server context is executed first and after that, if further processing is allowed (no redirect or proxy happened), root folder config is processed (if present).
server-wide directive
Picture 1. Server-wide configuration (httpd.conf)
per-site directive
Picture 2. Per-site configuration (.htaccess)
Picture 3. Processing order for the configs on Pictures 1 and 2
***
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:
DirectiveA
DirectiveB
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 b
RewriteRule 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
If there are both
Picture 5. Processing order when there are both .htaccess and
Let’s see how the configs are merged for the request to http://localhost/Directory1/Directory2/index.html if each directory has both
Picture 6. Processing order when there are several .htaccess files and several
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
The resulting sequence of directives will be:
DirectiveDirectoryA
DirectiveA
DirectiveDirectoryB
DirectiveB
DirectiveDirectoryC
DirectiveC
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!
and
then both of them get into the merged config.
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
#httpd.conf
ServerDirective
VirtualHostDirectiveA
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
RewriteCond %{HTTP_HOST} localhost
RewriteRule . index.php [L]
RewriteCond %{HTTP_HOST} localhost
RewriteRule about$ about.php [L]
and
RewriteRule . index.php [L]
RewriteRule about$ about.php [L]
On the other hand, the limitation of
Picture 7. Processing order when
Note!
For request to localhost:80/page.html the second line will be executed, whereas for localhost/page.html the first one will fire.
If
Thus, the use of
Picture 8. Processing order when there are
These two behave similar to
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
Note!
Are applied to the corresponding virtual path, which for http://localhost/Directory1/index.html#top is /Directory1/index.html.
Summary
Let’s now put it all together. Here’s the final sequence of sections:
1. httpd.conf
2. httpd.conf
3. .htaccess
4. .htaccess
5. httpd.conf
6. httpd.conf
7. httpd.conf
8. httpd.conf
9. httpd.conf
10. httpd.conf
11. httpd.conf
12. httpd.conf
13. httpd.conf
14. httpd.conf
***
Seems every aspect of configs processing has been covered. We understand that this article may look somewhat sophisticated, but we are sure there are enthusiasts who’ll find it helpful.
IIS proxy and load balancer with web admin panel
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.
Here’s how you can set this handler to enjoy all this stuff:
SetHandler balancer-manager
Order allow,deny
Allow from 127.0.0.7 ::1 localhost
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.
Best wishes,
Ruslan – Helicon Tech Team
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.
Here’s how you can set this handler to enjoy all this stuff:
SetHandler balancer-manager
Order allow,deny
Allow from 127.0.0.7 ::1 localhost
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.
Best wishes,
Ruslan – Helicon Tech Team
Load balancing with Helicon Ape mod_proxy
Helicon Ape mod_proxy module provides simple way to configure load balancer. This article is giving explicit instructions of how to configure and test such load balancer.
Goal
Create simple cluster in which one front-end server (www.site.com), accessible via Internet, proxies some application operation in an intranet (not accessible via Internet).
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.
Configuration
Here’s the sample configuration of the balancer described above:
# route all requests starts with /static/ to static balancer
ProxyPass /static/ balancer://static-balancer/
# describe static balancer members
BalancerMember http://static1.site.com/media/
BalancerMember http://static2.site.com/media/
# enable reversing of response redirects
ProxyPassReverse /static/ http://static1.site.com/media/
ProxyPassReverse /static/ http://static2.site.com/media/
# route all other requests to application balancer
ProxyPass / balancer://app-balancer/ stickysession=sessionid routeregex=!(.*)$
# describe application balancer members
BalancerMember http://app1.site.com/ route=app1
BalancerMember http://app2.site.com/ route=app2
# enable reversing of response redirects
ProxyPassReverse / http://app1.site.com/
ProxyPassReverse / http://app1.site.com/
# enable reversing of domain in Set-Cookie headers
ProxyPassReverseCookieDomain app1.site.com www.site.com
ProxyPassReverseCookieDomain app2.site.com www.site.com
What was that?
And here’s the explanation of the code above.
section conditions that all directives inside it are applied only to the requests to www.site.com. This is especially important when the server manges several sites.
ProxyPass /static/ balancer://static-balancer/directive tells mod_proxy that all requests beginning with /static/ must be proxied via static-balancer balancer.
<Proxy balancer://static-balancer/> ...
