url中jsessionid的理解

標籤：產生   ssi   請求報文   ash   put   編碼   關閉   資料   使用者   

（1） 

這是一個保險措施 
因為Session預設是需要Cookie支援的 
但有些客戶瀏覽器是關閉Cookie的 
這個時候就需要在URL中指定伺服器上的session標識,也就是5F4771183629C9834F8382E23BE13C4C 
用一個方法(忘了方法的名字)處理URL串就可以得到這個東西 
這個方法會判斷你的瀏覽器是否開啟了Cookie,如果他認為應該加他就會加上去 

（2） 

連結1：wapbrowse.jsp?curAlbumID=9 ； 
連結2:wapbrowse.jsp;jsessionid=5AC6268DD8D4D5D1FDF5D41E9F2FD960?curAlbumID=9； 
這兩個連結是從模擬器運行時產生的source中拷貝過來的，兩個連結都是指向wapbrowse.jsp,連結1由於不包含 jsessionid,所以在wapbrowse.jsp中變數為null,通過連結2開啟wapbrowse.jsp可以正常訪問session 變數 

（3） 

URL重寫功能,為了防止一些使用者把Cookie禁止而無法使用session而設定的功能.jsessionid後面的一長串就是你伺服器上的session的ID號,這樣無需cookie也可以使用session. 


（4） 

http本身是無session的，無法跟蹤用戶端的資訊，換句話說：http協議不管是誰聯結自己。 
為了實現session，必須有瀏覽器支援。瀏覽器可以用cookie儲存session，這是最通用的做法。 
但是，如果我自己寫一個完全符合http協議的瀏覽器，但是不配合伺服器的session要求，那麼伺服器就無法產生session。 
好在現在的瀏覽器都支援session要求，即使關閉了cookie，瀏覽器也會向伺服器傳遞sessionid，這個id是儲存在瀏覽器的記憶體空間中的，不儲存在硬碟cookie中。 


（5） 

sessionid是作為一個臨時cookie放在瀏覽器端的。 

session的具體資訊放在伺服器端。 

每次瀏覽器發出的請求，都會在http header裡 帶上 sessionid來標識自己。 


既然用Struts，順便再把JSTL用上， 

下面一個非常有用的標籤： 


清單 12. 操作的文法 
    var="name" scope="scope"> 
  
  ... 





URL 重寫是由 操作自動執行的。如果 JSP 容器檢測到一個儲存使用者當前會話標識的 cookie，那麼就不必進行重寫。但是，如果不存在這樣的 cookie，那麼 產生的所有 URL 都會被重寫以編碼會話標識。註：如果在隨後的請求中存在適當的 cookie，那麼 將停止重寫 URL 以包含該標識。 


參考：http://www-900.ibm.com/developerWorks/cn/java/j-jstl0318/index.shtml 

（6） 

方法一：url中緊跟servlet/jsp檔案名稱加;jsessionid=sessionId，其中sessionId由 HttpSession.getId()得到，如http://localhost:8080/aaa /bbb.jsp;jsessionid=saldjfsdflsaeir234?para=1?2=2 

方法二：在application(ServletContext)裡儲存一個session管理器HashMap:sessionId--- sessionRef，這樣可以在所有的servlet/jsp裡調用，這需要在url裡將sessionId以參數形式傳遞，如http: //localhost:8080/aaa/bbb.jsp?sessionId=saldjfsdflsaeir234?para=1?2=2，在服務 器端用request.getParameter("sessionId")擷取 

（7） 

session是在伺服器端儲存。伺服器根據url請求中的session_id來尋找對應的session。 

以一個bbs為例，網站需要根據每個請求url擷取使用者的資訊，如果以cookie方式，使用者資訊全部是存放在cookie中的，這樣可能會不安 全；如果以session方式，使用者資訊可以存放在伺服器端，伺服器只要從http請求中得到session_id，就可以得到存放在session中的 使用者資訊了，這樣安全性比較高。session在伺服器中的表現方式依伺服器而定，可能是寫到臨時檔案中，也可能直接放在記憶體中。 

伺服器從http請求中得到session_id的方式有兩種：cookie和url重寫。如果用戶端啟用cookie，那麼 session_id可以儲存在cookie中；如果禁用cookie，就用url重寫方式，在url中添加.jsessionid=xxxxx參數部 分，伺服器會試圖從url中得到.jsessionid參數作為session_id. 

（8） 

cookie 是儲存在用戶端的文字格式設定資料，session是用戶端登入到應用，由伺服器為該用戶端建立的唯一的標識，可以在session裡面儲存該用戶端的資料比如說使用者帳號。 
一般cookie可以用來儲存你的登入帳號和密碼，在你登入到應用服務上，自動添加到登入介面或直接發送到伺服器上進行登入，這就是你經常能在論壇上看到的你的登入資訊儲存一年的選項 的實現方式 


（9） 

在http的報文格式裡面cookie和session是在同一個包文位置上的 
如果ie發現包文裡麵包含cookie/session的資訊的話，他會根據安全層級來決定是否儲存相關資訊，比如，如果安全機制允許使用 cookie那麼ie將把cookie的資訊儲存到臨時檔案裡面，每次在請求伺服器檔案的時候會把收到的session的資訊加入到請求的報文裡面，這就 是session儲存資訊的原理。如果安全機制不允許使用cookie的話，雖然ie收到了cookie和session的資訊，那麼cookie的資訊 不會被寫入臨時檔案，當ie再次請求伺服器檔案的時候，也不會把收到的session的資訊加入到請求報文裡面，伺服器就無法知道session的資訊 了。

 

 

jessionid通過這樣的方式來從用戶端傳遞到伺服器端,從而來標識session。
注意一點，jsessionid跟一般的url參數傳遞方式是不同的，不是作為參數跟在"？"後面，而是緊跟在url後面用"；"來分隔。
這樣在使用者禁用cookie的時候我們也可以傳遞jsessionid來使用session了，
只不過需要每次都把jseesionid作為參數跟在url後面傳遞。
那這樣豈不是很麻煩，每次請求一個url都要判斷cookie是否可用，
如果禁用了cookie，還要從url裡解析出jsessionid，然後跟在處理完後轉到的url後面，以保持jsessionid的傳遞。
這些問題sun當然已經幫我們想到了。
所以提供了2個方法來使事情變得簡單：response.encodeURL()和response.encodeRedirectURL()。
這2個方法會判斷cookie是否可用，如果禁用了會解析出url中的jsessionid，並串連到指定的url後面，如果沒有找到jessionid會自動幫我們產生一個。
至於為什麼要有2個方法？這2個方法有什麼不同？google了一下，說是這2個方法在判斷是否要包含jsessionid的邏輯上會稍有不同。
在調用HttpServletResponse.sendRedirect前，應該先調用encodeRedirectURL()方法，否則可能會丟失Sesssion資訊。
這2個方法的使用方法如：response.sendRedirect(response.encodeURL("/myapp/input.jsp"));。
如果cookie沒有禁用，我們在瀏覽器地址欄中看到的地址是這樣的：/myapp/input.jsp，如果禁用了cookie，我們會看到：/myapp/input.jsp;jsessionid=73E6B2470C91A433A6698C7681FD44F4。
所以，我們在寫web應用的時候，為了保險起見，應該在程式裡的每一個跳轉url上都使用這2個方法，來保證session的可用性。

 

以前很少遇到這樣的問題，今天又漲見識了...

 

 

資料來自互連網:http://sizhefang.iteye.com/blog/25294

url中jsessionid的理解