當客戶端瀏覽器中禁止 Cookie，Servlet 容器無法從客戶端瀏覽器中取得作爲 Cookie 的 Session ID，也就無法跟蹤客戶狀態。
Java Servlet API 中提出了跟蹤 Session 的另一種機制，如果客戶端瀏覽器不支持 Cookie，Servlet 容器可以重寫客戶請求的 URL，把 Session ID 添加到 URL 信息中。
HttpServletResponse 接口提供了重寫 URL 的方法：public java.lang.String encodeURL(java.lang.String url)
該方法的實現機制爲：
● 先判斷當前的 Web 組件是否啓用 Session，如果沒有啓用 Session，直接返回參數 url。
● 再判斷客戶端瀏覽器是否支持 Cookie，如果支持 Cookie，直接返回參數 url；如果不支持 Cookie，就在參數 url 中加入 Session ID 信息，然後返回修改後的 url。
我們可以對網頁中的鏈接稍作修改，解決以上問題：
修改前：
<a href=“maillogin.jsp“>
修改後：
<a href=“<%=response.encodeURL(“maillogin.jsp“)%>“>
Java代碼 ![收藏代碼]()
- //HTTP協議與狀態保持
- HTTP協議本身是無狀態的，這與HTTP協議本來的目的是相符的，客戶端只需要簡單的向服務器請求下載某些文件，無論是客戶端還是服務器都沒有必要紀錄 彼此過去的行爲，每一次請求之間都是獨立的，好比一個顧客和一個自動售貨機或者一個普通的（非會員制）大賣場之間的關係一樣。
- 然而聰明（或者貪心？）的人們很快發現如果能夠提供一些按需生成的動態信息會使web變得更加有用，就像給有線電視加上點播功能一樣。這種需求一方 面迫使HTML逐步添加了表單、腳本、DOM等客戶端行爲，另一方面在服務器端則出現了CGI規範以響應客戶端的動態請求，作爲傳輸載體的HTTP協議也 添加了文件上載、cookie這些特性。其中cookie的作用就是爲了解決HTTP協議無狀態的缺陷所作出的努力。至於後來出現的session機制則 是又一種在客戶端與服務器之間保持狀態的解決方案。
- 讓我們用幾個例子來描述一下cookie和session機制之間的區別與聯繫。筆者曾經常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就需要某種方式來紀錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案：
- 1、該店的店員很厲害，能記住每位顧客的消費數量，只要顧客一走進咖啡店，店員就知道該怎麼對待了。這種做法就是協議本身支持狀態。
- 2、發給顧客一張卡片，上面記錄着消費的數量，一般還有個有效期限。每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以後的消費相聯繫起來。這種做法就是在客戶端保持狀態。
- 3、發給顧客一張會員卡，除了卡號之外什麼信息也不紀錄，每次消費時，如果顧客出示該卡片，則店員在店裏的紀錄本上找到這個卡號對應的紀錄添加一些消費信息。這種做法就是在服務器端保持狀態。
- 由於HTTP協議是無狀態的，而出於種種考慮也不希望使之成爲有狀態的，因此，後面兩種方案就成爲現實的選擇。具體來說cookie機制採用的是在 客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。同時我們也看到，由於採用服務器端保持狀態的方案在客戶端也需要保存一個 標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上它還有其他選擇。