自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

你還在為 HTTP 的這些概念頭疼嗎？

作者：cxuan
安全
HTTP 通用標(biāo)頭之所以這樣命名，是因?yàn)榕c其他三個(gè)類(lèi)別不同，它們不是限定于特定種類(lèi)的消息或者消息組件(請(qǐng)求，響應(yīng)或消息實(shí)體)的。HTTP 通用標(biāo)頭主要用于傳達(dá)有關(guān)消息本身的信息，而不是它所攜帶的內(nèi)容。它們提供一般信息并控制如何處理和處理消息。

[[313442]]

HTTP 標(biāo)頭

先來(lái)回顧一下 HTTP1.1 標(biāo)頭都有哪幾種

HTTP 1.1 的標(biāo)頭主要分為四種，通用標(biāo)頭、實(shí)體標(biāo)頭、請(qǐng)求標(biāo)頭、響應(yīng)標(biāo)頭，現(xiàn)在我們來(lái)對(duì)這幾種標(biāo)頭進(jìn)行介紹

通用標(biāo)頭

HTTP 通用標(biāo)頭之所以這樣命名，是因?yàn)榕c其他三個(gè)類(lèi)別不同，它們不是限定于特定種類(lèi)的消息或者消息組件(請(qǐng)求，響應(yīng)或消息實(shí)體)的。HTTP 通用標(biāo)頭主要用于傳達(dá)有關(guān)消息本身的信息，而不是它所攜帶的內(nèi)容。它們提供一般信息并控制如何處理和處理消息。

盡管通用標(biāo)頭不會(huì)限定于是請(qǐng)求還是響應(yīng)報(bào)文，但是某些通用標(biāo)頭大部分或全部用于一種特定類(lèi)型的請(qǐng)求中。也就是說(shuō)，如果某個(gè)通用標(biāo)頭出現(xiàn)在請(qǐng)求報(bào)文中，那么大部分通用標(biāo)頭都會(huì)顯示在該請(qǐng)求報(bào)文中。響應(yīng)報(bào)文也是一樣的。

先列出來(lái)一個(gè)清單，講明我們都需要介紹哪些通用標(biāo)頭

  • Cache-Control
  • Connection
  • Date
  • Pragma
  • Trailer
  • Transfer-Encoding
  • Upgrade
  • Via
  • Warning

Cache-Control

緩存(Cache)是計(jì)算機(jī)領(lǐng)域里的一個(gè)重要概念，是優(yōu)化系統(tǒng)性能的利器。不僅計(jì)算機(jī)中的 CPU 為了提高指令執(zhí)行效率從而選擇使用寄存器作為輔助，計(jì)算機(jī)網(wǎng)絡(luò)同樣存在緩存，下面我們就來(lái)介紹一下計(jì)算機(jī)網(wǎng)絡(luò)中的緩存。

Cache-Control 是通用標(biāo)頭的指令，它能夠管理如何對(duì) HTTP 的請(qǐng)求或者響應(yīng)使用緩存。

因?yàn)橛?jì)算機(jī)網(wǎng)絡(luò)中是可以有第三者出現(xiàn)的，也就是緩存服務(wù)器，這個(gè)指令通過(guò)影響請(qǐng)求/響應(yīng)中的緩存服務(wù)器從而達(dá)到控制緩存的目的;不僅有緩存服務(wù)器，還有瀏覽器內(nèi)部緩存也會(huì)影響鏈路的緩存。

這個(gè)標(biāo)頭中可以出現(xiàn)許多單獨(dú)的指令，其詳細(xì)信息可以在 RFC 2616 中找到，即使這是常規(guī)標(biāo)頭，某些指令也只能出現(xiàn)在請(qǐng)求或響應(yīng)中。下表提供了一個(gè) Cache-Control 選項(xiàng)的總結(jié)并告訴你如何去使用

“請(qǐng)注意，在 Cache-Control 標(biāo)頭中只能出現(xiàn)一個(gè)指令，但是在消息中可以出現(xiàn)多個(gè)這樣的標(biāo)頭。

 

上面這個(gè)表格其實(shí)會(huì)有四種分類(lèi)

  • 可緩存性：它們分別是 no-cache、no-store、private 和 public
  • 緩存有效性時(shí)間：它們分別是 max-age、s-maxage、max-stale、min-fresh
  • 重新驗(yàn)證并重新加載：它們分別是 must-revalidate 和 proxy-revalidate
  • 其他：它們分別是 only-if-cached 和 no-transform

分別對(duì)表格中的內(nèi)容進(jìn)行一下詳細(xì)介紹

no-cache

no-cache 很容易和 no-store 混淆，一般都會(huì)把 no-cache 認(rèn)為是不緩存，其實(shí)不是這樣。

使用 no-cache 指令的目的是為了防止從緩存中返回過(guò)期的資源，例如下圖所示

Cache-Control: no-cache

 

舉個(gè)例子你就明白了，No-Cache 就相當(dāng)于是吃著碗里的，占著鍋里的，如果鍋里還有新的肉片，就先吃鍋里的，如果鍋里沒(méi)有新的，再吃自己的，這里鍋里的就相當(dāng)于是源服務(wù)器產(chǎn)生的，碗里的就相當(dāng)于是緩存的。

no-store

no-store 才是真正意義上的不緩存，每次服務(wù)器接受到客戶(hù)端的請(qǐng)求后，都會(huì)返回最新的資源給客戶(hù)端。

  1. Cache-Control: no-store 

max-age

max-age 可以用在請(qǐng)求或者響應(yīng)中，當(dāng)客戶(hù)端發(fā)送帶有 max-age 的指令時(shí)，緩存服務(wù)器會(huì)判斷自己緩存時(shí)間的數(shù)值和 max-age 的大小，如果比 max-age 小，那么緩存有效，可以繼續(xù)給客戶(hù)端返回緩存的數(shù)據(jù)，如果比 max-age 大，那么緩存服務(wù)器將不能返回給客戶(hù)端緩存的數(shù)據(jù)。

  1. Cache-Control: max-age=60 

如果 max-age = 0，那么緩存服務(wù)器將會(huì)直接把請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)器

  1. Cache-Control: max-age=0 

“注意：這個(gè) max-age 的值是相對(duì)于請(qǐng)求時(shí)間的

must-revalidate

表示一旦資源過(guò)期，緩存就必須在原始服務(wù)器上沒(méi)有成功驗(yàn)證的情況下才使用其過(guò)期的數(shù)據(jù)。

  1. Cache-Control: must-revalidate 

no-store 、no_cache 、 must-revalidate 和 max-age 可以一起看，下面是一個(gè)這四個(gè)標(biāo)頭的流程圖

 

public

