一、會話跟蹤的需求
cookie
可以使用 cookie 儲存購物會話的 id；在後續連線中，取出當前的會話 id，並使用這個 id 從伺服器上的查詢表（lookup table）中提取出會話的相關資訊。 以這種方式使用 cookie 是一種絕佳的解決方案，也是在處理會話時最常使用的方式。但是，sevlet 中最好有一種高階的 api 來處理所有這些任務，以及下面這些冗長乏味的任務：從眾多的其他cookie中（畢竟可能會存在許多cookie）提取出儲存會話識別符號的 cookie；確定空閒會話什麼時候過期，並**它們；將雜湊表與每個請求關聯起來；生成惟一的會話識別符號。
url 重寫
採用這種方式時，客戶程式在每個url的尾部新增一些額外資料。這些資料標識當前的會話，伺服器將這個識別符號與它儲存的使用者相關資料關聯起來。 url重寫是比較不錯的會話跟蹤解決方案，即使瀏覽器不支援 cookie 或在使用者禁用 cookie 的情況下，這種方案也能夠工作。url 重寫具有 cookie 所具有的同樣缺點，也就是說，伺服器端程式要做許多簡單但是冗長乏味的處理任務。即使有高層的 api 可以處理大部分的細節，仍須十分小心每個引用你的站點的 url ，以及那些返回給使用者的 url。即使通過間接手段，比如伺服器重定向中的 location 字段，都要新增額外的資訊。這種限制意味著，在你的站點上不能有任何靜態 html 頁面（至少靜態頁面中不能有任何鏈結到站點動態頁面的鏈結）。因此，每個頁面都必須使用 servlet 或 jsp 動態生成。即使所有的頁面都動態生成，如果使用者離開了會話並通過書籤或鏈結再次回來，會話的資訊也會丟失，因為儲存下來的鏈結含有錯誤的標識資訊。
隱藏的表單域
二、servlet 的會話跟蹤
servlet 提供一種出色的會話跟蹤解決方案：httpsession api 這個高層介面構築在 cookie 或 url 重寫之上。所有的伺服器都支援使用 cookie 的會話跟蹤，大多數伺服器可以全域性地切換到 url 重寫。不管採用哪種方式，servlet 的開發設計人員都不需要為許多具體的實現細節操心，也不需要顯式地操作 cookie 或附加到 url 上的資訊；他們自動獲得乙個區域，可以方便地儲存與每個會話相關聯的任意物件。
在 servlet 中，會話的使用比較簡單直接，它涉及4個基本的步驟：
訪問與當前請求相關聯的會話物件。
呼叫 request.getsession 獲取 httpsession 物件，該物件是乙個簡單的雜湊表，用來存 儲使用者的相關資料。
查詢與會話相關聯的資訊。
呼叫 httpsession 物件的 getattribute 將返回值轉換成恰當的型別，並檢查結果是否為null
儲存會話中的資訊。
使用 setattribute，設定需要儲存的值以及相應的鍵。
廢棄會話資料。
呼叫 removeattribute 廢棄指定的值。呼叫 invalidate 廢棄整個會話。呼叫 logout 使客戶退出 web 伺服器，並作廢與該使用者相關聯的所有會話。
下面對 httpsession 類中的方法進行彙總：
public object getattribute(string name)
這個方法從會話物件中提取出之前儲存的值。如果沒有值與給定的名稱相關聯，它返回 null
public enumeration getattributenames()
這個方法返回會話中所有屬性的名稱。
public void setattribute(string name, object value)
這個方法將值和名稱關聯起來。如果提供給 setattribute 的物件實現了 httpsessionbindinglistener 介面，在它儲存到會話中之後，它的 valuebound 方法 會被呼叫。類似地，如果之前的值實現了 httpsessionbindinglistener，它的 valueunbound 方法會被呼叫。
public void removeattribute(string name)
這個方法移除與指定名稱關聯的任何值。如果要移除的值實現了 httpsessionbindinglistener 介面，它的 valueunbound 方法會被呼叫。
public void invalidate()
這個方法將會話作廢，並釋放所有與之相關聯的物件。使用這個方法時要小心： 要牢記會話是與使用者（即客戶程式）相關聯的，而不是單個的 servlet 或 jsp 頁面。 因此，如果作廢乙個會話，有可能會破壞掉其他 servlet 或 jsp 頁面正在使用的資料。
public void logout()
這個方法將客戶從 web 伺服器中登出，並將與該客戶相關聯的所有會話作廢。logout 的影響範圍和身份驗證的影響範圍相同。例如，如果伺服器實現了單一登 錄，那麼呼叫 logout 則會將客戶從伺服器上的所有 web 應用中登出，並且將與該 客戶相關聯的所有會話（每個 web 應用至多乙個）作廢。
public string getid()
這個方法返回每個會話所對應的惟一識別符號。這對於除錯或記錄，或少數情況下 用程式設計的手段將值從記憶體移到資料庫中（儘管某些 j2ee 伺服器可以自動完成這項任務），都很有用。
public boolean isnew()
如果會話尚未和客戶程式（瀏覽器）發生任何聯絡，則這個方法返回 true，這一般是 因為會話是新建立的，不是由輸入的客戶請求所引起。對於預先存在的會話，該 方法返回 false，提及這個方法的主要原因是盡量避免使用它。
public long getcreationtime()
這個方法返回會話首次構建的時間，格式為自2023年1月1日午夜（gmt）以來的 毫秒數。如果要獲取用於列印的值，可以將該值傳遞給 date 的建構函式或 gregoriancalendar 的 settimeinmillis 方法。
public long getlastaccessedtime()
這個方法返回會話最後被客戶程式訪問的時間，格式為自2023年1月1日午夜（gmt）以來的毫秒數。
public int getmaxinactiveinterval()
public void setmaxinactiveinterval(int seconds)
這些方法讀取或設定在沒有訪問的情況下，會話在被自動廢棄之前應該保持多長 時間，以秒為單位。負值表示會話從不超時。要注意，超時由伺服器來維護，它 不同於 cookie 的失效日期。首先，會話一般基於駐留記憶體的 cookie，不是持續性 cookie，因而也就沒有截止日期。即使擷取到 jsessionid cookie，並為它設定乙個失效日期傳送出去，瀏覽器會話和伺服器會話也會截然不同。
三、對 url 編碼
預設地，servlet 容器（引擎）使用 cookie 作為會話跟蹤的底層機制。但如果伺服器進行了重新配置，使用 url 重寫（url rewrite），則**需要更改。
核心的會話跟蹤**不需做任何改動。其他大部分**都需要進行更改。
特別地，如果頁面中含有指向自身所在站點的鏈結時，必須顯式地將會話資料新增到 url。servlet api 提供將這項資訊新增到任意指定 url 的方法。問題是必須呼叫這些方法；如果想讓系統檢查所有 servlet 和 jsp 頁面的輸出，找出哪些部分包含指向自身站點的超連結並修改這些 url，這在技術上是不可行的。這項需求表示：如果使用 url 重寫進行會話跟蹤，那麼就不能擁有任何靜態 html 頁面，或者至少不能擁有引用自身站點的靜態 html 頁面。這對於很多應用都是一項沉重的負擔，但少數情況下是值得的。
兩種情況下可能會用到引用自身站點的url：
第一種情況是在 servlet 生成的 web 頁面中含有嵌入的 url。這種情況下，應該將這些 url 傳遞給 httpservletresponse 的 encodeurl 方法。這個方法確定當前是否在使用 url 重寫，僅在必需時附加會話資訊；否則，不做任何更改直接返回傳入的url。下面是乙個具體的例子：
string originalurl = somerelativeorabsoluteurl;
string encodedurl = response.encodeurl(originalurl);
out.println("...");
第二種情況是在 sendredirect 呼叫中（即放入 location 響應報頭）。這種情況下，由於要根據不同的規則確定是否需要附加會話資訊，因而不能使用 encodeurl。幸運的是，httpservletresponse 提供 encoderedirecturl 方法來處理這種情況。下面是乙個具體的例子：
string originalurl = someurl;
string encodedurl = response.encoderedirecturl(originalurl);
response.sendredirect(encodedurl);
如果認為自己的 web 應用最終有可能使用 url 重寫來替代 cookie，那麼最好預先規劃，對引用自身站點的 url 進行編碼。
四種會話跟蹤技術
會話跟蹤是一種靈活 輕便的機制，它使web上的狀態程式設計變為可能。當使用者在同一 的多個頁面之間轉換時，根本無法確定是否是同乙個客戶，會話跟蹤技術就可以解決這個問題。當乙個客戶在多個頁面間切換時，伺服器會儲存該使用者的資訊。有四種方法可以實現會話跟蹤技術 url重寫 隱藏表單域 cookie se...
四種會話跟蹤技術
suc.jsp中獲取資料 sring name request.getparameter username sring pwd request.getparameter userpwd 3 cookie方式 伺服器上，響應cookie給瀏覽器 string name request.getparam...
四種會話跟蹤技術
session,cookie,url重寫，掩藏表單域 為什麼會出現會話跟蹤技術 基於http是一種無狀態，無連線的協議，但是在現實生活中我們在瀏覽器中瀏覽的資訊或是傳送的請求都希望服務端能夠識別是否是同乙個人傳送的請求，這時引入了會話跟蹤技術。四種技術的區別 session和cookie是相互依存的...