【讀書筆記】圖解 HTTP Chapter 06 HTTP 首部(下)

請求首部字段

請求 header 就是客戶端發送 http 訊息給伺服端所要補充的附加訊息。

請求首部字段

請求 header 就是客戶端發送 http 訊息給伺服端所要補充的附加訊息。

Accept

Accept: text/html, application/xhtml+xml...

這個字串可以告訴伺服器,客戶端需要能處理的媒體類型和相對的優先順序。
使用的是 type/subtype 型式,可以一次指定多種媒體的方式。

  • 文字文件
    • text/html, text/plain, text/css …
  • 圖片文件
    • images/jpeg, image/gif …
  • 影音文件
    • video/mpeg, video/quicktime …
  • 應用程序所使用的二進制文件
    • application/zip …

如果需要優先順序,使用 q= 來表示權重,範圍是0~1,可細分至小數點後三位,並用分號分隔,默認權重是 q=1.0

Accept-Charset

Accept-Charset: iso-8859-5, unicode1-1;q=0.8

這個字串用來通知伺服器客戶端所支援的字串集,及相對順序,一樣可以使用 q 值來表示優先順序。

Accept-Encoding

Accept-Charset: gzip, deflate

這個字串用來通知伺服器客戶端所支援的編碼,及相對順序,可以一次指定多種編碼。

Accept-Language

Accept-Language: zh-cn,zh;q=0.7

這個字串用來通知伺服器客戶端所支援的語言,及相對優先順序,一樣可以使用 q 值來表示優先順序。

Authorization

Authorization: Basic dWVde3fs..

這個字串通常是還告訴伺服器,用戶代理的認證訊息。通常想要通過伺服器的用戶代理收到回傳的 401 狀態碼之後,會把Authorization 加入請求中。共用緩存在接收到 Authorization 的請求操作會有所差異。

Expect

Expect: 100-continue

用戶端用此字串來告訴伺服端,希望伺服端做出某種特別的行為,如果伺服端無法達成就會回傳 417 狀態碼。

Form

Form: info@hacker.jp

這個字串用來告知伺服器用戶代理的用戶電子郵件地址。通常是為了顯示搜尋引擎等的用戶代理負責人的電子郵件聯繫方式,使用代理時盡量用這個字串,但可能因為代理不同而顯示在 User-Agent 中。

Host

這個字串會告訴伺服器,請求的資料所在的網路主機名稱和埠號,在 Http/1.1 中是唯一一個必須要包含在內的字串部。

Host 對於單台伺服器分配多個域名的虛擬主機工作機制有很密切的關係。
請求被發送到伺服器時,請求的主機名會用 IP 位置來替換處理,如果相同 IP 位置下部署多個域名,那個伺服器就會無法了解是哪個對應的域名做請求,因此就需要 host 來指出請求的主機名稱。

If-Match

像是以If-開頭的請求字串,皆為條件請求,伺服器接收到附帶條件請求後,只有判斷的條件為真才會執行請求。

If-Match: "12345"

這個字串會先告訴伺服器 ETag 值,當值與伺服器的相同才會執行請求,如果不同就會回傳 412 狀態碼。

還可以使用星號(*) 指定 If-Match 字串,這時候就會忽略 ETag 值,只要有資料就會進行處理。

If-Modified-Since

這個字串會告訴伺服器,如果 If-Modified-Since 的值早於資料更新的時間,就處理該請求,如果在此日期之後就回傳 304 狀態碼。

If-Modified-Since 是要確認代理與客戶端所有的本地資料的有效性,獲取資料更新的日期和時間可確認伺服端的 Last-Modified 字串。

If-None-Match

這個字串和 If-Match 的作用相反,ETag 值不一致才會處理該請求,在 Get 或 HEAD 方法中使用此字串就可以取得最新的資料。

If-Range

If-Range: "132455"

這個字串告訴伺服器如果指定的 If-Range 值(可能是 ETag 或時間)和請求資料的 ETag 或時間相同,就做範圍請求處理,此時伺服端會回傳 Content-Range 及 Content-Length 字串,如果不是的話就回傳全部資料。

如果不使用 If-Range 的話,伺服器的資料如果更新,那客戶端手上有一部份的資料可能就會無效,這時候伺服端會回傳 412 狀態,目的是催促客戶端再次發送請求。

比較下來不使用 If-Range ,需要耗費兩倍時間。

If-Modified-Since

