Http權威指南筆記 十四 內容協商與轉碼

2021-09-24 20:49:25 字數 2907 閱讀 5267

現在很多國際化的一些web服務都會根據不同地區使用的語言不同,返回不同語言的頁面內容展示給使用者。而這裡面就涉及到本篇介紹的內容——內容協商與轉碼。

目前的內容協商技術主要有3種——客戶端驅動協商、伺服器驅動協商和透明協商(也就是中間**商進行選擇和判斷)。這三類大致歸納如下:

技  術

工作原理

優  點

缺  點

客戶端驅動

客戶端發起請求,伺服器傳送可選項的列表,客戶端選擇

在伺服器端的實現最容易。客戶端可以選擇最合適的內容

增加了時延:為了獲得正確的內容,至少要傳送兩次請求

伺服器驅動

伺服器檢查客戶端的請求首部集並決定提供哪個版本的頁面

比客戶端驅動的協商方式要快。http 提供了 q 值機制,允許伺服器近似匹配,還提供了 vary 首部供伺服器告知下游的裝置如何對請求估值

如果結論不是很明確(比如首部集不匹配),伺服器要做猜測

透明某個中間裝置(通常是快取**)代表客戶端進行請求協商

免除了 web 伺服器的協商開銷。「比客戶端驅動的協商要快

關於如何進行透明協商,還沒有正式的規範

下面就以上三種內容協商技術進行一些介紹。

該種協商技術的基本原理和過程就是:客戶端發起請求的時候,先請求一次伺服器可以提供服務的列表,然後客戶端選擇乙個最合適自己的版本進行請求。這種協商方式,伺服器實現簡單,而且客戶端也能夠尋找到最適合自己的版本,但是缺點也是顯而易見。每次為了獲取乙份內容都需要傳送兩次請求。這樣會給使用者感覺請求速度很慢。

其中具體的實現原理上:伺服器有兩種選擇,一種是直接正常響應乙個html頁面,在裡面包含有各個版本的描述和連線位址。另外一種就是直接返回300 multiple choices 響應**,然後由使用者進行選擇。

這種協商技術,伺服器需要依賴於客戶端在請求中提供足夠多的資訊以便讓伺服器知道該返回什麼版本的內容給客戶端。這種協商技術相較於客戶端驅動的協商,只需要一次請求即可,可以大大降低使用者等待時間。但是主要技術點就在於客戶端怎麼給伺服器提供足夠多的可用於判斷返回版本的資訊。

在http中,提供了不少用於協商內容的頭部集。如下:

首  部

描  述

實體首部

accept

告知伺服器傳送何種**型別

content-type

accept-language

告知伺服器傳送何種語言

content-language

accept-charset

告知伺服器傳送何種字符集

content-type

accept-encoding

告知伺服器採用何種編碼

content-encoding

這裡最後一欄提供了響應資訊中對應的一些實體資訊頭部。一般可以配合客戶端一起使用。

這種協商技術雖然減少了使用者等待時間,提交了效率。但是有個需要解決的問題是:返回的版本不一定是客戶端最適合的版本。比如:伺服器端只有英文、中文兩種語言的內容。但是客戶端給到的accept-language中卻是需要西班牙語,這個時候伺服器可能就不知道應該返回哪個版本了。也行使用者在中文和英文中對英文更加熟悉,那他就可能希望返回英文版本,也有可能對中文更加熟悉呢。這個時候伺服器就需要客戶端提供更多的資訊,用於匹配更加合適的版本。在http中提供了乙個質量值用於描述偏好資訊,如:

accept-language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0

這裡我們為每一種語言定義了乙個q值。用於表示我們的偏好資訊。其中q的取值範圍為(0~1),數值越大,代表優先順序越高,同時該值的對排列順序並沒有要求。比如上述例子中,nl優先順序就要高於en。

透明協商的機制利用中間**實現。假定**了解了客戶端的需要,可以代表客戶端與伺服器進行協商,並將協商後的內容進行快取。下次客戶端在獲取的時候,就能直接提供需要的內容。但是在伺服器這端,為了支援該特性,需要告知**伺服器需要進行哪些請求首部的檢查,以便達到和客戶端進行最佳匹配的目的。http中定義的vary首部即可用於此處的實現。如:

vary: user-agent, cookie

這裡的vary字段說明,需要根據user-agentcookie兩個首部進行內容篩選匹配,最終確定出乙份最合適的文件。

中間**快取為了實現上面的功能,就必須對同乙份內容的不同形式進行快取。比如同乙份文件存在英語和法語兩種語言,中間快取的**就需要更加客戶端的需求快取兩份文件,以便滿足不同客戶端的需求。如果篩選標準在多一些,從不同的緯度進行判斷,如上述的列子。這個時候快取**就需要快取成倍的內容。所以這個也會消耗掉大量測儲存空間。

我們前面討論的都是假設伺服器存在滿足客戶端需求的文件。然而,如果伺服器沒有能滿足客戶端需求的文件會怎麼樣呢?伺服器可以給出乙個錯誤響應。但理論上,伺服器可以把現存的文件轉換成某種客戶端可用的文件。這種選項稱為轉碼。常見的轉碼型別如下:

格式轉換

格式轉換是指將資料從一種格式轉換成另一種格式,使之可以被客戶端檢視。通過 html 到 wml 的轉換,無線裝置就可以訪問通常供桌面客戶端檢視的文件了。通過慢速連線訪問 web 頁面的客戶端並不需要接收高解析度影象,如果通過格式轉換降低影象解析度和顏色來減小影象檔案大小的話,這類客戶端就能更容易地檢視影象比較豐富的頁面了。

資訊綜合

從文件中提取關鍵的資訊片段稱為資訊綜合(information synthesis),這是一種有用的轉碼操作。這種操作的例子包括根據小節標題生成文件的大綱,或者從頁面中刪除廣告和商標。

內容注入

前面描述的兩類轉碼通常會減少 web 文件的內容,但還有另一類轉換會增加文件的內容,即內容注入轉碼。內容注入轉碼的例子有自動廣告生成器和使用者追蹤系統。

現在大多數的web伺服器,也是通過動態注入生成不同的頁面,從而替代以前的單獨儲存各種不同版本的靜態資源。

HTTP權威指南筆記

狀態碼 所有http響應都帶status codes,狀態碼是3位數字,常見狀態碼如200 ok,404 找不到資源 http messages是plain text,純文字,只有request messages與response messages兩種,格式 http messages通過tcp協議...

《HTTP權威指南》筆記

1.8.3 閘道器 2.2.6 查詢字串 只有問號 右邊的內容是查詢內容。其中它們由 分隔。2.2.7 片段 號右邊的是片段內容。http伺服器通常只處理整個物件,而不是物件的片段,客戶端不能將片段傳送給伺服器。瀏覽器從伺服器獲得了整個資源之後,會根據片段來顯示你感興趣的那部分資源。2.4.4 另外...

HTTP權威指南學習筆記

一直以為學習前端只需要掌握js語法 html語法 css就夠了,確實沒有想到還需要很多知識點,今天來細細學習http。乙個http請求由4部分組成 伺服器返回的http相應包含3部分 乙個數字和文字組成的狀態碼,用來顯示請求的成功和失敗 乙個響應頭集合 響應主體 最常用的web伺服器是apache和...