正在阅读：无 Cookie 的 ASP.NET无 Cookie 的 ASP.NET

2005-08-01 10:15 出处：作者：Dino Esposito 责任编辑：moningfeng

　　当不使用 Cookie 时，ASP.NET 在哪里存储会话 ID 呢？在这种情况下，会话 ID 插入到 URL 内的特定位置中。下图显示一个使用无 Cookie 会话的真实站点的快照。

图 1. 使用无 Cookie 会话的 MapPoint

　　假设您请求了一个类似于 http://yourserver/folder/default.aspx 的页。正如您可以从 MapPoint 快照中看到的那样，资源名称前面的相邻斜杠进行了扩展，以便包含在内部填充了会话 ID 的括号，如下所示。

　　http://yourserver/folder/(session ID here)/default.aspx

　　会话 ID 嵌入到 URL 中，并且无需在其他任何地方持久保存它。唔，并不完全是这样。请考虑以下方案。

　　您访问了一个页，并且被分配了一个会话 ID。接下来，您清除了同一浏览器示例的地址栏，转到另一个应用程序并且开始工作。然后，您重新键入了上一个应用程序的 URL，并且（猜猜看）在您进入的过程中检索会话值。

　　如果您使用无 Cookie 会话，那么当您第二次访问该应用程序时，您将被分配一个不同的会话 ID，并且丢失以前的所有状态。这是无 Cookie 会话的一个典型的副作用。为了了解其原因，让我们进一步探讨无 Cookie 会话的实现。

　　实现
　　无Cookie会话的实现得益于下列两个运行时模块的努力:一个名为SessionStateModule的标准会话 HTTP 模块，以及一个名为 aspnet_filter.dll 的可执行文件。后者是一小段 Win32 代码，它充当 ISAPI 筛选器。HTTP 模块和 ISAPI 筛选器实现了相同的思想，不同之处在于 HTTP 模块由托管代码组成，并且需要 ASP.NET 和 CLR 触发才能工作。像 aspnet_filter.dll 这样的传统 ISAPI 筛选器是由 Internet 信息服务 (IIS) 调用的。二者都截获在请求处理过程中激发的 IIS 事件。

　　当新浏览器会话的第一个请求进入时，会话状态模块读取 web.config 文件中有关 Cookie 支持的设置。如果节的 cookieless 属性设置为 true，则该模块生成一个新的会话 ID，通过将该会话 ID 填充到资源名称前面的相邻位置来分割 URL，并且使用 HTTP 302 命令将浏览器重定向到新的 URL。
　　当每个请求到达 IIS 入口时（远远早于它被移交给 ASP.NET），aspnet_filter.dll 获得了一个查看它的机会。如果该 URL 将会话 ID 嵌入到括号中，则会提取该会话 ID 并将其复制到一个名为 AspFilterSessionId 的请求标头中。然后，重写该 URL 以使其看起来像原来请求的资源，并且将其释放。这一次，ASP.NET 会话状态模块从请求标头中检索会话 ID，并且通过会话-状态绑定继续工作。

　　只要该 URL 包含可用来获取会话 ID 的信息，无 Cookie 机制就可以很好地工作。正如您稍后将看到的那样，这会造成一些使用限制。

　　让我们研究一下无 Cookie 会话的优缺点。