此字串和 If-Modified-Since 相反,他的作用是告訴伺服器,指定的請求資料只能在值指定的時間後,且沒發生更新的狀況才能處理請求,如果在指定時間後發生更新,就以狀態碼 412 回傳。

Max-Forwards

Max-Forwards: 10

藉由 Trace 或 option 方法,發送包含這個字串的請求時,這個字串以十進位整數的方式指定可經過伺服器最大數目,伺服器在轉發請求給下個伺服器前,會將 Max-Forwards 的值減一之後再重新賦值,當收到 Max-Forwards 的值為 0 後,就不再進行轉發請求。

需要這樣是因為當 HTTP 通訊的時候,請求可能會經過多台代理伺服器,如果這些代理伺服器因為某些原因而請求轉發失敗,客戶端就無從得知,所以必須通過此字串來追蹤請求。

Proxy-Authorization

接到從代理伺服器的憑證,客戶端會發送此字串 Proxy-Authorization 的請求,以告知伺服器憑證所需要的資訊。

這個動作和客戶端與伺服器之間的 HTTP 訪問認證相似,但差別在這是發生在客戶端與代理之間。

Range

對於要獲取部分資料的範圍請求,Range 可以告訴伺服器指定的範圍。

接收到 Range 字串請求的伺服器,會在處理請求後回傳 206 狀態碼,如果無法處理就會回傳所有資料及 200 狀態碼。

Referer

這個字串是告訴伺服器原始資料的 URI。客戶端一般來說都會發送 Referer 字串,但直接在瀏覽器地址輸入 URI,基於安全也可以不發此字串。

因為原始資料的 URI 的查詢字串也可能含有 ID 和密碼等重要資訊,如果寫進 Referer 轉發給其他伺服器可能會造成保密訊息外洩。

TE

這個字串主要告知伺服器,客戶端能夠處理回應的傳輸編碼方式及優先順序,他和 Accept-Encoding 的功能很像,但是用在傳輸編碼。

除了指定編碼外,他還可以指定伴隨的 trailer 分快傳輸編碼的方式,應用後者只需要把 trailer 賦值給該字串。

User-Agent

用於傳達瀏覽器種類,User-Agent 會建立請求瀏覽器和用戶代理等等訊息給伺服端。

如果由網路爬蟲請求,可能會在這個字串被加上爬蟲作者的電子郵件,如果請求經過代理,那也可能會被加上代理伺服器的名稱。

響應首部字段

回應 header 就是伺服端發送 http 訊息給客戶端所要補充的附加訊息。

Accept-Ranges

Accept-Ranges: byte

此字串是用來告知客戶端是用來告知客戶端是否能進行範圍請求,可處理的話,該值為 byte 不能處理的話該值為 none

Age

Age: 600

這個字串可以告訴客戶端,來源伺服器在多久以前建立回應資料。
如果建立資料的是緩存伺服器,那麼 Age 值就是指緩存後的回應資料再發出認證到認證完成的時間值,另外代理伺服器如果建立回應資料,一定要加上此字串值。單位為秒。

Etag

Etag: "82e24848424..."

這個字串可以告訴客戶端實體標記。他是一種把資料已字串形式作為一標記的方式,伺服器會為了每一份資料分配對應的 Etag。

而當資料更新時,Etag 也必須要更新,產生 Etag 並沒有固定的計算方法,只是由伺服端分配。

比方說,同個網站可能有中文版和英文版的資料,那他們都是用同個 URI 資料,這時候伺服端就只能依照 Etag 值給客戶端對應的資料。

強 Etag 與弱 Tag

而在 Etag 中,有分強 Etag 與弱 Tag。

E-tag: "usagi-1234"

強 Etag,無論實體發生多細微的變化都會更改值。

E-tag: "W/usagi-1234"

弱 tag,只用來提示資料是否相同,只有資料發生根本的改變而產生差異才會改變 E-tag 值,這時候就會在前面加上W/

Location

Location: http://codingwife.com

Location 可以將回應接收方引導到某個 URL 位置上的不同資料,基本上該字串會配合 3xx: Redirection 的回應來重新導向 URI。

幾乎所有瀏覽器在接收此字串的回應後,都會強制性嘗試訪問重新導向資料。

Proxy-Authenticate

這個字串會把代理伺服器所要求的認證訊息發送給客戶端。

這個和客戶端與伺服端之間在發送 HTTP 傳輸的模式類似,只不過這個對象換成客戶端與代理伺服器,而在認證時 WWW-Authenticatea 字串也會有一樣的作用。

Retry-After