public 屬性只出現(xiàn)在客戶(hù)端響應(yīng)中，表示響應(yīng)可以被任何緩存所緩存。在計(jì)算機(jī)網(wǎng)絡(luò)中，分為兩種緩存，共享緩存和私有緩存，如下所示

  1. Cache-Control: public 

 

private

當(dāng)指定 private 指令后，響應(yīng)只以特定的用戶(hù)作為對(duì)象，這與 public 的用法相反，緩存服務(wù)器只對(duì)特定的客戶(hù)端進(jìn)行緩存，其他客戶(hù)端發(fā)送過(guò)來(lái)的請(qǐng)求，緩存服務(wù)器則不會(huì)返回緩存。

  1. Cache-Control: private 

 

s-maxage

s-maxage 指令的功能和 max-age 指令的功能相同，不同點(diǎn)之處在于 s-maxage 不能用于私有緩存，只能用于多用戶(hù)使用的公共服務(wù)器，對(duì)于同一用戶(hù)的重復(fù)請(qǐng)求和響應(yīng)來(lái)說(shuō)，這個(gè)指令沒(méi)有任何作用。

  1. Cache-Control: s-maxage=60 

min-fresh

min-fresh只能出現(xiàn)在請(qǐng)求中，min-fresh 要求緩存服務(wù)器返回 min-fresh 時(shí)間內(nèi)的緩存數(shù)據(jù)。例如 Cache-Control:min-fresh=60，這就要求緩存服務(wù)器發(fā)送60秒內(nèi)的數(shù)據(jù)。

  1. Cache-Control: min-fresh=60 

max-stable

max-stable 只能出現(xiàn)在請(qǐng)求中，表示客戶(hù)端會(huì)接受緩存數(shù)據(jù)，即使過(guò)期也照常接收。

  1. Cache-Control: max-stable=60 

only-if-cached

這個(gè)標(biāo)頭只能出現(xiàn)在請(qǐng)求中，使用 only-if-cached 指令表示客戶(hù)端僅在緩存服務(wù)器本地緩存目標(biāo)資源的情況下才會(huì)要求其返回。

  1. Cache-Control: only-if-cached 

proxy-revalidate

proxy-revalidate 指令要求所有的緩存服務(wù)器在接收到客戶(hù)端帶有該指令的請(qǐng)求返回響應(yīng)之前，必須再次驗(yàn)證緩存的有效性。

  1. Cache-Control: proxy-revalidate 

no-transform

使用 no-transform 指令規(guī)定無(wú)論是在請(qǐng)求還是響應(yīng)中，緩存都不能改變實(shí)體主體的媒體類(lèi)型。

  1. Cache-Control: no-transform 

Connection

HTTP 協(xié)議使用 TCP 來(lái)管理連接方式，主要有兩種連接方式，持久性連接 和 非持久性連接。

持久性連接

持久性連接指的是一次會(huì)話(huà)完成后，TCP 連接并未關(guān)閉，第二次再次發(fā)送請(qǐng)求后，就不再需要建立 TCP 連接，而是可以直接進(jìn)行請(qǐng)求和響應(yīng)。它的一般表示形式如下

  1. Connection: keep-alive 

從 HTTP 1.1 開(kāi)始，默認(rèn)使用持久性連接。

keep-alive 也是一個(gè)通用標(biāo)頭，一般 Connection 都會(huì)和 keep-alive 一起使用，keep-alive 有兩個(gè)參數(shù)，一個(gè)是 timeout;另一個(gè)是 max，它們的主要表現(xiàn)形式如下

  1. Connection: Keep-Alive 
  2. Keep-Alive: timeout=5, max=1000 
  • timeout: 指的是空閑連接必須打開(kāi)的最短時(shí)間，也就是說(shuō)這次請(qǐng)求的連接時(shí)間不能少于5秒，
  • max: 指的是在連接關(guān)閉之前服務(wù)器所能夠收到的最大請(qǐng)求數(shù)。

非持久性連接

非持久性連接表示一次會(huì)話(huà)請(qǐng)求/響應(yīng)后關(guān)閉連接的方式。HTTP 1.1 之前使用的連接都是非持久連接，也就是

  1. Connection: close 

Date

Date 是一個(gè)通用標(biāo)頭，它可以出現(xiàn)在請(qǐng)求標(biāo)頭和響應(yīng)標(biāo)頭中，它的基本表示如下

  1. Date: Wed, 21 Oct 2015 07:28:00 GMT 

表示的是格林威治標(biāo)準(zhǔn)時(shí)間，這個(gè)時(shí)間要比北京時(shí)間慢八個(gè)小時(shí)

 

Pragma

Pragma是 http 1.1 之前版本的歷史遺留字段，僅作為與 http 的向后兼容而定義。它的一般形式如下

  1. Pragma: no-cache 

只用于客戶(hù)端發(fā)送的請(qǐng)求中。客戶(hù)端會(huì)要求所有的中間服務(wù)器不返回緩存的資源。

如果所有的中間服務(wù)器都以實(shí)現(xiàn) HTTP /1.1為標(biāo)準(zhǔn)，那么直接使用 Cache-Control: no-cache 即可，如果不是的話(huà)，就要包含兩個(gè)字段，如下

  1. Cache-Control: no-cache 
  2. Pragma: no-cache 

Trailer

首部字段 Trailer 會(huì)事先說(shuō)明在報(bào)文主體后記錄了哪些首部字段。該首部字段可應(yīng)用在 HTTP/1.1 版本分塊傳輸編碼時(shí)。一般用法如下

  1. Transfer-Encoding: chunked 
  2. Trailer: Expires 

以上用例中，指定首部字段 Trailer 的值為 Expires，在報(bào)文主體之后(分塊長(zhǎng)度 0 之后)出現(xiàn)了首部字段 Expires。

Transfer-Encoding

Transfer-Encoding 屬于內(nèi)容協(xié)商的范疇，下面會(huì)具體介紹一下內(nèi)容協(xié)商，現(xiàn)在先做個(gè)預(yù)告：Transfer-Encoding 規(guī)定了傳輸報(bào)文所采用的編碼方式

“注意：HTTP 1.1 的傳輸編碼方式僅對(duì)分塊傳輸有效，但是 HTTP 2.0 就不再支持分塊傳輸，而提供了自己更有效的數(shù)據(jù)傳輸機(jī)制。

  1. Transfer-Encoding: chunked 

Transfer-Encoding 也屬于 Hop-by-hop(逐跳) 首部 ，下面來(lái)回顧一下，HTTP 報(bào)文標(biāo)頭除了可以根據(jù)屬性所在的位置分為 通用標(biāo)頭、請(qǐng)求標(biāo)頭、響應(yīng)標(biāo)頭 和 實(shí)體標(biāo)頭;還可以按照是否被緩存分為 端到端首部(End-to-End) 和 逐跳首部(Top-to-Top)。

