有没有办法配置 IIS 7.5 以对同一站点上的不同应用程序池执行 URL 重写而不会遇到 403.18 错误？
我们在 IIS 6 上使用 Helicon ISAPI Rewrite 3，它运行良好。根级“应用程序”在其自己的应用程序池下运行，在 IIS 6 上，我们可以毫无问题地从该应用程序池向其他四个应用程序池中的任何一个执行 URL 重写。但是，当我将相同的服务器配置信息复制到 IIS 7.5 时，对任何其他应用程序池的 URL 重写都会失败，并出现“403.18 - 禁止”错误。
奇怪的是，IIS 6 不是（至少据我所知，通过查看站点服务配置对话框）在 IIS 5 仿真模式下运行，所以重写不会抛出 403.18 错误。所以某物肯定有所不同...但无论是什么，我实在没法弄清楚。
顺便说一句，我们并没有完全依赖 Helicon ISAPI Rewrite。如果有其他方法可以使用其他模块或方法来保留我们当前的重写配置规则，我会非常乐意使用它。
答案1
在 IIS 中，您无法直接将请求从一个应用程序路由到另一个应用程序。应用程序是隔离的，这就是您收到 403 错误的原因。
您可以使用 ISAPI_Rewrite、Ape 或 ARR 代理请求 - 这并不重要，因为请求无论如何都会使用本地 HTTP 请求传递给另一个应用程序。此解决方案非常稳定，但您会损失一些性能。
重定向在这里可能不是一个选项，因为无论如何它都会向服务器生成两个请求，但是由于请求是由连接速度较慢的用户生成的，因此性能可能会显著下降。
答案2
IIS7 也不支持微软新推出的 URL Rewrite 组件。会出现同样的问题。
我不记得在 IIS6 中可以跨应用程序池进行重写。您正在进行重写而不是重定向？重定向在 IIS7 中可以工作。
我会询问 Helicon，网址为 www.isapirewrite.com。他们在论坛上回复得很好。可能 ISAPI 模块现在完全存在于 w3wp.exe 进程中，因此无法将其请求转交给另一个应用程序池。
另一个可以提问的地方是http://forums.iis.net/。IIS 开发团队回复了一些帖子，他们可能会提供有关为什么在迁移到 IIS7 时 ISAPI Rewrite 的功能也发生了变化的详细信息。
答案3
事实上，这在 URL 重写中是无法实现的，但是如果您真的想这样做，您可以结合使用 ARR（应用程序请求路由），这样它就可以工作了，但请注意，它实际上会为其执行一个全新的请求，换句话说，它将作为一个代理向其自身发出一个新的 HTTP 请求，为此您需要重写以使用包括主机名和所有内容在内的完整 URL。这是一个很大的开销，因此仅当对应用程序至关重要时才这样做。
当然，正如斯科特·福赛斯 (Scott Forsyth) 所提到的，另一种选择是使用重定向。
答案4
这是我发现的最接近 IIS 的 mod_rewrite 的东西。