MRVirtual » ISA Server 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/ 34