除了下面八種屬于逐跳首部外，其余都屬于端到端首部

Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade

下面回到討論中來(lái)，Transfer-Encoding 用于兩個(gè)節(jié)點(diǎn)之間傳輸消息，而不是資源本身。在多個(gè)節(jié)點(diǎn)傳輸消息的過(guò)程中，每一段消息的傳輸都可以使用不同的 Transfer-Encoding。如圖所示

 

Transfer-Encoding 支持文件壓縮，如果你想要以文件壓縮后的形式發(fā)送的話(huà)。Transfer-Encoding 所有可選類(lèi)型如下

  • chunked：數(shù)據(jù)按照一系列塊發(fā)送，在這種情況下，將省略 Content-Length 標(biāo)頭，并在每個(gè)塊的開(kāi)頭，需要以十六進(jìn)制填充當(dāng)前塊的長(zhǎng)度，后跟 '\r\n'，然后是塊本身，然后是另一個(gè)'\r\n'。當(dāng)將大量數(shù)據(jù)發(fā)送到客戶(hù)端并且在請(qǐng)求已被完全處理之前，可能無(wú)法知道響應(yīng)的總大小時(shí)，分塊編碼很有用。例如，在生成由數(shù)據(jù)庫(kù)查詢(xún)產(chǎn)生的大型 HTML 表時(shí)或在傳輸大型圖像時(shí)。分塊的響應(yīng)看起來(lái)像這樣
  1. HTTP/1.1 200 OK 
  2. Content-Type: text/plain 
  3. Transfer-Encoding: chunked 
  4.  
  5. 7\r\n 
  6. Mozilla\r\n 
  7. 9\r\n 
  8. Developer\r\n 
  9. 7\r\n 
  10. Network\r\n 
  11. 0\r\n 
  12. \r\n 

終止塊通常是0。緊隨Transfer-Encoding 后面的是 Trailer 標(biāo)頭， Trailer 可能為空。

  • compress：使用 Lempel-Ziv-Welch(LZW) 算法的格式。值名稱(chēng)取自 UNIX 壓縮程序，該程序?qū)崿F(xiàn)了該算法?，F(xiàn)在幾乎沒(méi)有瀏覽器使用這種內(nèi)容編碼了，因?yàn)檫@個(gè)專(zhuān)利在 2003 年就停掉了。
  • deflate：使用 zlib(在 RFC 1950 定義) 結(jié)構(gòu)和 deflate 壓縮算法
  • gzip：使用Lempel-Ziv編碼(LZ77)和32位CRC的格式。這最初是 UNIX gzip 程序的格式。HTTP / 1.1標(biāo)準(zhǔn)還建議出于兼容性目的，支持此內(nèi)容編碼的服務(wù)器應(yīng)將 x-gzip 識(shí)別為別名。
  • identity：使用身份功能(即無(wú)壓縮或修改)。

也可以列出多個(gè)值，以逗號(hào)分隔，類(lèi)似一個(gè)集合列表

  1. Transfer-Encoding: gzip, chunked 

Upgrade

首部字段 Upgrade 用于檢測(cè) HTTP 協(xié)議及其他協(xié)議是否可使用更高的版本進(jìn)行通信，其參數(shù)值可以用來(lái)指定一個(gè)完全不同的通信協(xié)議。

 

上圖用例中，首部字段 Upgrade 指定的值為 TLS/1.0。請(qǐng)注意此處兩個(gè)字段首部字段的對(duì)應(yīng)關(guān)系，Connection 的值被指定為 Upgrade。Upgrade 首部字段產(chǎn)生作用的對(duì)象僅限于客戶(hù)端和臨近服務(wù)器之間。因此，使用首部字段 Upgrade 時(shí)，還需要額外指定 Connection: Upgrade。對(duì)于附有首部字段 Upgrade 的請(qǐng)求，服務(wù)器可用 101 Switching Protocols 狀態(tài)碼作為響應(yīng)返回。

Via

使用 Via 是為了跟蹤客戶(hù)端和服務(wù)器之間的請(qǐng)求/響應(yīng)路徑，避免請(qǐng)求循環(huán)以及能夠識(shí)別請(qǐng)求/響應(yīng)鏈中發(fā)送者協(xié)議的功能。Via 字段由代理服務(wù)器添加，不論是正向代理還是反向代理，并且可以出現(xiàn)在請(qǐng)求標(biāo)頭和響應(yīng)標(biāo)頭中。它用于跟蹤消息轉(zhuǎn)發(fā)。例如下圖所示

 

Via 后面的的 1.1, 1.0 表示接收服務(wù)器上的 HTTP 版本，Via 首部是為了跟蹤路徑，經(jīng)常和TRACE 方法一起使用。

Warning

“注意：Warning 字段即將被棄用查閱 Warning (https://github.com/httpwg/http-core/issues/139) and Warning: header & stale-while-revalidate (https://github.com/whatwg/fetch/issues/913) 獲取更多細(xì)節(jié)

Warning 通用 HTTP 標(biāo)頭通常會(huì)告知用戶(hù)一些與緩存相關(guān)的問(wèn)題的警告

HTTP/1.1 中定義了 7 種警告。它們分別如下

 

請(qǐng)求標(biāo)頭

請(qǐng)求標(biāo)頭用于客戶(hù)端發(fā)送 HTTP 請(qǐng)求到服務(wù)器中所使用的字段，下面我們一起來(lái)看一下 HTTP 請(qǐng)求標(biāo)頭都包含哪些字段，分別是什么意思。下面會(huì)介紹

  • Accept
  • Accept-Charset
  • Accept-Encoding
  • Accept-Language
  • Authorization
  • Expect
  • From
  • Host
  • If-Match
  • If-Modified-Since
  • If-None-Match
  • If-Range
  • If-Unmodified-Since
  • Max-Forwards
  • Proxy-Authorization
  • RangeReferer
  • TE
  • User-Agent

下面分別來(lái)介紹一下

Accept

HTTP 請(qǐng)求標(biāo)頭會(huì)告知客戶(hù)端能夠接收的 MIME 類(lèi)型是什么

那么什么是 MIME 類(lèi)型呢?在回答這個(gè)問(wèn)題前你應(yīng)該先了解一下什么是 MIME

“MIME: MIME (Multipurpose Internet Mail Extensions) 是描述消息內(nèi)容類(lèi)型的因特網(wǎng)標(biāo)準(zhǔn)。MIME 消息能包含文本、圖像、音頻、視頻以及其他應(yīng)用程序?qū)Ｓ玫臄?shù)據(jù)。

也就是說(shuō)，MIME 類(lèi)型其實(shí)就是一系列消息內(nèi)容類(lèi)型的集合。那么 MIME 類(lèi)型都有哪些呢?

