在不支持Cookies的移動設(shè)備模擬器中無法正常進行表單驗證,聯(lián)想到昨天使用web.config設(shè)置cookieless屬性時會在訪問時會出現(xiàn)"Cannot use a leading .. to exit above the top directory"的異常,自然而然的我就想到了前一段時間困擾我很久的一個站點異常無法使用前導(dǎo) .. 在頂級目錄上退出(Cannot use a leading .. to exit above the top directory)。綜合一下，終于理解了為什么會出現(xiàn)這樣的異常，也理解了為什么在asp.net 2.0 中，將原來cookieless屬性只能設(shè)置true|false，改成了可以設(shè)置枚舉HttpCookieMode的值,分別為:AutoDetect,UseCookies,UseDeviceProfile,UseUri 。

如果對表單驗證很有經(jīng)驗的朋友可能會很清楚，可以有兩種方式來保存當前的SessionID和用戶的驗證票信息，分別是使用Cookie和在URL地址加上一串編碼過的字符串來標識當前的SessionID和用戶的驗證票信息。第一種方式非常普遍，對于使用URI來標識當前SessionID和驗證票，我相信如果不是特殊需要的話，相信很多人都會跟我一樣還無法很好理解。我做了兩個簡單的頁面，來模擬用戶的驗證過程。當我在web.config中設(shè)置cookieless="AutoDetect"時，就跟我們平常一樣，登錄的URL是：

http://localhost:1115/FormsAuthentication/Security/Default.aspx

而當我設(shè)置cookieless="UseUri"時，這時URL地址就變成了：

http://localhost:1115/FormsAuthentication/(F(V0-gEZNEzXUqevbOqKwNoBcMf6vBWnyNbdpa2UhZzrfOUkGPvyB91-9nFlnBDmCAgdpz4gJ6kq-QOVjbNsvKig2))/Security/Default.aspx 

在站點目錄多了一級目錄，這里的值就是當前會用戶的驗證票信息和SessionID信息。在某些場合，這樣做是非常有意義的（或者是必須的），因為在不支持cookie環(huán)境下，你要去標識一個是否屬于同一個會話，當前用戶是否已驗證過，等等與會話相關(guān)信息的時候就會變得異常的困難。

了解了這兩個保存會話信息的方式后,我們再來討論一下,asp.net team為什么把原來只能設(shè)置true | false的屬性改成可以設(shè)置不同的枚舉值.首先我們來看看這4個值的含意(在Windows Live Writer 不能畫表格 :< ):

AutoDetect:自動檢測客戶端實際是否支持cookie再來決定使用兩種方式中的哪一種(最佳適應(yīng))。

UseCookies:不管客戶端是否支持cookie,反正都使用cookie來標識(第一種方式)。

UseDeviceProfile:根據(jù)設(shè)備文件來判斷是否支持cookie,進而決定使用哪種方式。相信很多人都對這個概念很模糊，由于最近在研究WAP，所以對它有一些簡單的認識。在<%windir%>Microsoft.NET/Framework/v2.0.50727/CONFIG/Browsers目錄下有很多的.browser文件，這些文件就是用來標識對應(yīng)的設(shè)備（瀏覽器）的瀏覽能力（描述不是很清楚，就是一些技術(shù)參數(shù)，是否支持cookie and so on），在asp.net中，會根據(jù)這些.browser文件，動態(tài)生成從HttpBrowserCapabilities繼承下來的設(shè)備參數(shù)類型，標識對應(yīng)的設(shè)備的一些參數(shù)值，編程中可以通過Request.Browser得到這個設(shè)備參數(shù)對象，并使用。

UseUri :與UseCookies類似的，不管客戶端是否支持cookie，反正都使用第二種方式。

特別說明：為什么特別強調(diào)“實際”，和詳細描述UseDeviceProfile呢？主要是因為，我發(fā)現(xiàn)由于可能是設(shè)備文件中標識的參數(shù)與對應(yīng)的設(shè)備的實際并不完全匹配，（比如，有可能設(shè)備文件中標識這種設(shè)備支持cookie，但實際的設(shè)備卻不支持）。所以如果要根據(jù)設(shè)備的實際來選擇是否使用cookie，那就要使用AutoDetect值了。設(shè)備文件只能是做為參考，當然如果你對設(shè)備文件有充分控制條件的話那就另當別論了。而且還有一點要特別注意，AutoDetect并不是默認值，UseDeviceProfile才是。

回到正題，為什么要改cookieless屬性的可選值呢？毫無疑問，是為了增加程序的可操控性。原來的值有點太過單一化了，二選一，沒有商量的余地?，F(xiàn)在我們可以根據(jù)各種不同的情況來讓程序動態(tài)或程序員手動選擇。結(jié)合這一段時間的WAP開發(fā)經(jīng)驗，我想這樣做的一個目的就是為了能更好的兼容移動設(shè)備，兼容WAP的應(yīng)用。目前還有很多的設(shè)備還并不支持cookie。

有了上面的介紹后，我還想來解開為什么會出現(xiàn)“Cannot use a leading .. to exit above the top directory”異常的迷團。前幾天也有收到一個朋友的來信，也是在使用CommunityServer 2.0遇到這個問題，(相信目前遇到最多的就是asp.net 2.0版的CommunityServer了)。目前使用了Url Rewrite，所以我們程序的很多URL都是假的，所以如果在頁面中使用了相對路徑（~/）的話，那我們就有可能遇到這樣的麻煩了。因為搜索引擎（特別是google）不支持cookie，所以在它訪問站點的時候就會使用上面提到的第二種方式來標識會話信息，這時候URI就多了一級了，所以在這個頁面下所有的鏈接地址都是多一個../，無法正常訪問了，從而造成上面這個異常的出現(xiàn)。(其實可以看出這個異常本身與Url Rewrite并沒有多大關(guān)系，只不過communityserver和我的程序中都使用了url rewrite)。

解決辦法有三種：

1.設(shè)置cookieless = UseCookies，不管客戶端是否支持cookie都使用cookie。

2.因為默認cookieless = UseDeviceProfile，所以可以為搜索引擎建立一個設(shè)備文件.browser，弄虛作假一下。《Get GoogleBot to crash your .NET 2.0 site》就有給出了這樣的做法了。

3.修改程序，將里面的相對路徑（~/）改成絕對路徑表示（可以使用Resolve方法）。