思考：
國內訪問某個網址是中文，國外訪問就是英文，爲什麼在國外拿着自己的電腦訪問谷歌也是中文呢？
內容協商機制
◆指客戶端和服務器端就響應的資源內容進行交涉，然後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言，字符集，編碼方式等作爲判斷的基準。
當瀏覽器的默認語言爲英文或者中文，訪問相同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優先級最高）；
國際化網站就會用到內容協商機制，支持客戶想要的語言偏好