一文帶你瞭解 HTTP 黑科技

這是 HTTP 系列的第三篇文章，此篇文章爲 HTTP 的進階文章。

在前面兩篇文章中咱們講述了 HTTP 的入門，HTTP 全部經常使用標頭的概述，這篇文章咱們來聊一下 HTTP 的一些 黑科技。

HTTP 內容協商

什麼是內容協商

在 HTTP 中，內容協商是一種用於在同一 URL 上提供資源的不一樣表示形式的機制。內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，而後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的標準。

內容協商的種類

內容協商主要有如下3種類型：

• 服務器驅動協商（Server-driven Negotiation）

這種協商方式是由服務器端進行內容協商。服務器端會根據請求首部字段進行自動處理

• 客戶端驅動協商（Agent-driven Negotiation）

這種協商方式是由客戶端來進行內容協商。

• 透明協商（Transparent Negotiation）

是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。

內容協商的分類有不少種，主要的幾種類型是 Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。

通常來講，客戶端用 Accept 頭告訴服務器但願接收什麼樣的數據，而服務器用 Content 頭告訴客戶端實際發送了什麼樣的數據。

爲何須要內容協商

咱們爲何須要內容協商呢？在回答這個問題前咱們先來看一下 TCP 和 HTTP 的不一樣。

在 TCP / IP 協議棧裏，傳輸數據基本上都是 header+body 的格式。但 TCP、UDP 由於是傳輸層的協議，它們不會關心 body 數據是什麼，只要把數據發送到對方就算是完成了任務。

而 HTTP 協議則不一樣，它是應用層的協議，數據到達以後須要告訴應用程序這是什麼數據。固然不告訴應用這是哪一種類型的數據，應用也能夠經過不斷嘗試來判斷，但這種方式無疑十分低效，並且有很大概率會檢查不出來文件類型。

因此鑑於此，瀏覽器和服務器須要就數據的傳輸達成一致，瀏覽器須要告訴服務器本身但願可以接收什麼樣的數據，須要什麼樣的壓縮格式，什麼語言，哪一種字符集等；而服務器須要告訴客戶端本身可以提供的服務是什麼。

因此咱們就引出了內容協商的幾種概念，下面依次來進行探討

內容協商標頭

Accept

接受請求 HTTP 標頭會通告客戶端本身可以接受的 MIME 類型

那麼什麼是 MIME 類型呢？在回答這個問題前你應該先了解一下什麼是 MIME

MIME: MIME (Multipurpose Internet Mail Extensions) 是描述消息內容類型的因特網標準。MIME 消息能包含文本、圖像、音頻、視頻以及其餘應用程序專用的數據。

也就是說，MIME 類型其實就是一系列消息內容類型的集合。那麼 MIME 類型都有哪些呢？

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

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

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

應用程序二進制文件： application/octet-stream、application/zip

好比，若是瀏覽器不支持 PNG 圖片的顯示，那 Accept 就不指定image/png，而指定可處理的 image/gif 和 image/jpeg 等圖片類型。

通常 MIME 類型也會和 q 這個屬性一塊兒使用，q 是什麼？q 表示的是權重，來看一個例子

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

這是什麼意思呢？若想要給顯示的媒體類型增長優先級，則使用 q= 來額外表示權重值，沒有顯示權重的時候默認值是1.0 ，我給你列個表格你就明白了

q	MIME
1.0	text/html
1.0	application/xhtml+xml
0.9	application/xml
0.8	* / *

也就是說，這是一個放置順序，權重高的在前，低的在後，application/xml;q=0.9 是不可分割的總體。

Accept-Charset

Accept-charset 屬性規定服務器處理表單數據所接受的字符編碼；Accept-charset 屬性容許你指定一系列字符集，服務器必須支持這些字符集，從而得以正確解釋表單中的數據。

Accept-Charset 沒有對應的標頭，服務器會把這個值放在 Content-Type中用 charset=xxx來表示，

例如，瀏覽器請求 GBK 或 UTF-8 的字符集，而後服務器返回的是 UTF-8 編碼，就是下面這樣

Accept-Charset: gbk, utf-8
Content-Type: text/html; charset=utf-8

Accept-Language

首部字段 Accept-Language 用來告知服務器用戶代理可以處理的天然語言集（指中文或英文等），以及天然語言集的相對優先級。可一次指定多種天然語言集。和 Accept 首部字段同樣，按權重值 q= 來表示相對優先級。

Accept-Language: en-US,en;q=0.5

Accept-Encoding

表示 HTTP 標頭會標明客戶端但願服務端返回的內容編碼，這一般是一種壓縮算法。Accept-Encoding 也是屬於內容協商 的一部分，使用並經過客戶端選擇 Content-Encoding 內容進行返回。

即便客戶端和服務器都可以支持相同的壓縮算法，服務器也可能選擇不壓縮並返回，這種狀況多是因爲這兩種狀況形成的:

• 要發送的數據已經被壓縮了一次，第二次壓縮並不會致使發送的數據更小
• 服務器過載，沒法承受壓縮帶來的性能開銷，一般，若是服務器使用 CPU 超過 80% ，Microsoft 則建議不要使用壓縮

下面是 Accept-Encoding 的使用方式

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

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

• gzip: 由文件壓縮程序 gzip 生成的編碼格式，使用 Lempel-Ziv編碼（LZ77）和32位CRC的壓縮格式，感興趣的同窗能夠讀一下 （https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77）

• compress: 使用Lempel-Ziv-Welch（LZW）算法的壓縮格式，有興趣的同窗能夠讀 （https://en.wikipedia.org/wiki/LZW）

• deflate: 使用 zlib 結構和 deflate 壓縮算法的壓縮格式，參考 （https://en.wikipedia.org/wiki/Zlib） 和 （https://en.wikipedia.org/wiki/DEFLATE）

• br: 使用 Brotli 算法的壓縮格式，參考 （https://en.wikipedia.org/wiki/Brotli）

• 不執行壓縮或不會變化的默認編碼格式

• * : 匹配標頭中未列出的任何內容編碼，若是沒有列出 Accept-Encoding ，這就是默認值，並不意味着支

  持任何算法，只是表示沒有偏好

• ;q= 採用權重 q 值來表示相對優先級，這點與首部字段 Accept 相同。

Content-Type

Content-Type 實體標頭用於指示資源的 MIME 類型。做爲響應，Content-Type 標頭告訴客戶端返回的內容的內容類型其實是什麼。Content-type 有兩種值 : MIME 類型和字符集編碼，例如

Content-Type: text/html; charset=UTF-8

在某些狀況下，瀏覽器將執行 MIME 嗅探，而且不必定遵循此標頭的值；爲防止此行爲，能夠將標頭 X-Content-Type-Options 設置爲 nosniff。

Content-Encoding

Content-Encoding 實體標頭用於壓縮媒體類型，它讓客戶端知道如何進行解碼操做，從而使客戶端得到 Content-Type 標頭引用的 MIME 類型。表示以下

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br
Content-Encoding: gzip, identity
Content-Encoding: deflate, gzip

