今天看到rails 的session 實現(xiàn)方式時,突然對Tomcat的session 實現(xiàn)方式也產(chǎn)生了好奇心.
一般會認(rèn)為客戶端在第一次訪問Web容器時，容器會創(chuàng)建一個Session，這個Session被添加到一個Map 里，由容器負(fù)責(zé)維護(hù)。這個大家都很清楚，也很容易理解。但是關(guān)鍵是如何與客戶端瀏覽器交換這個SessionId 的信息，很多書都提到有三種方式：cookie、URL重寫、和隱藏表單，后兩種是類似的。
如果是第一種，那么Sessionid被關(guān)聯(lián)到一個瀏覽器一關(guān)閉就失效的cookie里，然后客戶端瀏覽器每次用這個cookie來標(biāo)示會話。注意這些都是Web容器替我們完成的。
如果是URL重寫，則每個請求字符串后面會被附加如;jsessionid=XXXXXXXXX這樣的標(biāo)示，用于標(biāo)示會話。
容器何時決定使用哪一種方法？
我找了一個Winsock Expert的軟件來監(jiān)測IE 瀏覽器發(fā)送和接收的信息，IE的版本為6.0，Tomcat的版本為5.0.19，結(jié)果如下：當(dāng)IE瀏覽器向Tomcat第一次發(fā)出請求時，
不包含任何Cookie信息，當(dāng)然這是第一次訪問這個站點(diǎn)。為了比對Cookie的內(nèi)容，我在訪問的index.jsp頁面中使用了response.setCookie向響應(yīng)放了一個名為newCookie的Cookie。
最后監(jiān)測的結(jié)果如下，除了用戶自定義的newCookie之外，還有一個名為JSESSIONID的Cookie被加入了響應(yīng)。
在接下來的請求中，都包含了JSESSIONID這個Cookie，在請求內(nèi)容中能清楚的看到這一點(diǎn)：
但是，如果用request.getCookies是無法看到JSESSIONID這個Cookie的，只能看到我自定義的那個newCookie，JSESSIONID這個Cookie被Tomcat隱藏起來了，對于編程人員來說，是不可見的（我無法使用${cookie.JSESSIONID.name}或是${cookie.JSESSIONID.value}來檢查它的名稱和值，雖然這些對我來說都是已知的）。
得出如下結(jié)論：如果客戶端禁用cookie，就用jsessionid,它的內(nèi)容不寫在硬盤,而是被ie緩存在內(nèi)存了,即便客戶端禁用了cookie,jsessionid還是存在的,這樣一來的話,服務(wù)器就可以知道來自客戶端的請求是不是來自同一個流覽器了.
==============================
你這里有個誤解,當(dāng)禁用cookie后,瀏覽器可以接受JSESSIONID,放到瀏覽器內(nèi)存里,但是瀏覽器不能將這個JSESSIONID放在請求頭里發(fā)送給服務(wù)器,所以實現(xiàn)不了會話,用戶禁用cookie后,只能用你說的后兩種方法
你的認(rèn)識是對的，我在寫這篇blog后，經(jīng)過查閱資料意識到自己之前的認(rèn)識有點(diǎn)偏差，但忘記改相應(yīng)的blog了