Using Administration .htaccess on Microsoft IIS With Helicon

Using Administration .htaccess on Microsoft IIS With Helicon: "Do you in troubles with IIS server? Is your .htacess file non-tunned? Do you want a best solution?! Yes, we have it. Helicon Ape provides support for Apache .htacces and .htpasswd configuration files for Microsoft IIS"

mod_rewrite and mod_proxy in one .htaccess on IIS 6 server

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.

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.

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

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/> ...