剛剛在洗衣服的時候突然想到今天在做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地址就變成了：
http://localhost:1115/FormsAuthentication/(F(V0-gEZNEzXUqevbOqKwNoBcMf6vBWnyNbdpa2UhZzrfOUkGPvyB91-9nFlnBDmCAgdpz4gJ6kq-QOVjbNsvKig2))/Security/Default.ASPx
在站點目錄多了一級目錄，這裡的值就是當前會用戶的驗證票信息和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的討論就算告一段落了，我發現到目前為止中文社區好像還沒有很多人對這一屬性有過深入的討論。文中很多都是我個人綜合理解，總結出來，裡面可能會有很多錯誤的認識和觀點，歡迎大家給我指正和補充。
http://www.cnblogs.com/hjf1223/archive/2006/10/14/529227.Html
