內容協商機制
◆指客戶端和伺服器端就響應的資源內容進行交涉，然後提供給客戶端最為適合的資源。內容協商會以響應資源的語言，字符集，編碼方式等作為判斷的基準。
當瀏覽器的預設語言為英文或者中文，訪問相同uri的web頁面時候，就返回對應的英文或中文的web頁面，這種機制稱為內容協商（content negotiation）。
內容協商方式
◆客戶端驅動
客戶端發起請求，伺服器傳送可選項列表，客戶端作出選擇後在傳送第二次請求。
優點：比較容易實現
缺點：增加了時延，至少要傳送兩次請求，第一次請求獲取資源列表，第二次獲取選擇的副本。
◆伺服器驅動（使用最廣泛）
伺服器檢查客戶端的請求頭部集並決定提供哪個版本的頁面。
優點：比客戶端驅動的協商要快。http提供了q機制（理解為權重），允許伺服器近似匹配，還提供了vary首部供伺服器告知下游的裝置（如**伺服器）如何對請求估值。
缺點：首部集不匹配，伺服器要做猜測
◆透明協商
某個中間裝置(通常是快取**)代表客戶端進行協商。
優點：免除了web伺服器的協商開銷，比客戶端驅動的協商要快。
缺點：http並沒有提供相應的規範
伺服器驅動內容協商請求首部集
◆accept: 告知伺服器傳送何種**型別–要聽**
◆accept-language:告知伺服器傳送何種語言–中文
◆accept-charset: 告知伺服器傳送何種字符集—unicode
◆accept-encoding:告知伺服器採用何種編碼----uft-8
內容協商首部集是由客戶端傳送給伺服器用於交換偏好資訊的，以便伺服器可以從文件的不同版本中選擇出最符合客戶端偏好的那個來提供服務。
伺服器用下面列出的實體首部集來匹配客戶端的accept首部集：
accept首部 實體首部
accept content-type
accept-language content-language
accept-charset content-type
accept-encoding content-encoding
伺服器驅動內容協商–近似匹配
假設客戶端的accept-language指定的是西班牙語，但是服務端只有英語與法語版本，這個客戶端希望在沒有西班牙語的時候優先返回英語。這就意味著，我們需要一種http機制更詳細的描述偏好。這種機制就是質量值（q值）。示例如下：
accept-language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0
這個首部表示：使用者最願意接受荷蘭語（nl），英文也行（en）,就是不願意接受法語（fr）或者土耳其語（tr）；
q值的範圍從0.0~1.0（1.0優先順序最高）；
國際化**就會用到內容協商機制，支援客戶想要的語言偏好
HTTP2的協議協商機制
http 2 使用和 http 1.1 一樣的 http 和 https 的 url 模式。同時 http 2 和 http 1.1 也共享了相同的預設埠號 http 的 80 埠，https 的 443 埠。字串 h2c 標示執行在明文 tcp 之上的 http 2 協議 http模式 字串 h2...
瀏覽器與伺服器的協議協商機制
如果你用 http 上知乎，它會返回乙個 301，重定向到 https.之後瀏覽器就會記住這個網頁支援 https，在不給出協議 scheme 的情況下 在輸入框只輸入zhihu.com 優先使用 https 訪問。在 https 協議中，先建立 tcp 連線，然後在建立 tls ssl 連線前，會...
REST內容協商註解
produces註解 用於定義方法的響應實體的資料型別。可以定義乙個或多個，同時可以為每種型別定義質量因素，質量因素取值範圍從0 1的小數值，預設為1.示例 path conneg resource public class connegresource get path id public boo...