MRVirtual » IIS 7.0 http://mrvirtual.de Blogging about Microsoft Software Fri, 03 Jul 2009 23:40:19 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 URL Rewrite through ISA Server ends in a loop http://mrvirtual.de/2009/07/04/url-rewrite-through-isa-server-ends-in-a-loop/ http://mrvirtual.de/2009/07/04/url-rewrite-through-isa-server-ends-in-a-loop/#comments Fri, 03 Jul 2009 23:33:09 +0000 MRVirtual http://mrvirtual.de/?p=20 Recently I’ve been having some trouble with the IIS 7 URL Rewrite module in combination with ISA Server 2006 which took me a serious amount of time to figure out the root of the behavior.

The task was pretty simple: I set up a website in IIS 7 with multiple bindings: example.net:80 and www.example.net:80. For SEO reasons the user shall always be redirected to example.net/… regardless of the URL he entered in the first place. This can easily be done with the following URL-Rewrite rule:

<rewrite>
<rules>
<rule name="Enforce Hostname" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" negate="true" pattern="^example\.net$" />
</conditions>
<action type="Redirect" url="http://example.net/{R:0}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>

This rule works without problems if the client can access the web server directly. However, if the site is published through ISA server I wasn’t able to get it working. The relevant portion of the publishing rule can be seen below

Web Site Publishing Rule Properties

Web Site Publishing Rule Properties

The public names were set to example.net; www.example.net.

If an external client tried to browse the website via http://example.net/site.html everything worked fine. However, if the user typed http://www.example.net/site.html he got stuck in a loop redirecting exactly to the site he came from instead of being redirected to http://example.net/site.html.

A Netmon trace on the client confirmed this behavior. It received an HTTP response with a response header
StatusCode: 301
Location: http://www.example.net/site.html

Furthermore the payload of the response contained a link to http://www.example.net/site.html

By disabling link translation in the settings of the web site publishing rule, the contents of the payload represented the URL rewrite rule correctly, but still the relevant part in the response header wasn’t like expected.
To investigate this further, I installed a great free tool called TrafficLog. Using TrafficLog I could see how the client requested the website (Raw Request Header) and how the ISA server altered the request (Processed Request Header) before sending it to the internal web server:


Raw Request Header (1)
GET /site.html HTTP/1.1
Via: 1.1 ISATOP01
If-None-Match: "94802358f0fbc91:0"
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: www.example.net
If-Modified-Since: Fri, 03 Jul 2009 15:10:04 GMT
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Accept-Language: de
UA-CPU: x86
Connection: Keep-Alive

Processed Request Header (1)
GET /site.html HTTP/1.1
Via: 1.1 ISATOP01, 1.1 ISAEX
Host: www.example.net
If-None-Match: "94802358f0fbc91:0"
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
If-Modified-Since: Fri, 03 Jul 2009 15:10:04 GMT
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Accept-Language: de
UA-CPU: x86
Connection: Keep-Alive

This resulted in the following response from the IIS web server, which is exactly what you expect as a result of the URL rewrite rule above:


Raw Response Header (1)
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: http://example.net/site.html
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Fri, 03 Jul 2009 19:18:34 GMT
Content-Length: 155


Raw Response Body bytes (1)
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://example.net/site.html">here</a></body>

But now the ISA Server does it’s part of messing up the situation. If link translation is enabled, the client will receive the following answer by ISA:


Processed Response Header (1)
HTTP/1.1 301 Moved Permanently
Connection: Keep-Alive
Content-Length: 155
Date: Fri, 03 Jul 2009 19:18:34 GMT
Location: http://www.example.net/site.html
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET


Processed Response Body bytes (1)
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://www.example.net/site.html">here</a></body>

As described earlier, after disabling link translation in the properties of the Web Site Publishing Rule, the body of the response was correct, but the response header still contained the ‘www’.

Somehow the ISA Server still applied link translation to the response header. My next step was to completely disable the link translation Web-Filter. To do so, navigate to Configuration -> Add-Ins in the ISA Management Console, choose Web Filters and disable the Link Translation Filter. At this point the web site could be access for the first time like expected. The Processed Header now looked like


Processed Response Header (1)
HTTP/1.1 301 Moved Permanently
Connection: Keep-Alive
Content-Length: 155
Date: Fri, 03 Jul 2009 20:10:51 GMT
Location: http://example.net/site.html
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET


Processed Response Body bytes (1)
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://example.net/site.html">here</a></body>

As you can imagine, it isn’t a very good idea to disable link translation server-wide because you will need this functionality in a lot of situations.

After a long time of trial and error I finally found the setting which caused all the trouble. Somehow it seems to be a problem if the internal site name (see screenshot above again) equals the location to which the web server redirects. In my scenario, the internal site name was set to example.net, exactly the host header enforced by the URL rewrite rule. So the simple solution to this weird  problem was to change the internal site name. You can set it to whatever you want. Since the option “Forward the original host header instead of the actual one” is selected, there is no need for a meaningful internal site name. In this case, I set it to www.example.net, but null would have been possible as well.