Content-Language

Content-Language 實體標頭用於描述面向受衆的語言，以便使用戶根據用戶本身的首選語言進行區分。例如

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA

下面根據內容協商對應的請求/響應標頭，我列了一張圖供你參考，注意其中 Accept-Charset 沒有對應的 Content-Charset ，而是經過 Content-Type 來表示。

HTTP 認證

HTTP 提供了用於訪問控制和身份認證的功能，下面就對 HTTP 的權限和認證功能進行介紹

通用 HTTP 認證框架

RFC 7235 定義了 HTTP 身份認證框架，服務器能夠根據其文檔的定義來檢查客戶端請求。客戶端也能夠根據其文檔定義來提供身份驗證信息。

請求/響應的工做流程以下：服務器以401(未受權) 的狀態響應客戶端告訴客戶端服務器須要認證信息，客戶端提供至少一個 www-Authenticate 的響應標頭進行受權信息的認證。想要經過服務器進行身份認證的客戶端能夠在請求標頭字段中添加認證標頭進行身份認證，通常的認證過程以下

首先客戶端發起一個 HTTP 請求，不帶有任何認證標頭，服務器對此 HTTP 請求做出響應，發現此 HTTP 信息未帶有認證憑據，服務器經過 www-Authenticate標頭返回 401 告訴客戶端此請求未經過認證。而後客戶端進行用戶認證，認證完畢後從新發起 HTTP 請求，此次 HTTP 請求帶有用戶認證憑據（注意，整個身份認證的過程必須經過 HTTPS 鏈接保證安全），到達服務器後服務器會檢查認證信息，若是不符合服務器認證信息，會返回 403 Forbidden 表示用戶認證失敗，若是知足認證信息，則返回 200 OK。

咱們知道，客戶端和服務器之間的 HTTP 鏈接能夠被代理緩存從新發送，因此認證信息也適用於代理服務器。

代理認證

因爲資源認證和代理認證能夠共存，所以須要不一樣的頭和狀態碼，在代理的狀況下，會返回狀態碼 407(須要代理認證)， Proxy-Authenticate 響應頭包含至少一個適用於代理的狀況，Proxy-Authorization請求頭用於將證書提供給代理服務器。下面分別來認識一下這兩個標頭

Proxy-Authenticate

HTTP Proxy-Authenticate 響應標頭定義了身份驗證方法，應使用該身份驗證方法來訪問代理服務器後面的資源。它將請求認證到代理服務器，從而容許它進一步發送請求。例如

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

Proxy-Authorization

這個 HTTP 請求標頭和上面的 Proxy-Authenticate 拼接很類似，可是概念不一樣，這個標頭用於向代理服務器提供憑據，例如

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

下面是代理服務器的請求/響應認證過程

這個過程和通用的過程相似，咱們就再也不詳細展開描述了。

禁止訪問

若是代理服務器收到的有效憑據不足以獲取對給定資源的訪問權限，則服務器應使用403 Forbidden狀態代碼進行響應。與 401 Unauthorized 和 407 Proxy Authorization Required 不一樣，該用戶沒法進行身份驗證。

WWW-Authenticate 和 Proxy-Authenticate 頭

WWW-Authenticate 和 Proxy-Authenticate 響應頭定義了得到對資源訪問權限的身份驗證方法。他們須要指定使用哪一種身份驗證方案，以便但願受權的客戶端知道如何提供憑據。它們的通常表示形式以下

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

我想你從上面看到這裏必定會好奇 <type> 和 realm是什麼東西，如今就來解釋下。

• <type> 是認證協議，Basic 是下面協議中最廣泛使用的