文本文件：text/html、text/plain、text/css、application/xhtml+xml、application/xml

圖片文件：image/jpeg、image/gif、image/png

視頻文件：video/mpeg、video/quicktime

應(yīng)用程序二進(jìn)制文件：application/octet-stream、application/zip

比如，如果瀏覽器不支持 PNG 圖片的顯示，那 Accept 就不指定image/png，而指定可處理的 image/gif 和 image/jpeg 等圖片類(lèi)型。

一般 MIME 類(lèi)型也會(huì)和 q 這個(gè)屬性一起使用，q 是什么?q 表示的是權(quán)重，來(lái)看一個(gè)例子

  1. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 

這是什么意思呢?若想要給顯示的媒體類(lèi)型增加優(yōu)先級(jí)，則使用 q= 來(lái)額外表示權(quán)重值，沒(méi)有顯示權(quán)重的時(shí)候默認(rèn)值是1.0 ，我給你列個(gè)表格你就明白了

 

也就是說(shuō)，這是一個(gè)放置順序，權(quán)重高的在前，低的在后，application/xml;q=0.9 是不可分割的整體。

Accept-Charset

Accept-Charset 表示客戶(hù)端能夠接受的字符編碼。Accept-Charset 也是屬于內(nèi)容協(xié)商的一部分，它和

Accept 一樣，也可以用 q 來(lái)表示字符集，用逗號(hào)進(jìn)行分割，例如

  1. Accept-Charset: iso-8859-1 
  2. Accept-Charset: utf-8, iso-8859-1;q=0.5 
  3. Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1 

“事實(shí)上，很多以 Accept-* 開(kāi)頭的標(biāo)頭，都是屬于內(nèi)容協(xié)商的范疇，關(guān)于內(nèi)容協(xié)商我們下面會(huì)說(shuō)。

Accept-Encoding

表示 HTTP 標(biāo)頭會(huì)標(biāo)明客戶(hù)端希望服務(wù)端返回的內(nèi)容編碼，這通常是一種壓縮算法。Accept-Encoding 也是屬于內(nèi)容協(xié)商 的一部分，使用并通過(guò)客戶(hù)端選擇 Content-Encoding 內(nèi)容進(jìn)行返回。

即使客戶(hù)端和服務(wù)器都能夠支持相同的壓縮算法，服務(wù)器也可能選擇不壓縮并返回，這種情況可能是由于這兩種情況造成的:

  • 要發(fā)送的數(shù)據(jù)已經(jīng)被壓縮了一次，第二次壓縮并不會(huì)導(dǎo)致發(fā)送的數(shù)據(jù)更小
  • 服務(wù)器過(guò)載，無(wú)法承受壓縮帶來(lái)的性能開(kāi)銷(xiāo)，通常，如果服務(wù)器使用 CPU 超過(guò) 80% ，Microsoft 則建議不要使用壓縮

下面是 Accept-Encoding 的使用方式

  1. Accept-Encoding: gzip 
  2. Accept-Encoding: compress 
  3. Accept-Encoding: deflate 
  4. Accept-Encoding: br 
  5. Accept-Encoding: identity 
  6. Accept-Encoding: * 
  7. Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5 

