UrlRewriting.Net 模块 + IIS7 等于 Page.User == null？
我已经使用 UrlRewriting.Net 模块几年了，在 Windows XP 和 Windows 2003 中没有任何问题。我最近刚刚将我的家用 PC 升级到 Windows 7 并开始开发一个新网站。
计划是使用 .html 扩展名，并使用 UrlRewriting.Net 模块将其重写为 .aspx 扩展名。 在 VWD 2008 中一切工作都完美无缺，但是当我尝试通过 IIS7 运行它时，情况就不同了。
当我尝试通过 .html 重写访问页面时，我无法再访问 Page.User；它不断返回 null。如果我使用 .aspx 扩展名访问该页面，则 Page.User 会正确填充。我还应该提到，我的母版页中有一个 LoginView 控制器，它具有相同的症状：通过 .html 扩展名访问时，它显示 AnonyousTemplate；使用 .aspx 扩展名时，它可以正确显示 LoggedInTemplate。我猜这两者是相关的。
[注意：我也尝试过无扩展名 URL，它们也出现了同样的问题]
我让它工作的唯一方法是将应用程序池切换到经典，然后需要我为该应用程序添加 ASP.Net ddl 处理程序.html 扩展名 [否则由 StaticFileHandler 处理并出现 404 错误]。但是，我希望我的 Web 应用程序能够为人们正常运行，而不必摆弄 IIS。
所以我留下了几个问题：
- 有谁知道为什么 Page.User 对于 .html 总是等于 null => .aspx 重写页面？
- 为什么它可以在 VWD 2008 中运行，但不能在 IIS7 中运行？
- IIS6 发生了什么变化=> IIS7可能导致此问题？
- 关于解决方法还有其他想法吗？
[注意：我刚刚尝试了 .aspx => .aspx 重写并没有出现问题。不是我真正想要的，但我想我应该提一下。]
I've used the UrlRewriting.Net module for a couple years now without any problems in Windows XP and Windows 2003. I just recently upgraded my home PC to Windows 7 and started developing a new website.
The plan was to use .html extensions and rewrite them to their .aspx counterparts using the UrlRewriting.Net module. Everything works flawlessly in VWD 2008, but when I try running it through IIS7 it is a different story.
When I try to access a page via the .html rewrite I can no longer access Page.User; it keeps returning null. If I hit the page using it's .aspx extension, Page.User is correctly populated. I should also mention that I have a LoginView controller in my Master Page and it suffers from the same symptoms: When accessing via .html extension it shows the AnonyousTemplate; When using .aspx extension it properly shows the LoggedInTemplate. I'm guessing the two are related.
[Note: I've also tried extensionless URLs and they exhibit the same problem]
The only way I've gotten it to work is to switch the application pool to Classic, which then requires me to add an ASP.Net ddl handler for the .html extension [otherwise it is handled by the StaticFileHandler and comes up as a 404 error]. However, I'd like my web app to run properly for people without having to fiddle around with IIS.
So I am left with several questions:
- Does anyone have ideas as to why Page.User always equals null for .html => .aspx rewritten pages?
- Why does it work in VWD 2008, but not IIS7?
- What changed from IIS6 => IIS7 that could have caused this?
- Any other thoughts on workarounds?
[Note: I just tried a .aspx => .aspx rewrite and it did not exhibit the problem. Not really what I want, but thought I should mention it.]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
刚刚在 UrlRewriting.Net 模块上取得了突破。这使得它可以在 IIS7 中的集成模式下工作：
弄清楚后，我对“runAllManagedModulesForAllRequests”进行了搜索，弹出的第一件事是 斯科特·格思里的博客 实际上讨论了将其用于此目的。
Just had a breakthrough with the UrlRewriting.Net module. This makes it work in Integrated Mode in IIS7:
<modules runAllManagedModulesForAllRequests="true">After figuring it out I did a search on "runAllManagedModulesForAllRequests" and the first thing that popped up was Scott Guthrie's blog which actually talks about using it for this purpose.
另一种似乎有效的方法是删除 Session 模块并重新添加它，而不选中“仅针对对 ASP.NET 应用程序或托管处理程序的请求调用”复选框。它在 web.config 文件中看起来像这样：
问题似乎是，当使用 HttpContext.RewritePath 时，会话模块不会执行“*.htm”文件，但是以这种方式删除和读取模块会导致针对请求执行的会话处理程序。
下面的线程中建议了该解决方案。不幸的是，微软选择不完全解释此行为背后的原因：
http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7
Another approach that seems to work is to remove the Session module and readd it leaving the "Invoke only for requests to ASP.NET applications or managed handlers" checkbox unchecked. It looks like this in the web.config file:
It seems the problem is that the Session module doesn't execute for say '*.htm' files when HttpContext.RewritePath is used, but removing and readding the module in this fashion causes the Session handler to be executed for the request.
This solution was suggested on the thread below. Unfortunately Microsoft chose not to explain the reasoning behind this behavior fully:
http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7
Microsoft 在 Win7 和 Windows Server 2008 R2 的 Service Pack 1 中修复了此问题（至少对于无扩展名的 URL）：
http://www.microsoft.com/download/en/details.aspx ?id=5842
也可以作为修补程序提供：http://support.microsoft.com/kb /980368
应用 SP1 或修补程序后，无需更改 web.config 即可使会话和表单身份验证适用于重写为 asp.net 页面/处理程序/等的无扩展 URL。
我不知道这是否可以解决重写静态文件扩展名（如 .htm）的问题。我的猜测是，可能不会。我会尽量避免在生产环境中设置 runAllManagedModulesForAllRequests="true" ，因为它会增加静态文件请求不必要的开销。
Microsoft included a fix for this issue (at least for extensionless urls) in Service Pack 1 for Win7 and Windows Server 2008 R2:
http://www.microsoft.com/download/en/details.aspx?id=5842
Also available as a hotfix: http://support.microsoft.com/kb/980368
After applying SP1 or the hotfix, no web.config changes are needed to make the session and forms auth work for extensionless URLs rewritten to asp.net pages/handlers/etc.
I don't know if this fixes anything for rewrites to static file extensions like .htm. My guess is, probably not. I would try to avoid setting runAllManagedModulesForAllRequests="true" in production environments, because it adds unnecessary overhead on static file requests.