RFC 7617 中定義了Basic HTT P身份驗證方案，該方案將憑據做爲用戶ID /密碼對傳輸，並使用 base64 進行編碼。(感興趣的同窗能夠看看 https://tools.ietf.org/html/rfc7617)

其餘的認證協議主要有

認證協議	參考來源
Basic	查閱 RFC 7617，base64編碼的憑據
Bearer	查閱 RFC 6750，承載令牌來訪問受 OAuth 2.0保護的資源
Digest	查閱 RFC 7616，Firefox僅支持md5哈希，請參見錯誤bug 472823以得到SHA加密支持
HOBA	查閱 RFC 7486
Mutual	查閱 RFC 8120
AWS4-HMAC-SHA256	查閱 AWS docs

• realm 用於描述保護區或指示保護範圍，這多是諸如 Access to the staging site(訪問登錄站點) 或者相似的，這樣用戶就能夠知道他們要訪問哪一個區域。

Authorization 和 Proxy-Authorization 標頭

Authorization 和 Proxy-Authorization 請求標頭包含用於經過代理服務器對用戶代理進行身份驗證的憑據。在此，再次須要類型，其後是憑據，取決於使用哪一種身份驗證方案，能夠對憑據進行編碼或加密。通常表示以下

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

HTTP 緩存

經過把請求/響應緩存起來有助於提高系統的性能，Web 緩存減小了延遲和網絡傳輸量，所以減小資源獲取鎖須要的時間。因爲鏈路漫長，網絡時延不可控，瀏覽器使用 HTTP 獲取資源的成本較高。因此，很是有必要把數據緩存起來，下次再請求的時候儘量地複用。當 Web 緩存在其存儲中具備請求的資源時，它將攔截該請求並直接返回資源，而不是到達源服務器從新下載並獲取。這樣作能夠實現兩個小目標

• 減輕服務器負載
• 提高系統性能

下面咱們就一塊兒來探討一下 HTTP 緩存都有哪些

不一樣類型的緩存

HTTP 緩存有幾種不一樣的類型，這些能夠分爲兩個主要類別：私有緩存 和 共享緩存。

• 共享緩存：共享緩存是一種緩存，它能夠存儲多個用戶重複使用的請求/響應。
• 私有緩存：私有緩存也稱爲專用緩存，它只適用於單個用戶。
• 不緩存過時資源：全部的請求都會直接到達服務器，由服務器來下載資源並返回。

咱們主要探討瀏覽器緩存和代理緩存，但真實狀況不僅有這兩種緩存，還有網關緩存，CDN，反向代理緩存和負載平衡器，把它們部署在 Web 服務器上，能夠提升網站和 Web 應用程序的可靠性，性能和可伸縮性。

不緩存過時資源

不緩存過時資源即瀏覽器和代理不會緩存過時資源，客戶端發起的請求會直接到達服務器，可使用 no-cache 標頭表明不緩存過時資源。

no-cache 屬於 Cache-Control 通用標頭，其通常的表示方法以下

Cache-Control: no-cache

也可使用 max-age = 0 來實現不緩存的效果。

Cache-Control: max-age=0

私有緩存

私有緩存只用來緩存單個用戶，你可能在瀏覽器設置中看到了 緩存，瀏覽器緩存包含服務器經過 HTTP 下載下來的全部文檔。這個高速緩存用於使訪問的文檔能夠進行前進/後退，保存操做而無需從新發送請求到源服務器。

可使用 private 來實現私有緩存，這與 public 的用法相反，緩存服務器只對特定的客戶端進行緩存，其餘客戶端發送過來的請求，緩存服務器則不會返回緩存。它的通常表示方法以下

Cache-Control: private

共享緩存

共享緩存是一種用於存儲要由多個用戶重用的響應緩存。共享緩存通常使用 public 來表示，public 屬性只出如今客戶端響應中，表示響應能夠被任何緩存所緩存。通常表示方法以下

Cache-Control: public

緩存控制

HTTP/1.1 中的 Cache-Control 常規標頭字段用於執行緩存控制，使用此標頭可經過其提供的各類指令來定義緩存策略。下面咱們依次介紹一下這些屬性

不緩存

no-store 纔是真正意義上的不緩存，每次服務器接受到客戶端的請求後，都會返回最新的資源給客戶端。

Cache-Control: no-store

緩存但須要驗證

同上面的 不緩存過時資源

私有和共享緩存

同上

緩存過時

緩存中一個很重要的指令就是max-age，這是資源被視爲新鮮的最長時間 ，與 Expires 相反，此指令是相對於請求時間的。對於應用程序中不會更改的文件，一般能夠添加主動緩存。下面是 mag-age 的表示

Cache-Control: max-age=31536000

緩存驗證

must-revalidate 表示緩存必須在使用以前驗證過期資源的狀態，而且不該使用過時的資源。

Cache-Control: must-revalidate

下面是一個緩存驗證圖

什麼是新鮮的數據

一旦資源存儲在緩存中，理論上就能夠永遠被緩存使用。可是無論是瀏覽器緩存仍是代理緩存，其存儲空間是有限的，因此緩存會按期進行清除，這個過程叫作 緩存回收(cache eviction) （自譯）。另外一方面，服務器上的緩存也會按期進行更新，HTTP 做爲應用層的協議，它是一種客戶-服務器模式，HTTP 是無狀態的協議，所以當資源發生更改時，服務器沒法通知緩存和客戶端。所以服務器必須經過某種方式告知客戶端緩存已經被更新。服務器會提供過時時間這個概念，告知客戶端在此到期時間以前，資源是新鮮的，也就是未更改過的。在此到期時間的範圍以外，資源已過期。過時算法(Eviction algorithms) 一般會將新資源優先於陳舊資源使用。

這裏須要注意一下，過時的資源並不會被回收或忽略，當高速緩存接收到過時資源時，它會使用 If-None-Match 轉發此請求，以檢查它是否仍然有效。若是有效，服務器會返回 304 Not Modified響應頭而且沒有任何響應體，從而節省了一些帶寬。

下面是使用共享緩存代理的過程

這個圖應該比較好理解，只說一下 Age 的做用，Age 是 HTTP 響應標頭告訴客戶端源服務器在多久以前建立了響應，它的單位爲秒，Age 標頭一般接近於0，若是是0則多是從源服務器獲取的，若是不是表示多是由代理服務器建立，那麼 Age 的值表示的是緩存後的響應再次發起認證到認證完成的時間值。

緩存的有效性是由多個標頭來共同決定的，而並不是某一個標頭來決定。若是指定了 Cache-control:max-age=N ，那麼緩存會保存 N 秒。若是這個通用標頭不存在的話，則會檢查是否存在 Expires 標頭。若是 Exprires 標頭存在，那麼它的值減去 Date 標頭的值就能夠肯定其有效性。最後，若是max-age 和 expires 都不存在，就去尋找 Last-Modified 標頭，若是存在此標頭，則高速緩存的有效性等於 Date 標頭的值減去 Last-modified 標頭的值除以10。

緩存驗證

當到達緩存資源的有效期時，將對其進行驗證或再次獲取。僅當服務器提供了強驗證器或弱驗證器時，才能夠進行驗證。

當用戶按下從新加載按鈕時，將觸發從新驗證。若是緩存的響應包含 Cache-control：must-revalidate標頭，則在正常瀏覽下也會觸發該事件。另外一個因素是 高級 -> 緩存首選項 面板中的緩存驗證首選項。有一個選項可在每次加載文檔時強制進行驗證。

Etag

咱們上面提到了強驗證器和弱驗證器，實現驗證器功能的標頭正式 Etag 的做用，這意味着 HTTP 用戶代理（例如瀏覽器）不知道該字符串表示什麼，而且沒法預測其值。若是 Etag 標頭是資源響應的一部分，則客戶端能夠在將來請求的標頭中發出 If-None-Match，以驗證緩存的資源。

Last-Modified響應標頭能夠用做弱驗證器，由於它只有1秒能夠分辨的時間。若是響應中存在 Last-Modified標頭，則客戶端能夠發出 If-Modified-Since請求標頭來驗證緩存資源。（關於 Etag 更多咱們會在條件請求介紹）

避免碰撞

經過使用 Etag 和 If-Match 標頭，你能夠檢測避免碰撞。

例如，在編輯 MDN 時，將對當前 Wiki 內容進行哈希處理並將其放入響應中的 Etag 中

Etag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

當將更改保存到 Wiki 頁面（發佈數據）時，POST 請求將包含 If-Match 標頭，其中包含 Etag 值以檢查有效性。

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

若是哈希值不匹配，則表示文檔已在中間進行了編輯，並返回 412 Precondition Failed 錯誤。

緩存未佔用資源

Etag 標頭的另外一個典型用法是緩存未更改的資源，若是用戶再次訪問給定的 URL（已設置Etag），而且該 URL過期，則客戶端將在 If-None-Match 標頭字段中發送其 Etag 的值

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

服務器將客戶端的 Etag（經過 If-None-Match 發送）與 Etag 進行比較，以獲取其當前資源版本，若是兩個值都匹配（即資源未更改），則服務器會發回 304 Not Modified狀態，沒有主體，它告訴客戶端響應的緩存仍然可使用。

HTTP CROS 跨域

CROS 的全稱是 Cross-Origin Resource Sharing(CROS)，中文譯爲 跨域資源共享，它是一種機制。是一種什麼機制呢？它是一種讓運行在一個域(origin)上的 Web 應用被准許訪問來自不一樣源服務器上指定資源的機制。在搞懂這個機制前，你須要線瞭解什麼是 域(origin)

Origin

Web 概念中域(Origin) 的內容由scheme(protocol) - 協議，host(domain) - 主機和用於訪問它的 URL port - 端口定義。僅僅當 scheme 、host、port 都匹配時，兩個對象纔有相同的來源。這種協議相同，域名相同，端口相同的安全策略也被稱爲 同源策略（Same Origin Policy)。某些操做僅限於具備相同來源的內容，可使用 CORS 取消此限制。

跨域的特色

• 下面是跨域問題的例子，看看你是否清楚什麼是跨域了

(1) http://example.com/app1/index.html
(2) http://example.com/app2/index.html

上面這兩個 URL 是否具備跨域問題呢？