上面的幾種表述方式就已經(jīng)把 Accept-Encoding 的屬性列全了

  • gzip: 由文件壓縮程序 gzip 生成的編碼格式，使用 Lempel-Ziv編碼(LZ77)和32位CRC的壓縮格式，感興趣的同學(xué)可以讀一下 (https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77)
  • compress: 使用Lempel-Ziv-Welch(LZW)算法的壓縮格式，有興趣的同學(xué)可以讀 (https://en.wikipedia.org/wiki/LZW)
  • deflate: 使用 zlib 結(jié)構(gòu)和 deflate 壓縮算法的壓縮格式，參考 (https://en.wikipedia.org/wiki/Zlib) 和 (https://en.wikipedia.org/wiki/DEFLATE)
  • br: 使用 Brotli 算法的壓縮格式，參考 (https://en.wikipedia.org/wiki/Brotli)
  • 不執(zhí)行壓縮或不會(huì)變化的默認(rèn)編碼格式
  • * : 匹配標(biāo)頭中未列出的任何內(nèi)容編碼，如果沒(méi)有列出 Accept-Encoding ，這就是默認(rèn)值，并不意味著支
  • 持任何算法，只是表示沒(méi)有偏好
  • ;q= 采用權(quán)重 q 值來(lái)表示相對(duì)優(yōu)先級(jí)，這點(diǎn)與首部字段 Accept 相同。

Accept-Language

Accept-Language 請(qǐng)求表示客戶(hù)端需要服務(wù)端返回的語(yǔ)言類(lèi)型，Accept-Language 也屬于內(nèi)容協(xié)商的范疇。服務(wù)端通過(guò) Content-Language 進(jìn)行響應(yīng)，和 Accept 首部字段一樣，按權(quán)重值 q來(lái)表示相對(duì)優(yōu)先級(jí)。例如

  1. Accept-Language: de 
  2. Accept-Language: de-CH 
  3. Accept-Language: en-US,en;q=0.5 

Authorization

HTTP Authorization 請(qǐng)求頭用于向服務(wù)器認(rèn)證用戶(hù)代理的憑據(jù)，通常用在服務(wù)器以401未經(jīng)授權(quán)狀態(tài)和WWW-Authenticate標(biāo)頭響應(yīng)之后，啥意思呢?你不明白的話(huà)我畫(huà)張圖給你看

 

請(qǐng)求標(biāo)頭 Authorization 是用來(lái)告知服務(wù)器，用戶(hù)的認(rèn)證信息，服務(wù)器在只有收到認(rèn)證后才會(huì)返回給客戶(hù)端 200 OK 的響應(yīng)，如果沒(méi)有認(rèn)證信息，則會(huì)返回 401 并告知客戶(hù)端需要認(rèn)證信息。詳細(xì)關(guān)于 Authorization 的信息，后面也會(huì)詳細(xì)解釋

Expect

Expect HTTP 請(qǐng)求標(biāo)頭指示服務(wù)器需要滿(mǎn)足的期望才能正確處理請(qǐng)求。如果服務(wù)器沒(méi)有辦法完成客服端所期望完成的事情并且服務(wù)端存在錯(cuò)誤的話(huà)，會(huì)返回 417 Expectation Failed 。HTTP 1.1 只規(guī)定了100-continue 。

  • 如果服務(wù)器能正常完成客戶(hù)端所期望的事情，會(huì)返回 100
  • 如果不能滿(mǎn)足期望或返回任何其他4xx 的狀態(tài)碼，會(huì)返回 417

例如

  1. PUT /somewhere/fun HTTP/1.1 
  2. Host: origin.example.com 
  3. Content-Type: video/h264 
  4. Content-Length: 1234567890987 
  5. Expect: 100-continue 

From

From 請(qǐng)求頭用來(lái)告知服務(wù)器使用用戶(hù)代理的電子郵件地址。通常情況下，其使用目的就是為了顯示搜索引擎等用戶(hù)代理的負(fù)責(zé)人的電子郵件聯(lián)系方式。我們?cè)谑褂么淼那闆r下，應(yīng)盡可能包含 From 首部字段。例如

From: webmaster@example.org

“你不應(yīng)該將 From 用在訪(fǎng)問(wèn)控制或者身份驗(yàn)證中

Host

Host 請(qǐng)求頭指明了服務(wù)器的域名(對(duì)于虛擬主機(jī)來(lái)說(shuō))，以及(可選的)服務(wù)器監(jiān)聽(tīng)的TCP端口號(hào)。如果沒(méi)有給定端口號(hào)，會(huì)自動(dòng)使用被請(qǐng)求服務(wù)的默認(rèn)端口(比如請(qǐng)求一個(gè) HTTP 的 URL 會(huì)自動(dòng)使用80作為端口)。

  1. Host: developer.mozilla.org 

Host 首部字段在 HTTP/1.1 規(guī)范內(nèi)是唯一一個(gè)必須被包含在請(qǐng)求內(nèi)的首部字段。

If-Match

If-Match 后面可以跟一大堆屬性，形式像 If-Match 這種的請(qǐng)求頭稱(chēng)為條件請(qǐng)求，服務(wù)器接收到條件請(qǐng)求后，需要判定條件請(qǐng)求是否滿(mǎn)足，只有條件請(qǐng)求為真，才會(huì)執(zhí)行條件請(qǐng)求

類(lèi)似的還有 If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since

  • 對(duì)于 GET 和 POST 方法，服務(wù)器僅在與列出的 ETag(響應(yīng)標(biāo)頭) 之一匹配時(shí)才返回請(qǐng)求的資源。這里又多了一個(gè)新詞 ETag，我們稍后再說(shuō) ETag 的用法。
  • 對(duì)于像是 PUT 和其他非安全的方法，在這種情況下，它僅僅將上傳資源。
  1. If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d" 
  2. If-Match: * 

下面是兩種常見(jiàn)的案例

  • 對(duì)于 GET 和 POST 方法，會(huì)結(jié)合使用 Range 標(biāo)頭，它可以確保新發(fā)送請(qǐng)求的范圍與上一個(gè)請(qǐng)求的資源相同，如果不匹配的話(huà)，會(huì)返回 416 響應(yīng)。
  • 對(duì)于其他方法，特別是 PUT 方法，If-Match 可以防止丟失更新，服務(wù)器會(huì)比對(duì) If-Match 的字段值和資源的 ETag 值，僅當(dāng)兩者一致時(shí)，才會(huì)執(zhí)行請(qǐng)求。反之，則返回狀態(tài)碼 412 Precondition Failed 的響應(yīng)。例如
  1. If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d" 
  2. If-Match: * 

If-Modified-Since

If-Modified-Since 是 HTTP 條件請(qǐng)求的一部分，只有在給定日期之后，服務(wù)端修改了請(qǐng)求所需要的資源，才會(huì)返回 200 OK 的響應(yīng)。如果在給定日期之后，服務(wù)端沒(méi)有修改內(nèi)容，響應(yīng)會(huì)返回 304 并且不帶任何響應(yīng)體。If-Modified-Since 只能使用 GET 和 HEAD 請(qǐng)求。

If-Modified-Since 與 If-None-Match 結(jié)合使用時(shí)，它將被忽略，除非服務(wù)器不支持 If-None-Match。一般表示如下

  1. If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT 

“注意：這是格林威治標(biāo)準(zhǔn)時(shí)間。HTTP 日期始終以格林尼治標(biāo)準(zhǔn)時(shí)間表示，而不是本地時(shí)間。

If-None-Match

條件請(qǐng)求，它與 If-Match 的作用相反，僅當(dāng) If-None-Match 的字段值與 ETag 值不一致時(shí)，可處理該請(qǐng)求。對(duì)于GET 和 HEAD ，僅當(dāng)服務(wù)器沒(méi)有與給定資源匹配的 ETag 時(shí)，服務(wù)器將返回 200 作為響應(yīng)。對(duì)于其他方法，僅當(dāng)最終現(xiàn)有資源的 ETag 與列出的任何值都不匹配時(shí)，才會(huì)處理請(qǐng)求。

當(dāng) GET 和 POST 發(fā)送的 If-None-Match與 ETag 匹配時(shí)，服務(wù)器會(huì)返回 304。

  1. If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d" 
  2. If-None-Match: W/"67ab43", "54ed21", "7892dd" 
  3. If-None-Match: * 

有同學(xué)可能會(huì)好奇 W/ 是什么意思，這其實(shí)是 ETag 的弱匹配，關(guān)于 ETag 我們會(huì)在響應(yīng)標(biāo)頭中詳細(xì)講述。

If-Range

If-Range 也是條件請(qǐng)求，如果滿(mǎn)足條件(If-Range 的值和 ETag 值或者更新的日期時(shí)間一致)，則會(huì)發(fā)出范圍請(qǐng)求，否則將會(huì)返回全部資源。它的一般表示如下

  1. If-Range: Wed, 21 Oct 2015 07:28:00 GMT 

If-Unmodified-Since

If-Unmodified-Since HTTP 請(qǐng)求標(biāo)頭也是一個(gè)條件請(qǐng)求，服務(wù)器只有在給定日期之后沒(méi)有對(duì)其進(jìn)行修改時(shí)，服務(wù)器才返回請(qǐng)求資源。如果在指定日期時(shí)間后發(fā)生了更新，則以狀態(tài)碼 412 Precondition Failed 作為響應(yīng)返回。

  1. If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT 

Max-Forwards

Max-Forwards 一般用于 TRACE 和 OPTION 方法，發(fā)送包含 Max-Forwards 的首部字段時(shí)，每經(jīng)過(guò)一個(gè)服務(wù)器，Max-Forwards 的值就會(huì) -1，直到 Max-Forwards 為0時(shí)返回。Max-Forwards 是一個(gè)十進(jìn)制的整數(shù)值。

  1. Max-Forwards: 10 

可以靈活使用首部字段 Max-Forwards，針對(duì)以上問(wèn)題產(chǎn)生的原因展開(kāi)調(diào)查。由于當(dāng) Max-Forwards 字段值為 0 時(shí)，服務(wù)器就會(huì)立即返回響應(yīng)，由此我們至少可以對(duì)以那臺(tái)服務(wù)器為終點(diǎn)的傳輸路徑的通信狀況有所把握。

Proxy-Authorization

Proxy-Authorization 是屬于請(qǐng)求與認(rèn)證的范疇，我們?cè)谏厦嫣岬揭粋€(gè)認(rèn)證的 HTTP 標(biāo)頭是 Authorization，不同于 Authorization 發(fā)生在客戶(hù)端 - 服務(wù)器之間;Proxy-Authorization 發(fā)生在代理服務(wù)器和客戶(hù)端之間。它表示接收到從代理服務(wù)器發(fā)來(lái)的認(rèn)證時(shí)，客戶(hù)端會(huì)發(fā)送包含首部字段 Proxy-Authorization 的請(qǐng)求，以告知服務(wù)器認(rèn)證所需要的信息。

  1. Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l 

Range

Range HTTP 請(qǐng)求標(biāo)頭指示服務(wù)器應(yīng)返回文檔指定部分的資源，可以一次請(qǐng)求一個(gè) Range 來(lái)返回多個(gè)部分，服務(wù)器會(huì)將這些資源返回各個(gè)文檔中。如果服務(wù)器成功返回，那么將返回 206 響應(yīng);如果 Range 范圍無(wú)效，服務(wù)器返回416 Range Not Satisfiable錯(cuò)誤;服務(wù)器還可以忽略 Range 標(biāo)頭，并且返回 200 作為響應(yīng)。

Range: bytes=200-1000, 2000-6576, 19000-

Referer

HTTP Referer 屬性是請(qǐng)求標(biāo)頭的一部分，當(dāng)瀏覽器向 web 服務(wù)器發(fā)送請(qǐng)求的時(shí)候，一般會(huì)帶上 Referer，告訴服務(wù)器該網(wǎng)頁(yè)是從哪個(gè)頁(yè)面鏈接過(guò)來(lái)的，服務(wù)器因此可以獲得一些信息用于處理。

Referer: https://developer.mozilla.org/testpage.html

TE

首部字段 TE 會(huì)告知服務(wù)器客戶(hù)端能夠處理響應(yīng)的傳輸編碼方式及相對(duì)優(yōu)先級(jí)。它和首部字段 Accept-Encoding 的功能很相像，但是用于傳輸編碼。

  1. TE: gzip, deflate;q=0.5 

首部字段 TE 除指定傳輸編碼之外，還可以指定伴隨 trailer 字段的分塊傳輸編碼的方式。應(yīng)用后者時(shí)，只需把 trailers 賦值給該字段值。

  1. TE: trailers, deflate;q=0.5 

User-Agent

首部字段 User-Agent 會(huì)將創(chuàng)建請(qǐng)求的瀏覽器和用戶(hù)代理名稱(chēng)等信息傳達(dá)給服務(wù)器。

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

響應(yīng)標(biāo)頭

剛剛我們的著重點(diǎn)一直放在客戶(hù)端請(qǐng)求，現(xiàn)在我們把關(guān)注點(diǎn)轉(zhuǎn)換一下放在服務(wù)器上。響應(yīng)首部字段是由服務(wù)器發(fā)送給客戶(hù)端響應(yīng)中所包含的字段，用于補(bǔ)充相應(yīng)信息等，這部分標(biāo)頭也是非常多，我們先一起來(lái)看一下

  • Accept-Ranges
  • Age
  • ETag
  • Location
  • Proxy-Authenticate
  • Retry-After
  • Server
  • Vary
  • www-Authenticate

Accept-Ranges

Accept-Ranges HTTP 響應(yīng)標(biāo)頭，這個(gè)標(biāo)頭有兩個(gè)值

  • 當(dāng)服務(wù)器能夠處理客戶(hù)端發(fā)送過(guò)來(lái)的請(qǐng)求時(shí)，使用bytes 來(lái)指定
  • 當(dāng)服務(wù)器不能處理客戶(hù)端發(fā)來(lái)的請(qǐng)求時(shí)，使用 none 來(lái)指定
  1. Accept-Ranges: bytes 
  2. Accept-Ranges: none 

Age

Age HTTP 響應(yīng)標(biāo)頭告訴客戶(hù)端源服務(wù)器在多久之前創(chuàng)建了響應(yīng)，它的單位為秒，Age 標(biāo)頭通常接近于0，如果是0則可能是從源服務(wù)器獲取的，如果不是表示可能是由代理服務(wù)器創(chuàng)建，那么 Age 的值表示的是緩存后的響應(yīng)再次發(fā)起認(rèn)證到認(rèn)證完成的時(shí)間值。代理創(chuàng)建響應(yīng)時(shí)必須加上首部字段 Age。一般表示如下

  1. Age: 24 

ETag

ETag 對(duì)于條件請(qǐng)求來(lái)說(shuō)真是太重要了。因?yàn)闂l件請(qǐng)求就是根據(jù) ETag 的值進(jìn)行匹配的，下面我們就來(lái)詳細(xì)了解一下。