I can’t say why ISA acts the way it does in this situation. But I’m sure happy, that I could finally solve the problem. If anybody can add further information on this topic, please leave a comment!

]]> http://mrvirtual.de/2009/07/04/url-rewrite-through-isa-server-ends-in-a-loop/feed/ 38 Installing Symphony CMS on IIS 7.0 http://mrvirtual.de/2009/05/29/installing-symphony-cms-on-iis-70/ http://mrvirtual.de/2009/05/29/installing-symphony-cms-on-iis-70/#comments Fri, 29 May 2009 00:54:08 +0000 MRVirtual http://mrvirtual.de/?p=13 Perhaps some of you know the Symphony Content Management System. A customer of mine wanted to run it on Windows Server 2008 with IIS 7.0 (in fact on the very same server this WordPress installation is running on). But sadly Symphony doesn’t run out of the box on IIS.

Of course as a base setup you need PHP and MySQL running. A great source that describes how to achieve this would be the article Using FastCGI to Host PHP Applications on IIS 7.0 over at iis.net. The same is true for MySQL, so check out Setting up MySQL for PHP applications.
In order to install Symphony CMS with full functionality make sure you have the following PHP extensions enabled:

  • php_mbstring.dll
  • php_mcrypt.dll
  • php_mysql.dll
  • php_xsl.dll
  • php_zip.dll

Before you can start the installation process of Symphony, you have to alter 2 files. Please locate the index.php file in the root folder of the Symphony website. There you should see the lines

define('DOCROOT', rtrim(dirname(dirname(__FILE__)), '/'));
define('DOMAIN', rtrim(rtrim($_SERVER['HTTP_HOST'], '/') . dirname(dirname($_SERVER['PHP_SELF'])), '/'));

right at the beginning.
Change those to

define('DOCROOT', rtrim(dirname(dirname(__FILE__)), '/\\'));
define('DOMAIN', rtrim(rtrim($_SERVER['HTTP_HOST'], '/\\') . dirname(dirname($_SERVER['PHP_SELF'])), '/\\'));

(notice the added double backslashes) and apply the same procedure to the index.php located inside the /symphony folder. As a result you should get:

define('DOCROOT', rtrim(dirname(__FILE__), '/\\'));
define('DOMAIN', rtrim(rtrim($_SERVER['HTTP_HOST'], '/\\') . dirname($_SERVER['PHP_SELF']), '/\\'));

After this step you should be able to install Symphony CMS as you’re used to! The installation process will work now, but there is one more thing you have to adjust. Symphony CMS utilizes the mod_rewrite engine if installed on an Apache web server. The IIS 7.0 pendant to that is called URL Rewrite Module. You’re gonna have to download and install this to get Symphony running. With the Rewrite Module installed you finally need to set up the rules equally to the mod_rewrite rules defined in the .htaccess files. The relevant portion of the web.config file in the root of your website should look like this:

<rewrite>
<rules>
<rule name="Favicon Rule Stopper" stopProcessing="true">
<match url="favicon.ico$" />
<conditions logicalGrouping="MatchAll" />
</rule>
<rule name="Image Rule" stopProcessing="true">
<match url="^image\/(.+\.(jpg|gif|jpeg|png|bmp))$" />
<conditions logicalGrouping="MatchAll" />
<action type="Rewrite" url="/extensions/jit_image_manipulation/lib/image.php?param={R:1}" appendQueryString="false" />
</rule>
<rule name="Add Trailing Slash" stopProcessing="true">
<match url="^(.*)$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{URL}" negate="true" pattern="/$" ignoreCase="false" />
<add input="{URL}" negate="true" pattern="(.*)/$" ignoreCase="false" />
</conditions>
<action type="Redirect" url="/{R:1}/" redirectType="Permanent" />
</rule>
<rule name="Main Rewrite" stopProcessing="true">
<match url="^(.*)\/$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="/index.php?page={R:1}&amp;{QUERY_STRING}" appendQueryString="false" />
</rule>
</rules>
</rewrite>

The folder /symphony needs separate rewrite rules. Set up a new web.config file there and set the rewrite-section to

<rewrite>
<rules>
<remove name="Add Trailing Slash" />
<remove name="Main Rewrite" />
<remove name="Image Rule" />
<rule name="Main Rewrite" stopProcessing="true">
<match url="^(.*)\/$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="/symphony/index.php?page={R:1}&amp;{QUERY_STRING}" appendQueryString="false" />
</rule>
<rule name="Add Trailing Slash" stopProcessing="true">
<match url="^(.*)$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{URL}" negate="true" pattern="/symphony$" ignoreCase="false" />
<add input="{URL}" negate="true" pattern="(.*)/$" ignoreCase="false" />
</conditions>
<action type="Redirect" url="/symphony/{R:1}/" redirectType="Permanent" />
</rule>
</rules>
</rewrite>

So this really was the last step and your installation of Symphony CMS on IIS 7.0 should be up and running!

In this case, I used the latest release of Symphony, which has the version number 2.0.2. I hope I could help some of you out there.

]]> http://mrvirtual.de/2009/05/29/installing-symphony-cms-on-iis-70/feed/ 247