[Http] Header 和 Cookie、Session技術 的筆記

Header

• header是能夠加入自定義鍵值對的。

  並不是必定要使用cookie，咱們公司APP的請求就是使用自定義的參數而非Cookie

• content-length用於描述HTTP消息實體的傳輸長度the transfer-length of the message-body

  在HTTP協議中，消息實體長度和消息實體的傳輸長度是有區別，好比說gzip壓縮下，消息實體長度是壓縮前的長度，消息實體 的傳輸長度是gzip壓縮後的長度。另外，長度是指字節大小，而非字符數量

Cookie

這兩天學習Cookie有關的知識，發現以前真的不懂

1. 服務器經過Set-Cookie首部將cookie信息返回給客戶端
2. 客戶端收到並保存cookie，服務器Set-Cookie時會指定cookie的有效目錄，默認爲當前頁面所處目錄
3. 客戶端在每次請求時，都攜帶當前頁面適用的cookie

Session

• session是經過Cookie實現的
• 服務器端 經過Set-Cookie，將session-id=value這個cookie存到客戶端
• 客戶端每次攜帶session-id=value這條cookie信息，因而服務器能根據seesionid來找到位於服務器上的session實例。
• 客戶端禁用session時使用URL重寫來使每次請求url攜帶sessionid

服務器是怎麼判斷瀏覽器是否禁用了cookie的呢？

• TOMCAT判斷客戶端瀏覽器是否支持Cookie的依據是請求中是否含有Cookie。儘管客戶端可能會支持Cookie，可是因爲第一次請求時不會攜帶任何Cookie（由於並沒有任何Cookie能夠攜帶），URL地址重寫後的地址中仍然會帶有jsessionid。當第二次訪問時服務器已經在瀏覽器中寫入Cookie了，所以URL地址重寫後的地址中就不會帶有jsessionid了。
• 瀏覽器第一次訪問時，服務器建立Session，而後將Session的Id以Cookie的形式發送回給瀏覽器，response. encodeURL(java.lang.String url)方法也將URL進行了重寫，當點擊刷新按鈕第二次訪問，因爲瀏覽器沒有禁用cookie，因此第二次訪問時帶上了cookie，此時服務器就能夠知道當前的客戶端瀏覽器並無禁用cookie，那麼就通知response. encodeURL(java.lang.String url)方法不用將URL進行重寫了。

簡單來講，就是服務器第一次返回html的時候，將sessionid設置到cookie的同時，爲全部url重寫加上sessionid。兩手準備，防止瀏覽器不支持cookie。等到瀏覽器下次再請求，就能夠根據是否攜帶cookie，來判斷是否支持cookie了。

一個攜帶sessionid的url示例

<a href='/JavaWeb_Session_Study_20140720/servlet/BuyServlet;jsessionid=96BDFB9D87A08D5AB1EAA2537CDE2DB2?id=2'>購買</a>
複製代碼

---

菜鳥聲明：

• 真的是菜鳥，並且我通常只會寫寫本身的理解，因此不免有錯誤。
• 請各位諒解的同時，能幫忙指正~

參考文獻

1. Http協議中關於Content-Length的解讀
2. 認識HTTP----Cookie和Session篇
3. cookie禁用後session怎麼使用url重寫詳細講解