ETag 響應(yīng)頭是特定版本的標(biāo)識(shí)，它能夠使緩存變得更高效并能夠節(jié)省帶寬，因?yàn)槿绻彺鎯?nèi)容未發(fā)生變更，Web 服務(wù)器則不需要重新發(fā)送完整的響應(yīng)。除此之外，ETag 能夠防止資源同時(shí)更新互相覆蓋。

 

 

 

 

如果給定 URL 上的資源發(fā)生變更，必須生成一個(gè)新的 ETag 值，通過(guò)比較它們可以確定資源的兩個(gè)表示形式是否相同。

ETag 值有兩種，一種是強(qiáng) ETag，一種是弱 ETag;

  • 強(qiáng) ETag 值，無(wú)論實(shí)體發(fā)生多么細(xì)微的變化都會(huì)改變其值，一般的表示如下
  1. ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" 
  • 弱 ETag 值，弱 ETag 值只用于提示資源是否相同。只有資源發(fā)生了根本改變，產(chǎn)生差異時(shí)才會(huì)改變 ETag 值。這時(shí)，會(huì)在字段值最開(kāi)始處附加 W/。
  1. ETag: W/"0815" 

Location

Location 響應(yīng)標(biāo)頭表示 URL 需要重定向頁(yè)面，它僅僅與 3xx(重定向) 或 201(已創(chuàng)建) 狀態(tài)響應(yīng)一起使用。下面是一個(gè)頁(yè)面重定向的過(guò)程

 

使用首部字段 Location 可以將響應(yīng)接受方引導(dǎo)至某個(gè)與請(qǐng)求 URI 位置不同的資源。

