IIS7 URL 重写为 WCF 请求返回 404（反向代理）答案

【问题标题】：IIS7 URL Rewrite returns 404 for WCF requests (reverse proxy)IIS7 URL 重写为 WCF 请求返回 404（反向代理）
【发布时间】：2013-10-10 02:01:54
【问题描述】：

我正在使用 IIS7.5、.net 4.0。我在本地工作。

我已经安装了 Application Request Routing、Web Farm Framework、WebDeploy 和 UrlRewrite 来设置反向代理。这在大多数情况下都可以正常工作。

我有两个网站：

DefaultWebSite（端口 80，应用程序池：默认应用程序池 (.net 4)）和
目标（端口 8085，应用程序池：TargetAppPool（我的身份，.net 4））。

我在 DefaultWebSite 上有一个重写规则（根据 IIS.net 的指示创建），它将所有 localhost（端口 80）流量重定向到 localhost:8085，正如上面链接中详述的那样。这适用于大多数文档类型（.aspx、.xap、.htm、.ico），但对 MyService.svc 的请求失败。它返回 404。

要明确：

当我将 localhost:8085/MyService.svc 粘贴到浏览器中时，我得到了请求的 WCF 页面。

当我将 localhost/MyService.svc 粘贴到浏览器中时，我得到了 404。

当我将 localhost:8085/MyIcon.ico 粘贴到浏览器中时，我得到了请求的资源。

当我将 localhost/MyIcon.ico 粘贴到浏览器中时，我得到了请求的资源。

.svc 是我发现的唯一返回 404 的文档类型。

我有两条可能相关的信息。

应用程序池。当我将 DefaultWebSite 的应用程序池更改为 TargetAppPool 时，404 变为 500（“无法映射路径'/'”）。进行此更改时，所有其他请求均成功。不确定这是否相关。
FREB（失败的请求跟踪）日志。我找到了一个页面 (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx)，它详细说明了当 URL 重写比我的更成功时（稍后会失败）时 FREB 日志中的步骤。我无法找到如何生成 FREB 日志以成功重写（如果可能的话），所以我只能将我的 FREB 日志与该博客上的日志进行比较。我可以在我的 FREB 日志中看到他们的第 21 步（URL_CHANGED），但不是第 22 步（URL_REWRITE_END）。我对这些日志没有足够的经验，无法注意到比这更重要的事情（欢迎提出建议）。

我的主要问题是：有谁知道为什么不重写请求 .svc 资源的 URL？

第二个问题是：有谁知道如何为成功的请求生成 FREB 日志（如果可能的话）？

谢谢

更新：

我已更改架构以尝试获取更多信息。

我已将 Target 网站移至另一台安装了 Microsoft Network Monitor 以捕获传入流量的 PC。

在我更改 url-rewrite 规则以指向这个新网站之前，当我在新 PC 上向 MyService.svc 发出请求时，我得到了正确的响应。很好。

只要我更改了重写规则以将请求路由到新的 Target 网站，它就会像以前一样响应 (404)。我已经发出了 POST 和 GET 请求。网络监视器日志中没有任何请求的迹象（所有其他调用 -200、404 或其他 - 出现在此日志中）。

这让我觉得有些东西与 url-rewrites 和 *.svc 请求不兼容。我尝试向 MyService.asmx 发出请求（已创建此文件）并且它正确返回了一个页面，因此它仅限于 *.svc。有什么想法吗？

【问题讨论】：

标签： c# wcf iis iis-7 url-rewriting

【解决方案1】：

解决方案在目标网站的配置文件中。

在 web.config（在目标应用程序中）有一段内容如下：

<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>.

我把它改成了：

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

为此，信用必须转到http://forums.iis.net/post/1956671.aspx（尽管他/她声称这是代理的配置需要更改，但我发现它是目标应用程序，而不是代理服务器）。

【讨论】：

我遇到了同样的问题，我使用我的端口 80 网站将 Web 服务请求代理到另一个端口。应用此更改修复它。谢谢！
我也改为代理配置。目标站点中没有 multipleSiteBindingsEnabled="true" 仍然可以正常工作。

【解决方案2】：

如果仍然无法运行，请确保网站上没有充当反向代理的 WCF 处理程序。我通过添加反向代理的这个 web.config 禁用了它：

 <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>

【讨论】：

这是正确的解决方案。此外，如果您不需要托管代码在反向代理的网站中运行，您需要禁用该应用程序池的托管代码并删除所有 ISAPI 处理程序。
如果您无法删除处理程序（例如，从子应用程序提供服务），您可以创建一个没有托管代码的应用程序池，按照我在此处的回答：stackoverflow.com/a/52972294/195395

【解决方案3】：

因为当扩展名是 .svc 时，重写似乎适用于所有资源除了，我想说这将是重点关注的领域。

我想rewrite rules 与您的其他资源匹配，但与您的服务不匹配，因为这些通常是regular expressions（通常很复杂），我会说值得测试您发现的任何规则网址。有关如何查找 UrlRewrite can be found here 的正则表达式的详细信息。

可能还值得以相同的心态查看任何出站规则。

【讨论】：

当我最初发布时，重写规则上的正则表达式是默认的 (/.X)，所以我认为这不是问题。 [X=asterisk] 我所做的是更改重写规则，使其匹配 XMyService.X 的通配符模式（不是正则表达式）现在对 MyService.htm、MyService.aaa 和 MyService.zzz 的调用被重写为我设置的页面来测试规则。但是对 MyService.svc 的调用继续返回 404。有趣的是，对 DoesNotExist.htm 的调用（在新规则的范围之外）会返回不同样式的 404 页面（比 MyService.svc 显示的详细信息更多）。
stackoverflow.com/a/8957579/1412915 说“即使您要在 IIS 中添加 .SVC 处理程序并以与 .HTM 请求相同的方式重定向它，重定向也不会保留消息的正文. 因此，对 SiteB 上的服务方法的请求不一定与 SiteA 上的服务方法调用相同”。我已经问过那张海报，她/他是否有这方面的参考资料，因为这可以解释我所看到的。
您知道重定向是否通过 HTTP 302 完成吗？还是它们完全在服务器上处理（即对客户端透明）。如果正在使用 302，您将能够使用 Fiddler 查看实际的重定向，并能够验证正文是否实际上被篡改。
完全在服务器上。 Fiddler 在其输出中只有 404（除了在我的 OP 中更改 AppPool 时，此时它显示为 500）。