刚刚在洗衣服的时候突然想到今天在做WAP程序的表单验证的时候遇到一个问题,在不支持Cookies的移动设备模拟器中无法正常进行表单验证,联想到昨天使用web.config设置cookieless属性时会在访问时会出现"Cannot use a leading .. to exit above the top directory"的异常,自然而然的我就想到了前一段时间困扰我很久的一个站点异常无法使用前导 .. 在顶级目录上退出(Cannot use a leading .. to exit above the top directory)。综合一下，终于理解了为什么会出现这样的异常，也理解了为什么在asp.net 2.0 中，将原来cookieless属性只能设置true|false，改成了可以设置枚举HttpCookieMode的值,分别为:AutoDetect,UseCookies,UseDeviceProfile,UseUri 。
如果对表单验证很有经验的朋友可能会很清楚，可以有两种方式来保存当前的SessionID和用户的验证票信息，分别是使用Cookie和在URL地址加上一串编码过的字符串来标识当前的SessionID和用户的验证票信息。第一种方式非常普遍，对于使用URI来标识当前SessionID和验证票，我相信如果不是特殊需要的话，相信很多人都会跟我一样还无法很好理解。我做了两个简单的页面，来模拟用户的验证过程。当我在web.config中设置cookieless="AutoDetect"时，就跟我们平常一样，登录的URL是：
http://localhost:1115/FormsAuthentication/Security/Default.aspx
而当我设置cookieless="UseUri"时，这时URL地址就变成了：
在站点目录多了一级目录，这里的值就是当前会用户的验证票信息和SessionID信息。在某些场合，这样做是非常有意义的（或者是必须的），因为在不支持cookie环境下，你要去标识一个是否属于同一个会话，当前用户是否已验证过，等等与会话相关信息的时候就会变得异常的困难。
了解了这两个保存会话信息的方式后,我们再来讨论一下,asp.net team为什么把原来只能设置true | false的属性改成可以设置不同的枚举值.首先我们来看看这4个值的含意(在Windows Live Writer 不能画表格 :< ):
AutoDetect:自动检测客户端实际是否支持cookie再来决定使用两种方式中的哪一种(最佳适应)。
UseCookies:不管客户端是否支持cookie,反正都使用cookie来标识(第一种方式)。
UseDeviceProfile:根据设备文件来判断是否支持cookie,进而决定使用哪种方式。相信很多人都对这个概念很模糊，由于最近在研究WAP，所以对它有一些简单的认识。在<%windir%>Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers目录下有很多的.browser文件，这些文件就是用来标识对应的设备（浏览器）的浏览能力（描述不是很清楚，就是一些技术参数，是否支持cookie and so on），在asp.net中，会根据这些.browser文件，动态生成从HttpBrowserCapabilities继承下来的设备参数类型，标识对应的设备的一些参数值，编程中可以通过Request.Browser得到这个设备参数对象，并使用。
UseUri :与UseCookies类似的，不管客户端是否支持cookie，反正都使用第二种方式。
特别说明：为什么特别强调“实际”，和详细描述UseDeviceProfile呢？主要是因为，我发现由于可能是设备文件中标识的参数与对应的设备的实际并不完全匹配，（比如，有可能设备文件中标识这种设备支持cookie，但实际的设备却不支持）。所以如果要根据设备的实际来选择是否使用cookie，那就要使用AutoDetect值了。设备文件只能是做为参考，当然如果你对设备文件有充分控制条件的话那就另当别论了。而且还有一点要特别注意，AutoDetect并不是默认值，UseDeviceProfile才是。
回到正题，为什么要改cookieless属性的可选值呢？毫无疑问，是为了增加程序的可操控性。原来的值有点太过单一化了，二选一，没有商量的余地。现在我们可以根据各种不同的情况来让程序动态或程序员手动选择。结合这一段时间的WAP开发经验，我想这样做的一个目的就是为了能更好的兼容移动设备，兼容WAP的应用。目前还有很多的设备还并不支持cookie。
有了上面的介绍后，我还想来解开为什么会出现“Cannot use a leading .. to exit above the top directory”异常的迷团。前几天也有收到一个朋友的来信，也是在使用CommunityServer 2.0遇到这个问题，(相信目前遇到最多的就是asp.net 2.0版的CommunityServer了)。目前使用了Url Rewrite，所以我们程序的很多URL都是假的，所以如果在页面中使用了相对路径（~/）的话，那我们就有可能遇到这样的麻烦了。因为搜索引擎（特别是google）不支持cookie，所以在它访问站点的时候就会使用上面提到的第二种方式来标识会话信息，这时候URI就多了一级了，所以在这个页面下所有的链接地址都是多一个../，无法正常访问了，从而造成上面这个异常的出现。(其实可以看出这个异常本身与Url Rewrite并没有多大关系，只不是communityserver和我的程序中都使用了url rewrite)。
解决办法有三种：
1.设置cookieless = UseCookies，不管客户端是否支持cookie都使用cookie。
2.因为默认cookieless = UseDeviceProfile，所以可以为搜索引擎建立一个设备文件.browser，弄虚作假一下。《Get GoogleBot to crash your .NET 2.0 site》就有给出了这样的做法了。
3.修改程序，将里面的相对路径（~/）改成绝对路径表示（可以使用Resolve方法）。
到目前为止对cookieless的讨论就算告一段落了，我发现到目前为止中文社区好像还没有很多人对这一属性有过深入的讨论。文中很多都是我个人综合理解，总结出来，里面可能会有很多错误的认识和观点，欢迎大家给我指正和补充。
代码下载：