Location 和 content-Location 是不一樣的：Location 表示目標(biāo)的重定向(或新創(chuàng)建資源的 URL)。然而 Content-Location 表示發(fā)生內(nèi)容協(xié)商時(shí)用于訪(fǎng)問(wèn)資源的直接 URL，而無(wú)須進(jìn)一步協(xié)商。Location 是與響應(yīng)相關(guān)聯(lián)的標(biāo)頭，而 Content-Location 與返回的實(shí)體相關(guān)聯(lián)。

  1. Location: /index.html 

Proxy-Authenticate

HTTP 響應(yīng)標(biāo)頭 Proxy-Authenticate 會(huì)定義認(rèn)證方法，應(yīng)該使用身份驗(yàn)證方法來(lái)訪(fǎng)問(wèn)代理服務(wù)器后面的資源即客戶(hù)端。

它與 HTTP 客戶(hù)端和服務(wù)端之間的訪(fǎng)問(wèn)認(rèn)證行為相似，不同之處在于 Proxy-Authenticate 的認(rèn)證雙方是客戶(hù)端與代理之間。它的一般表示形式如下

  1. Proxy-Authenticate: Basic 
  2. Proxy-Authenticate: Basic realm="Access to the internal site" 

Retry-After

HTTP 響應(yīng)標(biāo)頭 Retry-After 告知客戶(hù)端需要在多久之后重新發(fā)送請(qǐng)求，使用此標(biāo)頭主要有如下三種情況

  • 當(dāng)發(fā)送 503(服務(wù)不可用)響應(yīng)時(shí)，這表示該服務(wù)預(yù)計(jì)無(wú)法使用多長(zhǎng)時(shí)間。
  • 當(dāng)發(fā)送 429(太多請(qǐng)求)響應(yīng)時(shí)，這表示發(fā)出新請(qǐng)求之前要等待多長(zhǎng)時(shí)間。
  • 當(dāng)發(fā)送重定向的響應(yīng)像是 301(永久移動(dòng))，這表示在發(fā)出重定向請(qǐng)求之前要求用戶(hù)客戶(hù)端等待的最短時(shí)間。

字段值可以指定為具體的日期時(shí)間，也可以是創(chuàng)建響應(yīng)后所持續(xù)的秒數(shù)，例如

  1. Retry-After: Wed, 21 Oct 2015 07:28:00 GMT 
  2. Retry-After: 120 

Server

服務(wù)器標(biāo)頭包含有關(guān)原始服務(wù)器用來(lái)處理請(qǐng)求的軟件的信息。

應(yīng)該避免使用過(guò)于冗長(zhǎng)和詳細(xì)的 Server 值，因?yàn)樗鼈兛赡軙?huì)泄露內(nèi)部實(shí)施細(xì)節(jié)，這可能會(huì)使攻擊者容易地發(fā)現(xiàn)并利用已知的安全漏洞。例如下面這種寫(xiě)法

  1. Server: Apache/2.4.1 (Unix) 

Vary

Vary HTTP 響應(yīng)標(biāo)頭確定如何匹配請(qǐng)求標(biāo)頭，以決定是否可以使用緩存的響應(yīng)，而不是從原始服務(wù)器請(qǐng)求一個(gè)新的響應(yīng)。

  1. Vary: User-Agent 

www-Authenticate

HTTP WWW-Authenticate 響應(yīng)標(biāo)頭定義了應(yīng)用于獲得對(duì)資源的訪(fǎng)問(wèn)權(quán)限的身份驗(yàn)證方法。WWW-Authenticate標(biāo)頭與401未經(jīng)授權(quán)的響應(yīng)一起發(fā)送。它的一般表示形式如下

  1. WWW-Authenticate: Basic 
  2. WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8" 

Access-Control-Allow-Origin

一個(gè)返回的 HTTP 標(biāo)頭可能會(huì)具有 Access-Control-Allow-Origin ，Access-Control-Allow-Origin指定一個(gè)來(lái)源，它告訴瀏覽器允許該來(lái)源進(jìn)行資源訪(fǎng)問(wèn)。否則-對(duì)于沒(méi)有憑據(jù)的請(qǐng)求 *通配符，告訴瀏覽器允許任何源訪(fǎng)問(wèn)資源。例如，要允許源 https://mozilla.org 的代碼訪(fǎng)問(wèn)資源，可以指定：

  1. Access-Control-Allow-Origin: https://mozilla.org 
  2. Vary: Origin 

如果服務(wù)器指定單個(gè)來(lái)源而不是 *通配符的話(huà) ，則服務(wù)器還應(yīng)在 Vary 響應(yīng)標(biāo)頭中包含Origin ，以向客戶(hù)端指示 服務(wù)器響應(yīng)將根據(jù)原始請(qǐng)求標(biāo)頭的值而有所不同。

實(shí)體標(biāo)頭

實(shí)體標(biāo)頭用于HTTP請(qǐng)求和響應(yīng)中，例如 Content-Length，Content-Language，Content-Encoding 的標(biāo)頭是實(shí)體標(biāo)頭。實(shí)體標(biāo)頭不局限于請(qǐng)求標(biāo)頭或者響應(yīng)標(biāo)頭，下面例子中，Content-Length 是一個(gè)實(shí)體標(biāo)頭，但是卻出現(xiàn)在了請(qǐng)求報(bào)文中

  1. POST /myform.html HTTP/1.1 
  2. Host: developer.mozilla.org 
  3. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 
  4. Content-Length: 128 

下面就來(lái)說(shuō)一下實(shí)體標(biāo)頭都包含哪些

  • Allow
  • Content-Encoding
  • Content-Language
  • Content-Length
  • Content-Location
  • Content-MD5
  • Content-Range
  • Content-Type
  • Expires
  • Last-Modified

下面來(lái)分開(kāi)說(shuō)一下

Allow

HTTP 實(shí)體標(biāo)頭 Allow 列出了資源支持的方法集合。如果服務(wù)器響應(yīng)405 Method Not Allowed狀態(tài)碼以指示可以使用哪些請(qǐng)求方法，則必須發(fā)送此標(biāo)頭。例如

  1. Allow: GET, POST, HEAD 

這段代碼表示服務(wù)器允許支持 GET 、POST 和 HEAD 方法。當(dāng)服務(wù)器接收到不支持的 HTTP 方法時(shí)，會(huì)以狀態(tài)碼 405 Method Not Allowed 作為響應(yīng)返回。

Content-Encoding

我們上面講過(guò) Accept-Encoding 是客戶(hù)端希望服務(wù)端返回的內(nèi)容編碼，但是實(shí)際上服務(wù)端返回給客戶(hù)端的內(nèi)容編碼實(shí)際上是通過(guò) Content-Encoding 返回的。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮。主要也是四種，和 Accept-Encoding 相同，它們是 gzip、compress、deflate、identity。下面是一組請(qǐng)求/響應(yīng)內(nèi)容壓縮編碼

  1. Accept-Encoding: gzip, deflate 
  2. Content-Encoding: gzip 

