IIS 7 不提供默认文档
我们的一些开发人员工作站上出现了问题:访问没有文件名的 URL 时(例如 http://localhost/),IIS 7 返回 404 错误。每个人都在运行 Windows 7/IIS 7.5 和 ASP.NET 4.0。应用程序池配置为使用经典管道模式。
默认文档已启用,default.aspx 位于默认文档列表中。
我启用了失败的请求跟踪,并在日志中看到以下内容:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit",
NewHandlerModules="IsapiModule",
NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
稍后,我看到此 IsapiModule 拒绝了请求:
ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="404",
HttpReason="Not Found", HttpSubStatus="0",
ErrorCode="The operation completed successfully. (0x0)", ConfigExceptionInfo=""
看起来 IIS 认为 ExtensionlessUrl-ISAPI-4.0-64bit 应该处理该请求。当我查看该模块的配置时,它显示它应该匹配路径 *.
,所以我很困惑为什么它不匹配任何路径。
通过 Google 搜索,可以找到 2005 年IIS.net 论坛上的这篇帖子。遗憾的是,没有找到提供了解决方案,只是承认问题。
当我更新应用程序池以使用集成模式时,问题就消失了。不幸的是,它必须在经典模式下运行。
我该怎么做才能让 IIS 再次为我们的默认文档提供服务器?
We have a problem occuring on some of our developer workstations: when visiting a URL without a filename (e.g. http://localhost/), IIS 7 returns a 404 error. Everyone is running Windows 7/IIS 7.5 and ASP.NET 4.0. The application pool is configured to use Classic pipeline mode.
Default documents are enabled, and default.aspx is in the default document list.
I enabled failed request tracing, and see this in the log:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit",
NewHandlerModules="IsapiModule",
NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Later on, I see that this IsapiModule is rejecting the request:
ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="404",
HttpReason="Not Found", HttpSubStatus="0",
ErrorCode="The operation completed successfully. (0x0)", ConfigExceptionInfo=""
It looks like IIS thinks the ExtensionlessUrl-ISAPI-4.0-64bit should be handling the request. When I look at that module's configuration, it shows that it should be matching path *.
, so I'm confused why it is matching no path.
A Google search turns up this post on the IIS.net forums from 2005. Unfortunately, no solutions are offered, just an acknowledgement of the problem.
When I update my app pool to use integrated mode, the problem goes away. Unfortunately, it has to run in Classic mode.
What can I do to get IIS to server our default documents again?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
Microsoft 似乎发布了一个更新,使 ExtensionlessURL HTTP 处理程序能够处理无扩展 URL。不幸的是,这会破坏某些其他处理程序。就我而言,是经典应用程序池下的 DefaultDocument 处理程序。解决方案是删除应用程序 web.config 中的 ExtensionlessURL 处理程序:
It looks like Microsoft released an update that enables the ExtensionlessURL HTTP handler to work with extensionless URLs. Unfortunately, this breaks certain other handlers. In my case, the DefaultDocument handler under classic app pools. The solution is to remove the ExtensionlessURL handlers in our application's web.config:
我通过将 HandlerMapping 中的“StaticFile”处理程序放在“ExtensionlessUrlHandler-*”前面解决了问题
I solved the problem with putting the "StaticFile" handler in HandlerMapping in front of "ExtensionlessUrlHandler-*"
我注意到,当从应用程序池中删除托管 .NET 框架 (4.0) 时,它也解决了我的问题!
我们在 IIS 环境中根本不使用 .NET!
I noticed when removing the managed .NET framework (4.0) from the application pool, it fixed the problem for me too!
We don't use .NET at all in our IIS environment!
我在 web.config URL 重定向中使用以下规则作为解决方法来解决此问题:
I use the following rule in web.config URL Redirect as workaround to solve this:
当将默认文档设置为 IIS 中的网站应用程序时,更改 StaticFile 顺序有助于解决该问题,而根网站还有另一个默认文档。
Changing the StaticFile order helped to fix the issue, when setting default document to a web site application in IIS, while the root website also had another default document.
在添加/删除 Windows 功能中将 DefaultDocument 组件添加到 IIS,然后插入我的默认脚本 (index.php) 的名称对我来说很有效。
Adding the DefaultDocument component to IIS in add/remove windows features and then inserting the name of my default script ( index.php) worked for me.