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

NO IMAGE

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重寫詳細講解

相關文章

Java學習筆記

[持續更新]開發筆記

可隨機訪問(

[計算機網絡]分組交換和電路交換