Retry-After: 120

這個字串告訴客戶端多久以後再次發送請求,主要是配合 503 或 3xx 狀態一起使用。值可以指定日期,或是建立回應資料後的秒數。

Server

這個字串告訴客戶端目前伺服器上安裝的 HTTP 伺服器程式的訊息,除了軟體名稱外,還可能包括版本和安裝時的選項。

Vary

這個字串可以對緩存進行控制,來源伺服器會向代理伺服器傳達關於本地緩存使用方法命令。

從代理伺服器接收到來源伺服器包含此字串的回應之後,如要再進行緩存,僅對請求含有相同 Vary 的請求回傳緩存。即使對相同資料發起請求,如果 Vary 值不相同,就要重新再從來源伺服器取得資料。

WWW-Authenticate

此字串用於 HTTP 訪問,他會告訴客戶端適用於訪問請求 URI 指定資料的認證方案和帶參數提示的質詢。此字串會包含在回傳 401 狀態回應中。

實體首部字段

這是包含請求和回應訊息的實體部分,所用來補充內容或相關訊息的字串。

Allow

Allow: GET, HEAD

此字串通知客戶端能夠支援的 Request-URI 指定資料的所有 HTTP 方法。

當伺服器收到不支援的 HTTP 方法,會回傳 405 狀態碼,除此之外還會把所有支援的 HTTP 方法寫進此字段。

Content-Encoding

Content-Encoding: gzip

此字串會告知客戶端伺服器對實體主體的部分選用的內容編碼,內容編碼就是在不遺失實體訊息的狀況下所做的壓縮。

主要採用以下四種編碼:

  • gzip
  • compress
  • deflate
  • identity

Conten-Language

此字串告訴客戶端,實體主體主要用的自然語言。

Content-Length

此字串表明實體主體的大小(單位字節)。
對實體主體進行內容編碼傳輸時,就不能再用此字段,因為主體大小的計算方式比較複雜,詳細可參考 RFC2616 的 4.4。

Content-Location

此字段給訊息主體相對應的 URI,與 Location 不同的點在於,此字串表示的是訊息主體回傳資料對應的 URI。

假設使用 Accept-Language 的伺服器發送請求,而回傳的頁面和實際請求的對象不同時,此字串就會寫明對應的 URI。

Content-MD5

此字串的值是由 MD5 算法生成的值,目的在用來檢查主體傳輸過程是否完整,以及再確認是否有傳送到。

對訊息主體執行 MD5 算法,得到會是 128 位元的二進制數字,再通過 Base 64 編碼後寫進此字段。因為 HTTP 字段沒辦法紀錄二進制值,所以需要通過 Base 64 編碼處理,而客戶端會再對訊息主體執行相同的 MD5 算法,比較過後就可以知道訊息的正確性。

這種做法的缺點是無法發現內容有偶發性的改變,或是否被惡意竄改。

Content-Range

Content-Range: bytes 5001-10000/10000

此字串為針對範圍請求,回傳回應所使用,可以告訴客戶端回傳的實體哪個部分符合範圍請求,以字節為單位,表示當前發送部分及整個實體的大小。

Content-Type

此字串說明了實體內的媒體類型,與 Accept 相同使用 type/subtype 的形式。

Expires

這個字段會告訴客戶端資料的失效日期,緩存伺服器在接收此字串的回應之後,會以緩存來回覆此請求。在此字串值的時間以前,回傳的資料副本會一直留存,而當超過指定的時間後,緩存伺服器會轉向跟來源伺服器來請求有效資料。

來源伺服器不希望緩存伺服器對資料進行緩存時,最好在此字串內寫和 header 的 Date 一樣的時間,但是當 Cache-Control 有指定 max-age 時,比起此字串,他會先處理 max-age 的指令。

Last-Modified

此字串指定資料最後修改的時間,一般來說就是 Requst-URI 指定資料被修改的時間,但進行動態資料處理時,此字串可能會變成資料最後修改的時間。

管理伺服器和客戶端之間狀態的 Cookie ,雖還沒有被 HTTP / 1.1 的 RFC2616 列為標準,但在一般網站已經有廣泛應用。

Cookie 的目的是為了用戶識別和狀態管理,網站為了管理客戶狀態,會透過瀏覽器把資料臨時寫到客戶端的電腦,而客戶端再訪問網站時,就可通過通訊方式取回之前發的 Cookie。

