Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a rewrite rule responding with a 301 redirect but I don't know why.

I'm on WinHost shared hosting, using IIS 7 rewrite to host another domain I own from a subfolder of my account.

By default, WinHost points your other domains at the root of your account. So my goal is two-fold:

  1. I want to keep this other domains files physically separate in a subfolder
  2. I want to hide said subfolder from the address bar

So that:

Gets served from:


So using the IIS 7 rewrite module, I generated this rule.

<xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="Test" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTP_HOST}" pattern="(^|\.)myotherdomain\.com$" /> </conditions> <action type="Rewrite" url="myotherdomain/{R:1}" /> </rule> </rules> </rewrite> </system.webServer> </configuration>

I want requests for to offset into the myotherdomain subfolder.

This is working, but only if no paths are in the request. If I request I receive a 200 response & in my browser I see the default document located at E:\account_root\myotherdomain. No redirection occurs.

If you add a path to the request, e.g., now I receive a 301 redirect to the rewritten URL:

Response: HTTP/1.1 301 Moved Permanently


Which the browser then GETs:

Request: GET /myotherdomain/test/ HTTP/1.1

The rewrite rule then runs on IIS again, and ultimately IIS attempts to serve the default document located at:


Which doesn't exist:

Response: HTTP/1.1 404 Not Found

So the rewrite itself appears to be working; what I don't understand is why IIS is throwing a 301 redirect into the mix, but only when there is a path present in the request.

share|improve this question
up vote 1 down vote accepted

Isn't it redirecting to add the trailing / ?

share|improve this answer
Sounds likely. Not from that particular rule, but something else is causing the redirect. It's also possible that it's from WinHost's rules. – Scott Forsyth - MVP Apr 17 '11 at 0:31
I don't see what you mean yet but I'm new at this so I know I'm vulnerable to stupid mistakes like trailing slashes. Can you point out where exactly the trailing / is coming into play & why it's causing a redirect? – with Apr 17 '11 at 1:11
must be right. I added the rewrite module's canned "force trailing slash" redirect rule at the top of my rule list, and that eliminated the strange behaviors. I think there is something about the rule I posted which breaks when given non-slash terminated input from the browser. – with Apr 17 '11 at 14:54
Sounds to me like WinHost is adding the slash for you, so since you're doing it yourself with this other rule, you have more control and it works properly. Another thing to check is if you have a rule in the root of the site. web.config inherits down the folder tree so rules in your site's root web.config will take effect in your subfolder. In any case, glad you got a good working solution. Adding the trailing slash is good to do regardless. – Scott Forsyth - MVP Apr 17 '11 at 17:37

Your rule looks correct, and is does rewrite rather than a redirect, as you assumed. It sounds to me like something else in your site is causing the 301 client-side redirect. Try testing a .htm page to see if it's aspx or htm that is performing the redirect. Your URL Rewrite rule won't cause that.

You're on the right track. I have a couple blog posts on this situation, including the outgoing rules:

share|improve this answer
I know it's not coming from my content since I'm just using dead simple test html pages (site has no content yet, getting this hammered out first). Might be something hidden WinHost is doing, I was hoping it was just newbie error on my part. – with Apr 17 '11 at 1:12
Nah, you did it right. I would check with WinHost and see if it's from them. In fact Fiddler or Firebug may give some clues where the redirect is coming from. What you can do is to catch their redirect and then redirect it back again, unless their setup fights with you too much. I can't quite imagine what setup they would have which would cause this particular redirect. You can disable your rewrite rule to troubleshoot further. You should be able to find URLs that redirect, even with your rule disabled. – Scott Forsyth - MVP Apr 17 '11 at 5:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.