SESSION的知識

android模擬表單用到了httpclient,可是須要了解Jsessionid的相關知識

以下是從一篇博文摘抄來的

在web應用的開發中咱們會常常看到這樣的url：http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x...。這跟通常的url基本同樣，只有一個地方有區別，那就是「;jessionid=xxxxxxxx」。這個參數有時候有，有時候又沒有，說它是參數可又跟通常傳遞的參數不一樣，它是緊跟在url後面用分號來分隔的，用通常的request.getParameter()方法還取不到。那這個參數究竟是幹嗎用的呢？要了解它還要先了解session的實現方式。
session的實現方式
作web開發的同窗都知道，http是無狀態的會話協議，也就是說沒法保存用戶的信息。那若是有一些信息須要在用戶的瀏覽活動中一直保持，該怎麼作呢？咱們能夠把這些信息在每次請求的時候做爲參數傳遞給服務器，但這樣作既麻煩又耗費資源，這時候就體現出了session的重要性。session是web開發中不可或缺的一個特性。它是對於一個特定的用戶請求，在web服務器上保存的一個全局變量。有了它咱們就能夠把用戶的一些信息保存在服務器上，而不用在服務器和客戶端之間來回傳遞。知道了session的做用，那session是怎麼實現的呢？服務器上爲每一個用戶都保存了一個session，那當用戶請求過來的時候是怎麼知道某一個用戶應該對應哪一個session呢？這時jsessionid就派上用場了。每個session都有一個id來做爲標識，這個id會傳到客戶端，每次客戶端請求都會把這個id傳到服務器，服務器根據id來匹配此次請求應該使用哪一個session。jsessionid就是客戶端用來保存sessionid的變量，主要是針對j2ee實現的web容器，沒有研究過其餘語言是用什麼變量來保存的。通常對於web應用來講，客戶端變量都會保存在cookie中，jsessionid也不例外。不過與通常的cookie變量不一樣，jsessionid是保存在內存cookie中的，在通常的cookie文件中是看不到它的影子的。內存cookie在打開一個瀏覽器窗口的時候會建立，在關閉這個瀏覽器窗口的時候也同時銷燬。這也就解釋了爲何session變量不能跨窗口使用，要跨窗口使用就須要手動把jsessionid保存到cookie裏面。
jsessionid的做用
在以上的文字中咱們瞭解了session的實現原理，同時也知道了session跟jsessionid緊密不可分割的聯繫。只有經過jsessionid才能使session機制起做用，而jsessionid又是經過cookie來保存。看到這裏，也許你會發現一個問題，若是用戶禁用了cookie，那jsessionid不是就不能保存了嗎？session不是不起做用了嗎？咱們真的對此一籌莫展了嗎？固然不是。在用戶禁用了cookie時候，咱們能夠經過url重寫來實現jsessionid的傳遞。這就是我上面指出的那樣的url:http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x..。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的可用性。
說道這裏，你們應該對jsessionid和session的關係，以及jsessionid的做用有個了一個大體的瞭解，具體應用還要本身在項目中具體狀況具體對待。

=============================================================================================

jsessionid=CA72488F94BC8A3E92FEEDA8CC736FDC       這個jsessionid是session的一個標識。       我在這裏轉貼jdbc老大的部分講解       session機制是一種服務器端的機制，服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。       當程序須要爲某個客戶端的請求建立一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲 session id，若是已包含一個session id則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個 session檢索出來使用（若是檢索不到，可能會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個 session id將被在本次響應中返回給客戶端保存。       保存這個session id的方式能夠採用cookie，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發揮給服務器。通常這個cookie的名字都是相似於SEEESIONID，而。好比weblogic對於web應用程序生成的cookie，JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是 JSESSIONID。       因爲cookie能夠被人爲的禁止，必須有其餘機制以便在cookie被禁止時仍然可以把session id傳遞迴服務器。常常被使用的一種技術叫作URL重寫，就是把session id直接附加在URL路徑的後面，附加方式也有兩種，一種是做爲URL路徑的附加信息，表現形式爲http://...../xxx;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764另外一種是做爲查詢字符串附加在URL後面，表現形式爲http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764這兩種方式對於用戶來講是沒有區別的，只是服務器在解析的時候處理的方式不一樣，採用第一種方式也有利於把session id的信息和正常程序參數區分開來。爲了在整個交互過程當中始終保持狀態，就必須在每一個客戶端可能請求的路徑後面都包含這個session id。       另外一種技術叫作表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時可以把session id傳遞迴服務器。好比下面的表單<form name="testform" action="/xxx"><input type="text"></form>       在被傳遞給客戶端以前將被改寫成<form name="testform" action="/xxx"><input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764"><input type="text"></form>       這種技術如今已較少應用，筆者接觸過的很古老的iPlanet6(SunONE應用服務器的前身)就使用了這種技術。實際上這種技術能夠簡單的用對action應用URL重寫來代替。       在談論session機制的時候，經常聽到這樣一種誤解「只要關閉瀏覽器，session就消失了」。其實能夠想象一下會員卡的例子，除非顧客主動對店家提出銷卡，不然店家絕對不會輕易刪除顧客的資料。對session來講也是同樣的，除非程序通知服務器刪除一個session，不然服務器會一直保留，程序通常都是在用戶作log off的時候發個指令去刪除session。然而瀏覽器歷來不會主動在關閉以前通知服務器它將要關閉，所以服務器根本不會有機會知道瀏覽器已經關閉，之因此會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器後這個 session id就消失了，再次鏈接服務器時也就沒法找到原來的session。
       若是服務器設置的cookie被保存到硬盤上，或者使用某種手段改寫瀏覽器發出的HTTP請求頭，把原來的session id發送給服務器，則再次打開瀏覽器仍然可以找到原來的session。       偏偏是因爲關閉瀏覽器不會致使session被刪除，迫使服務器爲seesion設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就能夠認爲客戶端已經中止了活動，纔會把session刪除以節省存儲空間。

以上部分主要介紹了session的相關知識

可是實際在android中

用的時候就是在httpclient中使用這個session來進行請求鏈接的

進一步說就是cookie  我看過cookie中方的就是session

拿到這個session就能夠操做一些登錄以後才能操做的內容了