用户可以设置自己的浏览器拒绝接受 Cookie。如何才能知道您是否可以读写 Cookie？在不能写入 Cookie 时不会出现任何错误（例如 Response.Cookies 不会抛出异常），因为服务器并不跟踪呈现页面后出现的情况。浏览器同样不会向服务器发送任何有关其当前的 Cookie 设置的信息。（HttpBrowserCapabilities.Cookies Property [英文] 属性并不会告诉您 Cookie 是否被启用，而只能告诉您当前的浏览器是否支持 Cookie。）

　　一种确定浏览器是否接受 Cookie 的方法是先编写一个 Cookie，然后再尝试读取这个 Cookie。如果不能读取这个 Cookie，则可以认为该浏览器不接受 Cookie。

　下面通过一个简单的示例来说明如何测试 Cookie 是否被接受。
    该示例包含两个页面。
    在第一个页面中，我编写了一个 Cookie，然后把浏览器重新定向到第二个页面。
    第二个页面尝试读取这个 Cookie，转而将浏览器重新定向到第一个页面，并向 URL 添加一个带有测试结果的查询字符串变量。

第一个页面的代码：

第一个页面测试是否有回信，如果没有，就搜索包含测试结果的查询字符串变量 (AcceptsCookies)。如果没有找到查询字符串变量，则表示测试还没有完成，代码就写出一个名为“TestCookie”的 Cookie。写出 Cookie 之后，示例调用 Response.Redirect 来切换到测试页面 (TestForCookies.aspx)。附加到测试页面的 URL 的是名为 redirect 的查询字符串变量，该变量中包含了当前页面的 URL，这样就能在执行测试后把重定向到该页面。

测试页面可以完全由代码组成，不需要包含控件。
代码：

    读取 redirect 查询字符串变量后，代码就尝试读取 Cookie。为了实现日常管理，如果该 Cookie 确实存在，就会被立即删除。测试完成后，代码从 redirect 查询字符串变量传递的 URL 构造一个新的 URL。新的 URL 也包括一个包含测试结果的查询字符串变量。最后一步是使用新的 URL 将浏览器重定向到原来的页面。

　　以上示例说明：通过运行程序并查看结果来进行测试的基本原则。其中最需要改进的地方是要永久保存 Cookie 测试结果，这样用户就不必在每次浏览原始页面时都重复进行测试。但是，实际上并不能做到这一点。Cookie 不会起作用，原因是显而易见的。另一种可能是把测试结果保存在会话状态中，但在默认情况下，会话状态也依赖于 Cookie，而如果浏览器不接受 Cookie，会话状态也不会起作用。解决后一个问题的办法是采用无 Cookie 的会话状态。下一节我将简要介绍会话状态如何与 Cookie 协作。

　　Cookie 和会话状态

　　当用户访问您的站点时，服务器会为该用户创建唯一的会话，会话将一直延续到用户访问结束。对于每个会话，ASP.NET 都维护一种基于服务器的结构（会话状态），在该结构中应用程序可以保存用户的相关信息。有关详细信息，请参阅 Session State（英文）。

　　ASP.NET 需要能跟踪每个用户的会话 ID，这样才能把用户映射到服务器上的会话状态信息。默认情况下，ASP.NET 使用一个非永久性的 Cookie 来保存会话状态。如果您使用读取 Cookie 一节的“读取 Cookie 集合”中的示例，您可能就会在 Cookie 中发现一个会话状态 Cookie。

　　但是如果用户禁用了浏览器的 Cookie，会话状态就不能使用 Cookie 来保存会话 ID，会话状态也不会起作用。这就是为什么我在前面的检查浏览器是否接受 Cookie 中说，无法在 Cookie 测试完毕后把测试结果实际保存在会话状态中，因为没有 Cookie 就没有会话状态。

　　ASP.NET 提供了一种解决方案，即利用无 Cookie 的会话。您可以配置自己的应用程序，不在 Cookie 中保存会话 ID，而是在站点页面的 URL 中保存。会话 ID 保存在 URL 中，也就是 ASP.NET 将 ID 保存在浏览器中，从而能够在用户请求其他页面时取回 ID。

　　无 Cookie 会话可以避免浏览器拒绝 Cookie 的问题，使您能够使用会话状态。如果您的应用程序依赖于会话状态，您可能就需要对其进行配置，使它能使用无 Cookie 会话。但是，在某些情况下，如果用户与其他人共享 URL - 可能是用户通过电子邮件将 URL 发送给同事，而该用户的会话仍然处于激活状态 - 那么最终这两个用户可能共享同一个会话，结果将难以预料。

您可能感兴趣的文章: