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>