Content-Language

首部字段 Content-Language 會(huì)告知客戶(hù)端，服務(wù)器使用的自然語(yǔ)言是什么，它與 Accept-Language 相對(duì)，下面是一組請(qǐng)求/響應(yīng)使用的語(yǔ)言類(lèi)型

  1. Content-Language: de-DE, en-CA 

Content-Length

Content-Length 的實(shí)體標(biāo)頭指服務(wù)器發(fā)送給客戶(hù)端的實(shí)際主體大小，以字節(jié)為單位。

  1. Content-Length: 3000 

如上，服務(wù)器返回給客戶(hù)端的主體大小是 3000 字節(jié)。

Content-Location

Content-Location 可不是對(duì)應(yīng) Accept-Location，因?yàn)闆](méi)有這個(gè)標(biāo)頭哈哈哈哈。實(shí)際上 Content-Location 對(duì)應(yīng)的是 Location。

Location 和 Content-Location 是不一樣的，Location 表示重定向的 URL，而 Content-Location 表示用于訪(fǎng)問(wèn)資源的直接 URL，以后無(wú)需進(jìn)行進(jìn)一步的內(nèi)容協(xié)商。Location 是與響應(yīng)關(guān)聯(lián)的標(biāo)頭，而 Content-Location 是與返回的數(shù)據(jù)相關(guān)聯(lián)的標(biāo)頭，如果你不好理解，看一下下面的表格

Content-MD5

客戶(hù)端會(huì)對(duì)接收的報(bào)文主體執(zhí)行相同的 MD5 算法，然后與首部字段 Content-MD5 的字段進(jìn)行比較。

  1. Content-MD5: e10adc3949ba59abbe56e057f20f883e 

首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在于檢查報(bào)文主體在傳輸過(guò)程中是否保持完整，有無(wú)被修改的情況，以及確認(rèn)傳輸?shù)竭_(dá)。

Content-Range

HTTP 的 Content-Range 響應(yīng)標(biāo)頭是針對(duì)范圍請(qǐng)求而設(shè)定的，返回響應(yīng)時(shí)使用首部字段 Content-Range，能夠告知客戶(hù)端響應(yīng)實(shí)體的哪部分是符合客戶(hù)端請(qǐng)求的，字段以字節(jié)為單位。它的一般表示如下

  1. Content-Range: bytes 200-1000/67589 

上段代碼表示從所有 67589 個(gè)字節(jié)中返回 200-1000 個(gè)字節(jié)的內(nèi)容

Content-Type

HTTP 響應(yīng)標(biāo)頭 Content-Type 說(shuō)明了實(shí)體內(nèi)對(duì)象的媒體類(lèi)型，和首部字段 Accept 一樣使用，表示服務(wù)器能夠響應(yīng)的媒體類(lèi)型。

Expires

HTTP Expires 實(shí)體標(biāo)頭包含 日期/時(shí)間，在該日期/時(shí)間之后，響應(yīng)被認(rèn)為過(guò)期;在響應(yīng)時(shí)間之內(nèi)被認(rèn)為有效。特殊的值比如0表示過(guò)去的日期，表示資源已過(guò)期。

  1. Expires: Wed, 21 Oct 2015 07:28:00 GMT 

源服務(wù)器會(huì)將資源失效的日期或時(shí)間發(fā)送給客戶(hù)端，緩存服務(wù)器在接受到 Expires 的響應(yīng)后，會(huì)判斷是否把緩存返回給客戶(hù)端。

源服務(wù)器不希望緩存服務(wù)器對(duì)資源緩存時(shí)，最好在 Expires 字段內(nèi)寫(xiě)入與首部字段 Date 相同的時(shí)間值。但是，當(dāng)首部字段 Cache-Control 有指定 max-age 指令時(shí)，比起首部字段 Expires，會(huì)優(yōu)先處理 max-age 指令。

Last-Modified

實(shí)體字段 Last-Modified 指明資源的最后修改時(shí)間，它用作驗(yàn)證器來(lái)確定接收或存儲(chǔ)的資源是否相同。它的作用不如 ETag 那么準(zhǔn)確，它可以作為一種后備機(jī)制，包含 If-Modified-Since或 If-Unmodified-Since 標(biāo)頭的條件請(qǐng)求將使用此字段。它的一般表示如下

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

總結(jié)

本篇文章主要介紹了 HTTP 四種標(biāo)頭的基本概念，但是并沒(méi)有涵蓋全部，畢竟 HTTP 標(biāo)頭內(nèi)容確實(shí)太多了，以上介紹的基本都是平常工作中常用的一些概念，下一篇文章預(yù)告 HTTP 的黑科技

文章參考：

https://developer.mozilla.org/en-US/docs/Web/HTTP

http://www.tcpipguide.com/free/t_HTTPGeneralHeaders.htm

http://www.tcpipguide.com/free/t_HTTPCachingFeaturesandIssues.htm

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#Cache_validation

《圖解 HTTP》

https://www.w3.org/Protocols/rfc2616/rfc2616.html

https://blog.csdn.net/qq_29405933/article/details/84315254

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

 

責(zé)任編輯：武曉燕 來(lái)源： Java建設(shè)者
HTTP概念標(biāo)頭
相關(guān)推薦

2020-12-22 11:06:05

JavaScript開(kāi)發(fā)前端

2021-09-25 13:12:47

數(shù)據(jù)開(kāi)發(fā)架構(gòu)

2015-12-29 13:53:14

BeeCloud云計(jì)算支付

2022-02-24 07:03:13

JavaScrip語(yǔ)言

2018-09-24 09:15:12

數(shù)據(jù)倉(cāng)庫(kù)大數(shù)據(jù)

2018-09-04 05:05:29

2021-01-07 05:40:13

BLE模塊Android

2015-07-09 11:32:26

AWSIaaS云計(jì)算

2020-07-24 20:57:33

MySQL數(shù)據(jù)量數(shù)據(jù)庫(kù)

2014-08-28 09:55:19

中文郵箱郵箱賬號(hào)

2025-02-12 15:27:08

銳捷網(wǎng)絡(luò)運(yùn)維云計(jì)算

2021-05-27 11:26:46

nodesassCSS

2018-02-06 09:40:25

PythonOOP繼承

2014-01-09 14:52:47

創(chuàng)意開(kāi)源

2023-11-02 08:46:19

微服務(wù)開(kāi)發(fā)Istio

2015-09-16 09:21:12

移動(dòng)云技術(shù)數(shù)據(jù)管理

2018-11-11 11:16:38

AI天貓比價(jià)

2018-11-12 00:19:32

2021-02-04 14:24:25

5G網(wǎng)絡(luò)運(yùn)營(yíng)商

2023-05-12 07:12:20

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)