呼叫 Cookie 時,可以檢驗 Cookie 的有效期,以及發送端的網域、路徑等等訊息,所以標準的 Cookie 內的資料不會因來自其他網路和攻擊者的攻擊而洩漏。

Cookie 規格的標準文件有以下:

  • 網景公司發布的規格標準
  • RFC2109
  • RFC2965
  • RFC6265

目前最常用的就是 RFC6265,所以接下來以此規格來說。

Cookie 有兩個字串:

  • Set-Cookie:開始狀態管理所用的 Cookie 訊息。
  • Cookie:伺服端收到的 Cookie 訊息。

當伺服器開始管理客戶端的狀態,會事先告知各種訊息:
|屬性|說明|
|—|—|
|NAME=VALUE|賦予 Cookie 的名稱和值(必須)|
|expires=DATE|Cookie 的有效期(如果沒有指點,默認值就是以瀏覽器關閉為止)|
|path=PATH|伺服器上的文件目錄作為 Cookie 適用的物件(如果沒有指點,默認值就是以所在文件的文件目錄)|
|domain=域名|Cookie 適用物件的域名(如果沒有指點,默認值就是以創建 Cookie 的伺服器的域名)|
|Secure|僅在 HTTP 安全通訊才會發送 Cookie|
|HttpOnly|做限制,不能在 JavaScript 腳本訪問|

expires 屬性

  • expires 可以發送 Cookie 的有效期
  • 沒有指定,默認就是瀏覽器關閉之前
  • 一旦 Cookie 從伺服器發送到客戶端,伺服器就不存在可以顯示刪除 Cookie 的方法,但可以通過覆蓋已經過期的 Cookie,一樣可以達到對於客戶端 Cookie 刪除的操作。

path 屬性

可用於限制指定 Cookie 的發送範圍的文件目錄,不過另外有方法可以避開這個限制。

domain

通過 Cookie 的 domain 屬性指定的域名可以做到結尾配對相同。
比方說指定 codingwife.com ,www.codingwife.com 或 www2.codingwife.com 之類的都可以發送 Cookie。

除了指定多個域名發送 Cookie 之外,不指定 domain 更顯得安全。

secure

Set-Cookie: name=value; secure

Cookie 的 secure 僅在 HTTPS 或 SSL 安全連接時,才可會被發送到伺服器。

HttpOnly

這個屬性主要防止 cookie 的擴展功能,它讓 JavaScript 腳本沒辦法取得 Cookie,主要為了防止 XSS 攻擊對 Cookie 的竊取。

此字串告訴伺服器,當客戶端想取得 HTTP 狀態管理支援時,就會從請求中包含從伺服器接收到的 Cookie。

其他首部字段

HTTP header 可以自行擴展,所以在瀏覽器上會出現一些非標準的字串,以下就幾種最常用的來做說明。

X-Frame-Options

X-Frame-Options: DENY

此字串是回應 header,控制網站內容在其他網站的 Frame 標籤的顯示問題,主要為了防止點擊劫持。

以下有兩個可以指定的值:

  • DENY:拒絕
  • SAMEORIGIN:僅同源域名下的頁面配對許可。
    • 舉例:如果指定 codingwife.com 頁面是 SAMEORIGIN,那麼 codingwife.com 下的 frame 都允許可載入該頁面,而其他域名就不行。

X-XSS-Protection

此字串是回應 header,這是一個控制 XSS 對策的一個字串,用於控制瀏覽器 XSS 防護機制的開關。

  • 0:將 XSS 過濾設置成無效狀態
  • 1:將 XSS 過濾設置成有效狀態

DNT

此字串是請求 header,意思是拒絕個人訊息被收集,表示拒絕被精準廣告追蹤的一種方法。

  • 0:同意被追蹤。
  • 1:拒絕被追蹤。

這個字串必須要有伺服端對應的支援。

P3P

通過這個技術,可以讓網站上的個人隱私變成一種可以提供程式理解的形式,以保護用戶端隱私。

  1. 建立 P3P 隱私
  2. 建立對照文件後,保存命名在 w3c/p3p.xml 中。
  3. 從 P3P 隱私中建立 Compact policies,輸出到 HTTP 回應中。

    資料來源:《圖解 HTTP》 上野宣 人民郵電出版社
    筆記純屬推廣及分享,如有侵權,請告知。
    Please advise to remove immediately if any infringement caused.

【讀書筆記】圖解 HTTP Chapter 06 HTTP 首部(上) 【讀書筆記】圖解 HTTP Chapter 05 與 HTTP 協作的網頁伺服器

評論

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×