IIS7 URL Rewrite returns 404 for WCF requests (reverse proxy)

Question

I am using IIS7.5, .net 4.0. I am working locally.

I have installed Application Request Routing, Web Farm Framework, WebDeploy and UrlRewrite to set up a reverse proxy. This works fine for the most part.

I have two websites:

• DefaultWebSite (port 80, app pool: Default App Pool (.net 4)) and
• Target (port 8085, app pool: TargetAppPool(my identity, .net 4)).

I have a rewrite rule on DefaultWebSite (created as directed on IIS.net) which redirects all localhost (port 80) traffic to localhost:8085 just as detailed in the above link. This works fine for most document types (.aspx, .xap, .htm, .ico) but a request to MyService.svc fails. It returns a 404.

To be clear:

When I paste localhost:8085/MyService.svc into a browser I get the requested WCF page.

When I paste localhost/MyService.svc into a browser I get a 404.

When I paste localhost:8085/MyIcon.ico into a browser I get the requested resource.

When I paste localhost/MyIcon.ico into a browser I get the requested resource.

.svc is the only document type that I've found that returns a 404.

I've got two pieces of info that might be of relevance.

1. App Pools. When I change the DefaultWebSite's app pool to TargetAppPool then the 404 becomes a 500 ("Failed to map the path '/'"). All other requests are successful when this change is made. Not sure if this relevant or not.

2. FREB (Failed Request Tracing) Log. I found a page (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx) which details the steps in a FREB log when a URL rewrite is more successful than mine (it fails later on). I've not been able to find out how to generate a FREB log for a successful rewrite (if that's possible) so I can only compare my FREB log to the one on that blog. I can see that their step 21 (URL_CHANGED) in my FREB log but not 22 (URL_REWRITE_END). I've not got enough experience with these logs to notice anything more significant than that (suggestions welcomed).

My main question is: does anyone know why just URLs requesting .svc resources are not being rewritten?

A secondary question is: does anyone know how to generate a FREB log for successful request (if it's even possible)?

Thanks

Update:

I have changed the architecture to try to get more info.

I have moved the Target website to a different PC on which I have installed Microsoft Network Monitor to capture the incoming traffic.

Before I changed the url-rewrite rule to point at this new website I got the correct response when I made a request to MyService.svc on the new PC. Fine.

As soon as I changed the rewrite rule to route the request to the new Target website then it responds as before (404). I have made both POST and GET requests. There is no sign of any of the requests in the Network Monitor log (all other calls -200, 404 or otherwise- appear in this log).

This leads me to think that there is something incompatible with url-rewrites and *.svc requests. I tried making a request to MyService.asmx (having created this file) and it correctly returned a page, so it is limited to *.svc. Any ideas?

Answer 1

The solution to this is in the config file of the Target web site.

In web.config (in the Target application) there is a section which read:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>.

I changed this to read:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />.

Credit must go to http://forums.iis.net/post/1956671.aspx for this (although s/he claims it is the proxy's config which needs to be changed, but I found it be the Target app, not the proxy server).

Answer 2

If you still can't get it running, make sure you don't have the WCF handlers on the website which acts as the reverse proxy. I disabled this by adding this web.config of the reverse proxy:

 <system.webServer>    
  ...
 <handlers>
  <remove name="svc-ISAPI-4.0_64bit" />
  <remove name="svc-ISAPI-4.0_32bit" />
  <remove name="svc-Integrated-4.0" />
 </handlers>
</system.webServer>

Answer 3

Because the rewrite appears to work for all resources except when the extension is .svc I would say this would be the area to concentrate on.

I would imagine that the rewrite rules are matching your other resources, but not your service, and because these are usually regular expressions (which are often complicated) I would say it would be worth testing any rules you find with your urls. Details of how to find the regular expressions for an UrlRewrite can be found here.

It is also probably also worth looking at any outbound rules with the same mindset.