我在web.config中设置了404处理程序页面，但只有在URL扩展名是.aspx(或者其他由ASP.NET处理的)时，它才起作用。
我知道我可以在网站选项中设置静态HTML页面，但是我想要一个页面。
是否有任何选项可以为IIS中的所有请求扩展分配ASPX处理程序页面？

解决方案

web.config只能为其网站控制的页面设置错误页面。如果我们在ASP.Net应用程序的权限范围之外还有其他页面，则可以在IIS中设置它们的处理方式。那里有一个配置404页面的选项，我们可以将其指向自定义页面。

我能想到的其他事情就是将所有扩展名都传递给asp.net。

这样，asp.net会处理所有类型的文件，并且自定义错误页面将起作用。

在IIS应用程序配置中，可以将通配符映射(。*)设置为C：\ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ aspnet_isapi.dll

直接的问题是是否有将ASPX处理程序分配给所有请求扩展的选项：是的。我将在短期内讨论如何做到这一点。

首先，我认为"隐藏"问题(我们真正想要的答案)是，是否有一种方法可以重定向ASPX，ASMX等页面以外的所有404错误。是的，如果有的话，这是更好的选择它将解决我们遇到的问题。

要重定向IIS 6中的所有404，请右键单击Web应用程序根目录(无论是其自己的站点还是主站点中的虚拟目录)，然后选择"属性"。从那里，选择"自定义错误"选项卡。在列表中找到404，并将其更改为所需的重定向。

现在，如果那还不够-我真的希望它能-是的，我们可以通过ASPX处理程序运行每个页面。但是，这样做会在效率方面付出相当高的代价-原始HTML /图像服务比任何动态方法都快得多。

为此，请右键单击Web应用程序根目录，然后选择"属性"。选择"主目录"选项卡。点击"配置；"将会弹出一个新窗口。从ASP.NET页之一提供的路径中复制路径，然后将其用于通配符应用程序映射。

再次提醒我们，多数情况下，这是错误的答案。这将对性能产​​生负面影响，相当于使用电锯雕刻火鸡。如果可以，我强烈建议我们选择第一个选项。

有关信息：

这是IIS7通过处理程序路由所有页面的几件好事之一，这样我们就可以执行自定义404并为任何文件提供目录和文件级安全性(基于与asp.net文件相同的web.config内容) IIS7之前)。

因此，从概念上讲，"使用II7"是一个答案(即及时的"答案")，但是，如果我们不托管/不托管在W2k8(或者更高版本)上，那么它当然不是一个非常实用的答案。

• 我们可以在IIS中设置通配符映射(应用程序配置/映射/通配符映射/-只需将aspnet_isapi.dll设置为可执行文件，然后取消选中"确认文件存在"框)即可将所有传入请求路由到应用程序-因此我们可以控制行为直接从它。
• 我们无需在IIS应用程序设置中设置静态页面。恕我直言，我们应该能够从应用中设置有效的网址(例如/error_handler.aspx)，如果发生特定的服务器错误，该网址将用作着陆页。