asp.net - 为什么/何时 session 写入容易受到线程终止的影响？

Question

代码:

Session["foo"] = "bar";  
Response.Redirect("foo.aspx");

问题:

当 foo.aspx 从 session 中读取“foo”时，它不存在。 session 在那里，但“foo”没有任何值(value)。

我在我们的生产环境中间歇性地观察到这一点。但我不是在这里问 a question about Response.Redirect() .

解释:

Bertrand Le Roy解释(粗体字是我的):

Now, what Redirect does is to send a special header to the client so that it asks the server for a different page than the one it was waiting for. Server-side, after sending this header, Redirect ends the response. This is a very violent thing to do. Response.End actually stops the execution of the page wherever it is using a ThreadAbortException. What happens really here is that the session token gets lost in the battle.

我的收获是 Response.Redirect() 可以通过结束线程来处理。如果它们发生得太接近那种严厉，那可能会威胁到我的 session 写作。

问题:

ASP.NET session 管理如何使它如此容易受到此攻击？ Response.Redirect() 代码行直到 session 写入行“完成”才开始执行——它怎么会对我的 session 写入造成如此大的威胁？

在下一行代码执行之前 session 写入没有“完成”怎么办？是否存在 session 写入类似(好像从未发生过)丢失的其他场景？

Answer 1

我对 session 编写的内部结构不够熟悉，但我想它有一些复杂性，因为它依赖于将浏览器 session cookie 转换为服务器标识。此外，ThreadAbortExceptions do have special considerations在运行时，可能会在这里播放，我不确定。

无论如何，Response.Redirect()有一个带 bool 参数的重载，可让您指定是否要结束线程。

Response.Redirect(string url,  bool endResponse);

如果您在 endResponse 设置为“false”的情况下调用它，它将优雅地完成，而不是调用 Thread.Abort()内部。但是，这意味着它还将在完成之前执行页面生命周期中剩余的任何代码。

一个不错的折衷办法是调用 Response.Redirect(url, false)后跟 Application.CompleteRequest() .这将允许您的重定向发生，但也可以通过最少的额外生命周期处理优雅地关闭当前执行上下文。