上面兩個 URL 是不具備跨域問題的，由於這兩個 URL 具備相同的協議(scheme)和主機(host)

• 那麼下面這兩個是否具備跨域問題呢？

http://Example.com:80
http://example.com

這兩個 URL 也不具備跨域問題，爲何不具備，端口不同啊。其實它們兩個端口是同樣的。

或許你會認爲這兩個 URL 是不同的，放心，關於同樣不同的論據我給你拋出來了

協議和域名部分是不區分大小寫的，可是路徑部分則根據服務器平臺而定。Windows 和 Mac OS X 系統是不區分大小寫的，而採用UNIX和Linux系的服務器系統是區分大小寫的，

也就是說上面的 Example.com 和 example.com 實際上是一個網址，而且因爲兩個地址具備相同的 scheme 和 host ，默認狀況下服務器經過端口80傳遞 HTTP 內容，因此上面這兩個地址也是相同的。

• 下面這兩個 URL 地址是否具備跨域問題？

http://example.com/app1
https://example.com/app2

這兩個 URL 的 scheme 不一樣，因此這兩個 URL 具備跨域問題

• 再看下面這三個 URL 是否具備跨域問題

http://example.com
http://www.example.com
http://myapp.example.com

這三個 URL 也是具備跨域問題的，由於它們隸屬於不通服務器的主機 host。

• 下面這兩個 URL 是否具備跨域問題

http://example.com
http://example.com:8080

這兩個 URL 也是具備跨域問題，由於這兩個 URL 的默認端口不同。

同源策略

處於安全的因素，瀏覽器限制了從腳本發起跨域的 HTTP 請求。 XMLHttpRequest 和其餘 Fetch 接口 會遵循 同源策略(same-origin policy)。也就是說使用這些 API 的應用程序想要請求相同的資源，那麼他們應該具備相同的來源，除非來自其餘來源的響應包括正確的 CORS 標頭也能夠。

同源策略是一種很重要的安全策略，它限制了從一個來源加載的文檔或腳本如何與另外一個來源的資源進行交互。 它有助於隔離潛在的惡意文檔，減小可能的攻擊媒介。

咱們上面提到，若是兩個 URL 具備相同的協議、主機和端口號（若是指定）的話，那麼兩個 URL 具備相同的來源。下面有一些實例，你判斷一下是否是具備相同的來源

目標來源 http://store.company.com/dir/page.html

URL	Outcome	Reason
http://store.company.com/dir2/other.html	相同來源	只有path不一樣
http://store.company.com/dir/inner/another.html	相同來源	只有path不一樣
https://store.company.com/page.html	不一樣來源	協議不通
http://store.company.com:81/dir/page.html	不一樣來源	默認端口不一樣
http://news.company.com/dir/page.html	不一樣來源	主機不一樣

如今我帶你認識了兩遍不一樣的源，如今你應該知道如何區分兩個 URL 是否屬於同一來源了吧！

好，你如今知道了什麼是跨域問題，如今我要問你，哪些請求會產生跨域請求呢？這是咱們下面要討論的問題

跨域請求

跨域請求可能會從下面這幾種請求中發出：

1. 調用 XMLHttpRequest 或者 Fetch api。

XMLHttpRequest 是什麼？（我是後端程序員，前端不太懂，簡單解釋下，若是解釋的很差，還請前端大佬們不要胖揍我）

全部的現代瀏覽器都有一個內置的 XMLHttpReqeust 對象，這個對象能夠用於從服務器請求數據。

XMLHttpReqeust 對於開發人員來講很重要，XMLHttpReqeust 對象能夠用來作下面這些事情

• 更新網頁無需從新刷新頁面
• 頁面加載後從服務器請求數據
• 頁面加載後從服務端獲取數據
• 在後臺將數據發送到服務器

使用 XMLHttpRequest(XHR) 對象與服務器進行交互，你能夠從 URL 檢索數據從而沒必要刷新整個頁面，這使網頁能夠更新頁面的一部分，而不會中斷用戶的操做。XMLHttpRequest 在 AJAX 異步編程中使用很普遍。

再來講一下 Fetch API 是什麼，Fetch 提供了請求和響應對象（以及其餘網絡請求）的通用定義。它還提供了相關概念的定義，例如 CORS 和 HTTP Origin 頭語義，並在其餘地方取代了它們各自的定義。

1. Web 字體（用於 CSS 中@ font-face中的跨域字體使用），以便服務器能夠部署 TrueType 字體，這些字體只能由容許跨站點加載和使用的網站使用。
2. WebGL 紋理
3. 使用 drawImage() 繪製到畫布上的圖像/視頻幀
4. 圖片的 CSS 形狀

跨域功能概述

跨域資源共享標準經過添加新的 HTTP 標頭來工做，這些標頭容許服務器描述容許哪些來源從 Web 瀏覽器讀取信息。另外，對於可能致使服務器數據產生反作用的 HTTP 請求方法（尤爲是 GET 或者具備某些 MIME 類型 POST 方法之外 HTTP 方法），該規範要求瀏覽器預檢請求，使用 HTTP OPTIONS 請求方法從服務器請求受支持的方法，而後在服務器批准後發送實際請求。服務器還能夠通知客戶端是否應與請求一塊兒發送憑據（例如 Cookies 和 HTTP 身份驗證）。

注意：CORS 故障會致使錯誤，可是出於安全緣由，該錯誤的詳細信息不適用於 JavaScript。 全部代碼都知道發生了錯誤。 肯定具體出問題的惟一方法是查看瀏覽器的控制檯以獲取詳細信息。

訪問控制

下面我會和你們探討三種方案，這些方案都演示了跨域資源共享的工做方式。全部這些示例都使用XMLHttpRequest，它能夠在任何支持的瀏覽器中發出跨站點請求。

簡單請求

一些請求不會觸發 CORS預檢（關於預檢咱們後面再介紹）。簡單請求是知足一下全部條件的請求

• 容許如下的方法：GET、HEAD和 POST

• 除了由用戶代理自動設置的標頭（例如 Connection、User-Agent 或者在 Fetch 規範中定義爲禁止標頭名稱的其餘標頭）外，惟一容許手動設置的標頭是那些 Fetch 規範將其定義爲 CORS安全列出的請求標頭 ，它們是：

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type（下面會介紹）
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width

• Content-Type 標頭的惟一容許的值是

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

• 沒有在請求中使用的任何 XMLHttpRequestUpload 對象上註冊事件偵聽器；這些可使用XMLHttpRequest.upload 屬性進行訪問。

• 請求中未使用 ReadableStream對象。

  例如，假定 web 內容 https://foo.example 想要獲取 https://bar.other 域的資源，那麼 JavaScript 中的代碼可能會像下面這樣寫

  const xhr = new XMLHttpRequest();
  const url = 'https://bar.other/resources/public-data/';
  
  xhr.open('GET', url);
  xhr.onreadystatechange = someHandler;
  xhr.send();

這使用 CORS 標頭來處理特權，從而在客戶端和服務器之間執行某種轉換。

