有什么办法可以configurationIIS 7.5来执行URL重写到同一站点上的不同应用程序池，而不会遇到403.18错误？
我们在IIS 6上使用Helicon ISAPI Rewrite 3，它像一个魅力。 根级“应用程序”在它自己的应用程序池下运行，在IIS 6上，我们没有任何问题从该应用程序池进行URL重写到其他四个应用程序池中的任何一个。 但是，当我将相同的服务器configuration信息复制到IIS 7.5时，URL将重写为任何其他应用程序池失败并出现“403.18 – 禁止”错误。
奇怪的是，在IIS 5模拟模式下运行的IIS 6并不是（至less据我所知，通过查看站点服务configuration对话框），所以重写不会抛出403.18错误。 所以有些东西肯定是不一样的，但是无论如何，我一定还没弄明白。
顺便说一下，我们没有结婚Helicon ISAPI重写。 如果还有另外一种方法来使用另一个模块或方法来保存我们当前的重写configuration规则，那么我将非常乐意使用它。
在IIS中，您不能将请求从一个应用程序路由到另一个应用程序。 应用程序是孤立的，这就是为什么你得到403错误。
您可以使用ISAPI_Rewrite，Ape或ARR来代理请求 – 这并不重要，因为无论如何，请求都将被传递给另一个使用本地HTTP请求的应用程序。 这个解决scheme是相当稳定的，但是你会失去一些性能。
redirect在这里可能不是一个选项，因为它会生成两个请求到服务器无论如何，但由于请求将由用户生成慢连接性能可能大大下降。
微软新的URL重写组件也不支持IIS7。 同样的问题发生。
我不记得在IIS6中可以跨应用程序池重写。 你正在重写而不是redirect？ redirect将在IIS7中工作。
我会问在www.isapirewrite.com Helicon。 他们在论坛上做出了很好的回应。 可能ISAPI模块现在完全处于w3wp.exe进程中，因此无法将请求交给另一个应用程序池。
其他地方要问这个问题将在http://forums.iis.net/ 。 IIS开发团队回复了一些post，他们可能提供了为什么即使ISAPI Rewrite的function改变，当移动到IIS7的细节。
事实上，对于URL重写来说，这是不可能的，但是如果你真的想这么做的话，你可以联合使用ARR（应用程序请求路由），但它会起作用，但是请注意，它实际上会对它做一个完整的新请求，换句话说，它将作为一个代理向自己发出一个新的HTTP请求，因为你需要重写使用完整的URL，包括主机名和全部。 这是一个很大的开销，所以只有在关键的应用程序。
当然，正如Scott Forsyth所提到的，另一种select是使用redirect。
我们还习惯在IIS6上使用ISAPI Rewrite 3，但是当我们转移到IIS7.5时，我们切换到了Helicon APE，并且它在Rewrite上运行得更好。 你可以使用数据库中的数据来重写url。
这是我发现接近于IIS的mod_rewrite最近的东西。