怀疑 IIS 6 中会话状态丢失
我有一个 ASP.NET 网站，它根据访问的域以多种外观进行响应。
问题在于身份验证和其他一些功能似乎会遇到随机故障，其中用户被发送回登录屏幕，或者其他会话控制值似乎已丢失 - 但仅当通过其中一个域访问时才发生。其他域不会遇到同样的问题。
在我们的测试系统上，通过任何域访问时都不存在问题。在实时情况下，即使遵循相同的步骤，该问题也会在会话期间的不同时间发生。正是由于这些原因，我不认为这是应用软件中的错误。
在问题所在的实时系统上，IIS 中设置了两个网站，每个网站都绑定到所需的域。一个通过 http://mysite.com/myvirtualdir 的虚拟目录访问该站点，另一个通过以下地址访问该站点： http://myalternatesite.com/ 的根路径。不过，我不认为虚拟目录是问题所在。
I have an ASP.NET web site that responds with multiple skins depending on the domain that it is accessed via.
The problem is that authentication and some other features seem to suffer random glitches where the user is sent back to the log in screen, or other session controlled values appear to have been lost - but only when accessed via one of the domains. The other domain does not suffer the same issue.
On our test system, the issues DOES NOT exist when accessing via any domain. On live, the issue will happen at varying times during the session, even with identical steps followed. It is for these reasons that I don't think it is a bug in the application software.
On the live system, where the issue is, two websites are set up in IIS, each with bindings to the required domain. One accesses the site through a virtual directory at http://mysite.com/myvirtualdir, the other accesses the site at the root path at http://myalternatesite.com/. I don't think that the virtual directory is the issue however.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我现在已经解决了我的问题，但仍然不确定确切的原因是什么。
我在 IIS 中打开了两个网站的网站属性，一个有效，一个无效，并比较了属性。
对于解决此问题的其他人，这些是我采取的步骤，按照我认为它们是问题原因的可能性排列。
第二个网站正在使用默认应用程序池。从我所看到的情况来看，该服务器上的默认应用程序池设置没有什么特别之处，会导致会话丢失，但我现在已更改为使用与一直运行的网站相同的应用程序池。
禁用 Windows 身份验证以匹配工作网站。
更改了默认文档，以便仅列出所需的文档。
连接数限制为 500 个，以匹配工作网站。
希望这对其他人有用。
I've now solved my problem, though still not sure what the exact cause was.
I opened up website properties for the two websites in IIS, the one that worked and the one that didn't and compared properties.
For anyone else trouble shooting this issue, these are the steps that I took, in order of how likely I think they were to be the cause of the issue.
Second website was using Default app pool. There is nothing particular about the Default app pool settings on this server that would cause session to be lost from what I can see, but I have now changed to use the same app pool as the site that was working all along.
Disabled windows authentication to match the working website.
Changed default documents so that only the required document was listed.
Limited connections to 500 to match the working website.
Hope this is of use to somebody else.