讓咱們看看在這種狀況下瀏覽器將發送到服務器的內容，並讓咱們看看服務器如何響應：

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example

注意請求的標頭 Origin ，它代表調用來自於 https://foo.example。讓咱們看看服務器是如何響應的

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[…XML Data…]

服務端發送 Access-Control-Allow-Origin 做爲響應。使用 Origin 標頭和 Access-Control-Allow-Origin 展現了最簡單的訪問控制協議。在這個事例中，服務端使用 Access-Control-Allow-Origin 做爲響應，也就說明該資源能夠被任何域訪問。

若是位於https://bar.other的資源全部者但願將對資源的訪問限制爲僅來自https://foo.example的請求，他們應該發送以下響應

Access-Control-Allow-Origin: https://foo.example

如今除了 https://foo.example 以外的任何域都沒法以跨域方式訪問到 https://bar.other 的資源。

預檢請求

和上面探討的簡單請求不一樣，預檢請求首先經過 OPTIONS 方法向另外一個域上的資源發送 HTTP 請求，用來肯定實際請求是否能夠安全的發送。跨站點這樣被預檢，由於它們可能會影響用戶數據。

下面是一個預檢事例

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

上面的事例建立了一個 XML 請求體用來和 POST 請求一塊兒發送。此外，設置了非標準請求頭 X-PINGOTHER ，這個標頭不是 HTTP/1.1 的一部分，但一般對 Web 程序頗有用。因爲請求的 Content-Type 使用 application/xml，而且設置了自定義標頭，所以該請求被預檢。以下圖所示

以下所述，實際的 POST 請求不包含 Access-Control-Request- * 標頭；只有 OPTIONS 請求才須要它們。

下面咱們來看一下完整的客戶端/服務器交互，首先是預檢請求/響應

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

HTTP/1.1 204 No Content
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive

上面的1 -11 行表明預檢請求，預檢請求使用 OPYIIONS 方法，瀏覽器根據上面的 JavaScript 代碼段所使用的請求參數肯定是否須要發送此請求，以便服務器能夠響應是否可使用實際請求參數發送請求。OPTIONS 是一種 HTTP / 1.1方法，用於肯定來自服務器的更多信息，而且是一種安全的方法，這意味着它不能用於更改資源。請注意，與 OPTIONS 請求一塊兒，還發送了另外兩個請求標頭（分別是第9行和第10行）

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

Access-Control-Request-Method 標頭做爲預檢請求的一部分通知服務器，當發送實際請求時，將使用POST 請求方法發送該請求。

Access-Control-Request-Headers 標頭通知服務器，當發送請求時，它將與X-PINGOTHER 和 Content-Type 自定義標頭一塊兒發送。服務器能夠肯定這種狀況下是否接受請求。

下面的 1 - 11行是服務器發回的響應，表示POST 請求和 X-PINGOTHER 是能夠接受的，咱們着重看一下下面這幾行

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

服務器完成響應代表源 http://foo.example 是能夠接受的 URL，可以容許 POST、GET、OPTIONS 進行請求，容許自定義標頭 X-PINGOTHER, Content-Type。最後，Access-Control-Max-Age 以秒爲單位給出一個值，這個值表示對預檢請求的響應能夠緩存多長時間，在此期間內無需發送其餘預檢請求。

完成預檢請求後，將發送實際請求：

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: https://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: https://foo.example
Pragma: no-cache
Cache-Control: no-cache

<person><name>Arun</name></person>

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

正式響應中不少標頭咱們在以前的文章已經探討過了，本篇再也不作詳細的介紹，讀者能夠參考
你還在爲 HTTP 的這些概念頭疼嗎？ 查閱

帶憑證的請求

XMLHttpRequest 或 Fetch 和 CORS 最有趣的功能就是可以發出知道 HTTP Cookie 和 HTTP 身份驗證的 憑證 請求。默認狀況下，在跨站點 XMLHttpRequest 或 Fetch 調用中，瀏覽器將不發送憑據。調用 XMLHttpRequest對象或 Request 構造函數時必須設置一個特定的標誌。

在下面這個例子中，最初從 http://foo.example 加載的內容對設置了 Cookies 的 http://bar.other 上的資源進行了簡單的 GET 請求， foo.example 上可能的代碼以下

const invocation = new XMLHttpRequest();
const url = 'http://bar.other/resources/credentialed-content/';
    
