HTTP內容協商機制
懶人包
比方說有很多不同的國家訪問同一個URL，法國人瀏覽需要加載法與資源，美國人需要加載英語，而解決這些就是透過內容協商機制
內容協商方式
客戶端驅動
客戶端發起請求，服務器返回選項提供客戶端選擇後再二次請求
優點: 容易實現，且較精準
缺點: 使用者初次訪問無法直接查看內容，且需要多請求一次
服務器驅動(最廣泛)
服務器檢查客戶端請求頭來決定提供甚麼資源
優點: 可以直接查看內容， 具有近似匹配
缺點: 請求投如果沒有協代可能得用猜的提供資源
透明協商
中間設備(通常為緩存代理)代表客戶端進行協商
優點: 請求快速
缺點: 因為非標準HTTP方式，因此沒有標準規範
服務器驅動
請求頭
- Accept: 告知服務器發送何種媒體類型(mp3)
- Accept-Language: 告知服務器發送何種語言
- Accept-Charset: 告知服務器發送何種字符集(Unicode)
- Accept-Encoding: 告知服務器發送何種編碼(UTF-8)
響應頭
跟請求頭一一對應(跟上面索引一一對應)
- Content-Type
- Content-Language
- Content-Type
- Content-Encoding
近似匹配(Q值)
拿Accept-Language(所有都一樣)當例子
Accept-Language: en;q=0.5,fr ;q=0.0, nl;q=1.0,tr;q=0.0
註: nl:荷蘭語，en: 英語， fr: 法語, tr: 土耳其語
看q值大小(從0到1)，不是加起來等於1，只是代表優先級
比方說上面那個例子按照降冪排列會變下面
Accept-Language: nl;q=1.0, en;q=0.5, fr ;q=0.0, tr;q=0.0
假如客戶端請求西班牙語，但服務器端沒有西班牙語，因此服務器會找Q值最大，在此例優先優先發送荷蘭語(q=1.0)，假如服務器也沒有荷蘭語，則回傳英語(q=0.5) 。
假如服務器既沒有nl也沒有en會產生問題，所以服務器通常會設置默認回傳，即便沒有沒有上傳任何編號也會給默認的語言