function callOtherDomain() {
  if (invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

第7行顯示 XMLHttpRequest 上的標誌，必須設置該標誌才能使用 Cookie 進行調用。默認狀況下，調用是不在使用 Cookie 的狀況下進行的。因爲這是一個簡單的 GET 請求，所以不會進行預檢，可是瀏覽器將拒絕任何沒有 Access-Control-Allow-Credentials 的響應：標頭爲true，指的是響應不會返回 web 頁面的內容。

上面的請求用下圖能夠表示

這是客戶端和服務器之間的示例交換：

GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain


[text/plain payload]

上面第10行包含指向http://bar.other 上的內容 Cookie，可是若是 bar.other 沒有以 Access-Control-Allow-Credentials:true 響應（下面第五行），響應將被忽略，而且不能使用網站返回的內容。

請求憑證和通配符

當迴應憑證請求時，服務器必須在 Access-Control-Allow-Credentials 中指定一個來源，而不能直接寫* 通配符

由於上面示例代碼中的請求標頭包含 Cookie 標頭，若是 Access-Control-Allow-Credentials 中是指定的通配符 * 的話，請求會失敗。

注意上面示例中的 Set-Cookie 響應標頭還設置了另一個值，若是發生故障，將引起異常（取決於所使用的API）。

HTTP 響應標頭

下面會列出一些服務器跨域共享規範定義的 HTTP 標頭，上面簡單概述了一下，如今一塊兒來認識一下，主要會介紹下面這些

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Allow-Headers
• Access-Control-Allow-Methods
• Access-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Request-Headers
• Access-Control-Request-Method
• Origin

Access-Control-Allow-Origin

Access-Control-Allow-Origin 是 HTTP 響應標頭，指示響應是否可以和給定的源共享資源。Access-Control-Allow-Origin 指定單個資源會告訴瀏覽器容許指定來源訪問資源。對於沒有憑據的請求 *通配符，告訴瀏覽器容許任何源訪問資源。

例如，若是要容許源 https://mozilla.org 的代碼訪問資源，可使用以下的指定方式

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

若是服務器指定單個來源而不是*通配符，則服務器還應在 Vary 響應標頭中包含該來源。

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials 是 HTTP 的響應標頭，這個標頭告訴瀏覽器，當包含憑證請求（Request.credentials）時是否將響應公開給前端 JavaScript 代碼。

這時候你會問到 Request.credentials 是什麼玩意？不要着急，來給你看一下，首先來看 Request 是什麼玩意，

實際上，Request 是 Fetch API 的一類接口表明着資源請求。通常建立 Request 對象有兩種方式

• 使用 Request() 構造函數建立一個 Request 對象
• 還能夠經過 FetchEvent.request api 操做來建立

再來講下 Request.credentials 是什麼意思，Request 接口的憑據只讀屬性指示在跨域請求的狀況下，用戶代理是否應從其餘域發送 cookie。（其餘 Request 對象的方法詳見 https://developer.mozilla.org/en-US/docs/Web/API/Request）

當發送的是憑證模式的請求包含 （Request.credentials）時，若是 Access-Control-Allow-Credentials 值爲 true，瀏覽器將僅向前端 JavaScript 代碼公開響應。

Access-Control-Allow-Credentials: true

憑證通常包括 cookie、認證頭和 TLS 客戶端證書

當用做對預檢請求響應的一部分時，這代表是否可使用憑據發出實際請求。注意簡單的 GET 請求不會進行預檢。

能夠參考一個實際的例子 https://www.jianshu.com/p/ea485e5665b3

Access-Control-Allow-Headers

Access-Control-Allow-Headers 是一個響應標頭，這個標頭用來響應預檢請求，它發出實際請求時可使用哪些HTTP標頭。

示例

• 自定義標頭

這是 Access-Control-Allow-Headers 標頭的示例。它代表除了像 CROS 安全列出的請求標頭外，對服務器的 CROS 請求還支持名爲 X-Custom-Header 的自定義標頭。

Access-Control-Allow-Headers: X-Custom-Header

• 多個標頭

這個例子展現了 Access-Control-Allow-Headers 如何使用多個標頭

Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests

• 繞過其餘限制

儘管始終容許使用 CORS 安全列出的請求標頭，而且一般不須要在 Access-Control-Allow-Headers 中列出這些標頭，可是不管如何列出它們都將繞開適用的其餘限制。

Access-Control-Allow-Headers: Accept

這裏你可能會有疑問，哪些是 CORS 列出的安全標頭？（別嫌累，就是這麼麻煩）

有下面這些 Accep、Accept-Language、Content-Language、Content-Type ，當且僅當包含這些標頭時，無需在 CORS 上下文中發送預檢請求。

Access-Control-Allow-Methods

Access-Control-Allow-Methods 也是響應標頭，它指定了哪些訪問資源的方法可使用預檢請求。例如

Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Methods: *

Access-Control-Expose-Headers

Access-Control-Expose-Headers 響應標頭代表哪些標頭能夠做爲響應的一部分公開。默認狀況下，僅公開6個CORS安全列出的響應標頭，分別是

• Cache-Control
• Content-Language
• Content-Type
• Expires
• Last-Modified
• Pragma

若是但願客戶端可以訪問其餘標頭，則必須使用 Access-Control-Expose-Headers 標頭列出它們。下面是示例

要公開非 CORS 安全列出的請求標頭，能夠像以下這樣指定

Access-Control-Expose-Headers: Content-Length

要另外公開自定義標頭，例如 X-Kuma-Revision，能夠指定多個標頭，並用逗號分隔

Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision

在不是憑證請求中，你還可使用通配符

Access-Control-Expose-Headers: *

可是，這不會通配 Authorization 標頭，所以若是須要公開它，則須要明確列出

Access-Control-Expose-Headers: *, Authorization

Access-Control-Max-Age

Access-Control-Max-Age 響應頭表示預檢請求的結果能夠緩存多長時間，例如

Access-Control-Max-Age: 600

表示預檢請求能夠緩存10分鐘

Access-Control-Request-Headers

瀏覽器在發出預檢請求時使用 Access-Control-Request-Headers 請求標頭，使服務器知道在發出實際請求時客戶端可能發送的 HTTP 標頭。

Access-Control-Request-Headers: X-PINGOTHER, Content-Type

Access-Control-Request-Method

一樣的，Access-Control-Request-Method 響應標頭告訴服務器發出預檢請求時將使用那種 HTTP 方法。此標頭是必需的，由於預檢請求始終是 OPTIONS，而且使用的方法與實際請求不一樣。

Access-Control-Request-Method: POST

Origin

Origin 請求標頭代表匹配的來源，它不包含任何信息，僅僅包含服務器名稱，它與 CORS 請求以及 POST 請求一塊兒發送，它相似於 Referer 標頭，但與此標頭不一樣，它沒有公開整個路徑。例如

Origin: https://developer.mozilla.org

HTTP 條件請求

HTTP 具備條件請求的概念，經過比較資源更新生成的值與驗證器的值進行比較，來肯定資源是否進行過更新。這樣的請求對於驗證緩存的內容、條件請求、驗證資源的完整性來講很是重要。

原則

HTTP 條件請求是根據特定標頭的值執行不一樣的請求，這些標頭定義了一個前提條件，若是前提條件匹配或不匹配，則請求的結果將有所不一樣。

• 對於 安全 的方法，像是 GET、用於請求文檔的資源，僅當條件請求的條件知足時發回文檔資源，因此，這種方式能夠節約帶寬。

什麼是安全的方法，對於 HTTP 來講，安全的方法是不會改變服務器狀態的方法，換句話說，若是方法只是只讀操做，那麼它確定是安全的方法，好比說 GET 請求，它確定是安全的方法，由於它只是請求資源。幾種常見的方法確定是安全的，它們是 GET、HEAD和 OPTIONS。全部安全的方法都是冪等的（這他媽冪等又是啥意思？）但不是全部冪等的方法都是安全的，例如 PUT 和 DELETE 都是冪等的，但不安全。

冪等性：若是相同的客戶端發起一次或者屢次 HTTP 請求會獲得相同的結果，則說明 HTTP 是冪等的。（咱們此次不深究冪等性）

• 對於 非安全 的方法，像是 PUT，只有原始文檔與服務器上存儲的資源相同時，纔可使用條件請求來傳輸文檔。（PUT 方法一般用來傳輸文件，就像 FTP 協議的文件上傳同樣）

驗證

全部的條件請求都會嘗試檢查服務器上存儲的資源是否與某個特定版本的資源相匹配。爲了知足這種狀況，條件請求須要指示資源的版本。因爲沒法和整個文件逐個字符進行比較，所以須要把整個文件描繪成一個值，而後把此值和服務器上的資源進行比較，這種方式稱爲比較器，比較器有兩個條件

• 文檔的最後修改日期
• 一個不透明的字符串，用於惟一標識每一個版本，稱爲實體標籤或 Etag。

比較兩個資源是否時相同的版本有些複雜，根據上下文，有兩種相等性檢查

• 當指望的是字節對字節進行比較時，例如在恢復下載時，使用強 Etag進行驗證
• 當用戶代理須要比較兩個資源是否具備相同的內容時，使用若 Etag 進行驗證

HTTP 協議默認使用 強驗證，它指定什麼時候進行弱驗證

強驗證

強驗證保證的是字節 級別的驗證，嚴格的驗證很是嚴格，可能在服務器級別難以保證，可是它可以保證任什麼時候候都不會丟失數據，但這種驗證丟失性能。

要使用 Last-Modified 很難實現強驗證，一般，這是經過使用帶有資源的 MD5 哈希值的 Etag 來完成的。

弱驗證

弱驗證不一樣於強驗證，由於若是內容相等，它將認爲文檔的兩個版本相同，例如，一個頁面與另外一個頁面的不一樣之處僅在於頁腳的日期不一樣，所以該頁面被認爲與其餘頁面相同。而使用強驗證時則被認爲這兩個版本是不一樣的。構建一個若驗證的 Etag 系統可能會很是複雜，由於這須要瞭解每一個頁面元素的重要性，可是對於優化緩存性能很是有用。

下面介紹一下 Etag 如何實現強弱驗證。

Etag 響應頭是特定版本的標識，它可以使緩存變得更高效並可以節省帶寬，由於若是緩存內容未發生變動，Web 服務器則不須要從新發送完整的響應。除此以外，Etag 可以防止資源同時更新互相覆蓋。

若是給定 URL 上的資源發生變動，必須生成一個新的 Etag 值，經過比較它們能夠肯定資源的兩個表示形式是否相同。

Etag 值有兩種，一種是強 Etag，一種是弱 Etag；

• 強 Etag 值，不管實體發生多麼細微的變化都會改變其值，通常的表示以下

Etag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

• 弱 Etag 值，弱 Etag 值只用於提示資源是否相同。只有資源發生了根本改變，產生差別時纔會改變 Etag 值。這時，會在字段值最開始處附加 W/。

Etag: W/"0815"

下面就來具體探討一下條件請求的標頭和 Etag 的關係

條件請求

條件請求主要包含的標頭以下

• If-Match
• If-None-Match
• If-Modified-Since
• If-Unmodified-Since
• If-Range

If-Match

對於 GET 和 POST 方法，服務器僅在與列出的 Etag（響應標頭） 之一匹配時才返回請求的資源。這裏又多了一個新詞 Etag，咱們稍後再說 Etag 的用法。對於像是 PUT 和其餘非安全的方法，在這種狀況下，它僅僅將上傳資源。

下面是兩種常見的案例

• 對於 GET 和 POST 方法，會結合使用 Range 標頭，它能夠確保新發送請求的範圍與上一個請求的資源相同，若是不匹配的話，會返回 416 響應。
• 對於其餘方法，特別是 PUT 方法，If-Match 能夠防止丟失更新，服務器會比對 If-Match 的字段值和資源的 Etag 值，僅當二者一致時，纔會執行請求。反之，則返回狀態碼 412 Precondition Failed 的響應。例如

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-Match: *

If-None-Match

條件請求，它與 If-Match 的做用相反，僅當 If-None-Match 的字段值與 Etag 值不一致時，可處理該請求。對於GET 和 HEAD ，僅當服務器沒有與給定資源匹配的 Etag 時，服務器將返回 200 OK做爲響應。對於其餘方法，僅當最終現有資源的 Etag 與列出的任何值都不匹配時，纔會處理請求。

當 GET 和 POST 發送的 If-None-Match與 Etag 匹配時，服務器會返回 304。

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

If-Modified-Since

If-Modified-Since 是 HTTP 條件請求的一部分，只有在給定日期以後，服務端修改了請求所須要的資源，纔會返回 200 OK 的響應。若是在給定日期以後，服務端沒有修改內容，響應會返回 304 而且不帶任何響應體。If-Modified-Since 只能使用 GET 和 HEAD 請求。

If-Modified-Since 與 If-None-Match 結合使用時，它將被忽略，除非服務器不支持 If-None-Match。通常表示以下

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

注意：這是格林威治標準時間。 HTTP 日期始終以格林尼治標準時間表示，而不是本地時間。

If-Range

If-Range 也是條件請求，若是知足條件（If-Range 的值和 Etag 值或者更新的日期時間一致），則會發出範圍請求，不然將會返回所有資源。它的通常表示以下

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

If-Unmodified-Since

If-Unmodified-Since HTTP 請求標頭也是一個條件請求，服務器只有在給定日期以後沒有對其進行修改時，服務器才返回請求資源。若是在指定日期時間後發生了更新，則以狀態碼 412 Precondition Failed 做爲響應返回。

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

條件請求示例

緩存更新

條件請求最多見的示例就是更新緩存，若是緩存是空或沒有緩存，則以200 OK的狀態發送回請求的資源。以下圖所示

客戶端第一次發送請求沒有，緩存爲空而且沒有條件請求，服務器在收到客戶端請求後，設置驗證器 Last-Modified 和 Etag 標籤，並把這兩個標籤隨着響應一塊兒發送回客戶端。

下一次客戶端再發送相同的請求後，會直接從緩存中提取，只要緩存沒有過時，就不會有任何新的請求到達服務器從新下載資源。可是，一旦緩存過時，客戶端不會直接使用緩存的值，而是發出條件請求。 驗證器的值用做 If-Modified-Since 和If-Match標頭的參數。

緩存過時後客戶端從新發起請求，服務器收到請求後發現若是資源沒有更改，服務器會發回 304 Not Modified響應，這使緩存再次刷新，並讓客戶端使用緩存的資源。 儘管有一個響應/請求往返消耗一些資源，可是這比再次經過有線傳輸整個資源更有效。

若是資源已經發生更改，則服務器僅使用新版本的資源返回 200 OK 響應，就像沒有條件請求，而且客戶端會從新使用新的資源，從這個角度來說，緩存是條件請求的前置條件。

斷點續傳

HTTP 能夠支持文件的部分下載，經過保留已得到的信息，此功能容許恢復先前的操做，從而節省帶寬和時間。

支持斷點續傳的服務器經過發送 Accept-Ranges 標頭廣播此消息，一旦發生這種狀況，客戶端能夠經過發送缺乏範圍的 Ranges標頭來恢復下載

這裏你可能有疑問 Ranges 和 Content-Range是什麼，來解釋一下

Range

Range HTTP 請求標頭指示服務器應返回文檔指定部分的資源，能夠一次請求一個 Range 來返回多個部分，服務器會將這些資源返回各個文檔中。若是服務器成功返回，那麼將返回 206 響應；若是 Range 範圍無效，服務器返回416 Range Not Satisfiable錯誤；服務器還能夠忽略 Range 標頭，而且返回 200 做爲響應。

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

還有一種表示是

Range: bytes=0-499, -500

它們分別表示請求前500個字節和最後500個字節，若是範圍重疊，則服務器可能會拒絕該請求。

Content-Range

HTTP 的 Content-Range 響應標頭是針對範圍請求而設定的，返回響應時使用首部字段 Content-Range，可以告知客戶端響應實體的哪部分是符合客戶端請求的，字段以字節爲單位。它的通常表示以下

Content-Range: bytes 200-1000/67589

上段代碼表示從全部 67589 個字節中返回 200-1000 個字節的內容

那麼上面的 Content-Range你也應該知道是什麼意思了

斷點續傳的原理比較簡單，可是這種方式存在潛在的問題：若是在兩次下載資源的期間進行了資源更新，那麼得到的範圍將對應於資源的兩個不一樣版本，而且最終文檔將被破壞。

爲了阻止這種狀況的出現，就會使用條件請求。對於範圍來講，有兩種方法能夠作到這一點。一種方法是使用 If-Modified-Since和If-Match，若是前提條件失敗，服務器將返回錯誤；而後客戶端從頭開始從新下載。

即便此方法有效，當文檔資源發生改變時，它也會添加額外的 響應/請求 交換。這會下降性能，而且 HTTP 具備特定的標頭來避免這種狀況 If-Range。

該解決方案效率更高，但靈活性稍差一些，由於在這種狀況下只能使用一個 Etag。

經過樂觀鎖避免丟失更新

Web 應用程序中最廣泛的操做是資源更新。這在任何文件系統或應用程序中都很常見，可是任何容許存儲遠程資源的應用程序都須要這種機制。

使用 put 方法，你能夠實現這一點，客戶端首先讀取原始文件對其進行修改，而後把它們發送到服務器。

上面這種請求響應存在問題，一旦考慮到併發性，事情就會變得不許確。當客戶端在本地修改資源打算從新發送以前，第二個客戶端能夠獲取相同的資源並對資源進行修改操做，這樣就會形成問題。當它們從新發送請求到服務器時，第一個客戶端所作的修改將被第二次客戶端的修改所覆蓋，由於第二次客戶端修改並不知道第一次客戶端正在修改。資源提交併更新的一方不會傳達給另一方，因此要保留哪一個客戶的更改，將隨着他們提交的速度而變化； 這取決於客戶端，服務器的性能，甚至取決於人工在客戶端編輯文檔的性能。 例以下面這個流程

若是沒有兩個用戶同時操做服務器，也就不存在這個問題。可是，現實狀況是不可能只有單個用戶出現的，因此爲了規避或者避免這個問題，咱們但願客戶端資源在更新時進行提示或者修改被拒絕時收到通知。

條件請求容許實現樂觀鎖算法。這個概念是容許全部的客戶端獲取資源的副本，而後讓他們在本地修改資源，併成功經過容許第一個客戶端提交更新來控制併發，基於此服務端的後面版本的更新都將被拒絕。

這是使用 If-Match 或 If-Unmodified-Since標頭實現的。若是 Etag 與原始文件不匹配，或者自獲取以來已對文件進行了修改，則更改成拒絕更新，並顯示412 Precondition Failed錯誤。

HTTP Cookies

HTTP 協議中的 Cookie 包括 Web Cookie 和瀏覽器 Cookie，它是服務器發送到 Web 瀏覽器的一小塊數據。服務器發送到瀏覽器的 Cookie，瀏覽器會進行存儲，並與下一個請求一塊兒發送到服務器。一般，它用於判斷兩個請求是否來自於同一個瀏覽器，例如用戶保持登陸狀態。

HTTP Cookie 機制是 HTTP 協議無狀態的一種補充和改良

Cookie 主要用於下面三個目的

• 會話管理

登錄、購物車、遊戲得分或者服務器應該記住的其餘內容

• 個性化

用戶偏好、主題或者其餘設置

• 追蹤

記錄和分析用戶行爲

Cookie 曾經用於通常的客戶端存儲。雖然這是合法的，由於它們是在客戶端上存儲數據的惟一方法，但現在建議使用現代存儲 API。Cookie 隨每一個請求一塊兒發送，所以它們可能會下降性能（尤爲是對於移動數據鏈接而言）。客戶端存儲的現代 API 是 Web 存儲 API（localStorage 和 sessionStorage）和 IndexedDB。

建立 Cookie

當接收到客戶端發出的 HTTP 請求時，服務器能夠發送帶有響應的 Set-Cookie 標頭，Cookie 一般由瀏覽器存儲，而後將 Cookie 與 HTTP 標頭一同向服務器發出請求。能夠指定到期日期或持續時間，以後將再也不發送Cookie。此外，能夠設置對特定域和路徑的限制，從而限制 cookie 的發送位置。

Set-Cookie 和 Cookie 標頭

Set-Cookie HTTP 響應標頭將 cookie 從服務器發送到用戶代理。下面是一個發送 Cookie 的例子

HTTP/2.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

此標頭告訴客戶端存儲 Cookie

如今，隨着對服務器的每一個新請求，瀏覽器將使用 Cookie 頭將全部之前存儲的 cookie 發送回服務器。

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Cookie 主要分爲三類，它們是 會話Cookie、永久Cookie 和 Cookie的 Secure 和 HttpOnly 標記，下面依次來介紹一下

會話 Cookies

上面的示例建立的是會話 Cookie ，會話 Cookie 有個特徵，客戶端關閉時 Cookie 會刪除，由於它沒有指定Expires 或 Max-Age 指令。 這兩個指令你看到這裏應該比較熟悉了。

可是，Web 瀏覽器可能會使用會話還原，這會使大多數會話 Cookie 保持永久狀態，就像從未關閉過瀏覽器同樣

永久性 Cookies

永久性 Cookie 不會在客戶端關閉時過時，而是在特定日期（Expires）或特定時間長度（Max-Age）外過時。例如

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Cookie的 Secure 和 HttpOnly 標記

安全的 Cookie 須要通過 HTTPS 協議經過加密的方式發送到服務器。即便是安全的，也不該該將敏感信息存儲在cookie 中，由於它們本質上是不安全的，而且此標誌不能提供真正的保護。

HttpOnly 的做用

• 會話 cookie 中缺乏 HttpOnly 屬性會致使攻擊者能夠經過程序(JS腳本、Applet等)獲取到用戶的 cookie 信息，形成用戶cookie 信息泄露，增長攻擊者的跨站腳本攻擊威脅。

• HttpOnly 是微軟對 cookie 作的擴展，該值指定 cookie 是否可經過客戶端腳本訪問。

• 若是在 Cookie 中沒有設置 HttpOnly 屬性爲 true，可能致使 Cookie 被竊取。竊取的 Cookie 能夠包含標識站點用戶的敏感信息，如 ASP.NET 會話 ID 或 Forms 身份驗證票證，攻擊者能夠重播竊取的 Cookie，以便假裝成用戶或獲取敏感信息，進行跨站腳本攻擊等。

Cookie 的做用域

Domain 和 Path 標識定義了 Cookie 的做用域：即 Cookie 應該發送給哪些 URL。

Domain 標識指定了哪些主機能夠接受 Cookie。若是不指定，默認爲當前主機(不包含子域名）。若是指定了Domain，則通常包含子域名。

例如，若是設置 Domain=mozilla.org，則 Cookie 也包含在子域名中（如developer.mozilla.org）。

例如，設置 Path=/docs，則如下地址都會匹配：

• /docs
• /docs/Web/
• /docs/Web/HTTP

文章參考：

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

https://www.jianshu.com/p/5c41c536d47f

https://www.w3schools.com/php/default.asp

https://www.jianshu.com/p/ea485e5665b3

https://blog.csdn.net/qq_38098125/article/details/101213336