到目前為止，我們已經(jīng)對 ?fetch? 相當(dāng)了解了。

現(xiàn)在讓我們來看看 fetch 的剩余 API，來了解它的全部本領(lǐng)吧。

請注意：

請注意：這些選項(xiàng) (option) 大多都很少使用。即使跳過本章，你也可以很好地使用 fetch。

但是，知道 fetch 可以做什么還是很好的，所以如果需要，你可以來看看這些細(xì)節(jié)內(nèi)容。

這是所有可能的 fetch 選項(xiàng)及其默認(rèn)值（注釋中標(biāo)注了可選值）的完整列表：

let promise = fetch(url, {
  method: "GET", // POST，PUT，DELETE，等。
  headers: {
    // 內(nèi)容類型 header 值通常是自動(dòng)設(shè)置的
    // 取決于 request body
    "Content-Type": "text/plain;charset=UTF-8"
  },
  body: undefined // string，F(xiàn)ormData，Blob，BufferSource，或 URLSearchParams
  referrer: "about:client", // 或 "" 以不發(fā)送 Referer header，
  // 或者是當(dāng)前源的 url
  referrerPolicy: "no-referrer-when-downgrade", // no-referrer，origin，same-origin...
  mode: "cors", // same-origin，no-cors
  credentials: "same-origin", // omit，include
  cache: "default", // no-store，reload，no-cache，force-cache，或 only-if-cached
  redirect: "follow", // manual，error
  integrity: "", // 一個(gè) hash，像 "sha256-abcdef1234567890"
  keepalive: false, // true
  signal: undefined, // AbortController 來中止請求
  window: window // null
});

一個(gè)令人印象深刻的列表，對吧?

我們已經(jīng)在 Fetch 一章中詳細(xì)介紹了 method，headers 和 body。

在 Fetch：中止（Abort） 一章中介紹了 signal 選項(xiàng)。

現(xiàn)在讓我們一起探索其余的功能。

referrer，referrerPolicy

這些選項(xiàng)決定了 fetch 如何設(shè)置 HTTP 的 Referer header。

通常來說，這個(gè) header 是被自動(dòng)設(shè)置的，并包含了發(fā)出請求的頁面的 url。在大多數(shù)情況下，它一點(diǎn)也不重要，但有時(shí)出于安全考慮，刪除或縮短它是有意義的。

referrer 選項(xiàng)允許設(shè)置任何 Referer（在當(dāng)前域的），或者移除它。

如果不想發(fā)送 referrer，可以將 referrer 設(shè)置為空字符串：

fetch('/page', {
  referrer: "" // 沒有 Referer header
});

設(shè)置在當(dāng)前域內(nèi)的另一個(gè) url：

fetch('/page', {
  // 假設(shè)我們在 https://javascript.info
  // 我們可以設(shè)置任何 Referer header，但必須是在當(dāng)前域內(nèi)的
  referrer: "https://javascript.info/anotherpage"
});

referrerPolicy 選項(xiàng)為 Referer 設(shè)置一般的規(guī)則。

請求分為 3 種類型：

1. 同源請求。
2. 跨源請求。
3. 從 HTTPS 到 HTTP 的請求 (從安全協(xié)議到不安全協(xié)議)。

與 referrer 選項(xiàng)允許設(shè)置確切的 Referer 值不同，referrerPolicy 告訴瀏覽器針對各個(gè)請求類型的一般的規(guī)則。

可能的值在 Referrer Policy 規(guī)范中有詳細(xì)描述：

• ?"no-referrer-when-downgrade"? —— 默認(rèn)值：除非我們從 HTTPS 發(fā)送請求到 HTTP（到安全性較低的協(xié)議），否則始終會(huì)發(fā)送完整的 ?Referer?。
• ?"no-referrer"? —— 從不發(fā)送 ?Referer?。
• ?"origin"? —— 只發(fā)送在 ?Referer? 中的域，而不是完整的頁面 URL，例如，只發(fā)送 ?http://site.com? 而不是 ?http://site.com/path?。
• ?"origin-when-cross-origin"? —— 發(fā)送完整的 ?Referer? 到相同的源，但對于跨源請求，只發(fā)送域部分（同上）。
• ?"same-origin"? —— 發(fā)送完整的 ?Referer? 到相同的源，但對于跨源請求，不發(fā)送 ?Referer?。
• ?"strict-origin"? —— 只發(fā)送域，對于 HTTPS→HTTP 請求，則不發(fā)送 ?Referer?。
• ?"strict-origin-when-cross-origin"? —— 對于同源情況下則發(fā)送完整的 ?Referer?，對于跨源情況下，則只發(fā)送域，如果是 HTTPS→HTTP 請求，則什么都不發(fā)送。
• ?"unsafe-url"? —— 在 ?Referer? 中始終發(fā)送完整的 url，即使是 HTTPS→HTTP 請求。

這是一個(gè)包含所有組合的表格：

假如我們有一個(gè)帶有 URL 結(jié)構(gòu)的管理區(qū)域（admin zone），它不應(yīng)該被從網(wǎng)站外看到。

如果我們發(fā)送了一個(gè) fetch，則默認(rèn)情況下，它總是發(fā)送帶有頁面完整 url 的 Referer header（我們從 HTTPS 向 HTTP 發(fā)送請求的情況除外，這種情況下沒有 Referer）。

例如 Referer: https://javascript.info/admin/secret/paths。

如果我們想讓其他網(wǎng)站只知道域的部分，而不是 URL 路徑，我們可以這樣設(shè)置選項(xiàng)：

fetch('https://another.com/page', {
  // ...
  referrerPolicy: "origin-when-cross-origin" // Referer: https://javascript.info
});

我們可以將其置于所有 fetch 調(diào)用中，也可以將其集成到我們項(xiàng)目的執(zhí)行所有請求并在內(nèi)部使用 fetch 的 JavaScript 庫中。

與默認(rèn)行為相比，它的唯一區(qū)別在于，對于跨源請求，fetch 只發(fā)送 URL 域的部分（例如 https://javascript.info，沒有路徑）。對于同源請求，我們?nèi)匀豢梢垣@得完整的 Referer（可能對于調(diào)試目的是有用的）。

Referrer policy 不僅適用于 ?fetch?

在 規(guī)范 中描述的 referrer policy，不僅適用于 fetch，它還具有全局性。

特別是，可以使用 Referrer-Policy HTTP header，或者為每個(gè)鏈接設(shè)置 <a rel="noreferrer">，來為整個(gè)頁面設(shè)置默認(rèn)策略（policy）。

mode

mode 選項(xiàng)是一種安全措施，可以防止偶發(fā)的跨源請求：

• ?"cors"? —— 默認(rèn)值，允許跨源請求，如 Fetch：跨源請求 一章所述，
• ?"same-origin"? —— 禁止跨源請求，
• ?"no-cors"? —— 只允許安全的跨源請求。

當(dāng) fetch 的 URL 來自于第三方，并且我們想要一個(gè)“斷電開關(guān)”來限制跨源能力時(shí)，此選項(xiàng)可能很有用。

credentials

credentials 選項(xiàng)指定 fetch 是否應(yīng)該隨請求發(fā)送 cookie 和 HTTP-Authorization header。

• ?"same-origin"? —— 默認(rèn)值，對于跨源請求不發(fā)送，
• ?"include"? —— 總是發(fā)送，需要來自跨源服務(wù)器的 ?Access-Control-Allow-Credentials?，才能使 JavaScript 能夠訪問響應(yīng)，詳細(xì)內(nèi)容在 Fetch：跨源請求 一章有詳細(xì)介紹，
• ?"omit"? —— 不發(fā)送，即使對于同源請求。

cache

默認(rèn)情況下，fetch 請求使用標(biāo)準(zhǔn)的 HTTP 緩存。就是說，它遵從 Expires，Cache-Control header，發(fā)送 If-Modified-Since，等。就像常規(guī)的 HTTP 請求那樣。

使用 cache 選項(xiàng)可以忽略 HTTP 緩存或者對其用法進(jìn)行微調(diào)：

• ?"default"? —— ?fetch? 使用標(biāo)準(zhǔn)的 HTTP 緩存規(guī)則和 header，
• ?"no-store"? —— 完全忽略 HTTP 緩存，如果我們設(shè)置 header ?If-Modified-Since?，?If-None-Match?，?If-Unmodified-Since?，?If-Match?，或 ?If-Range?，則此模式會(huì)成為默認(rèn)模式，
• ?"reload"? —— 不從 HTTP 緩存中獲取結(jié)果（如果有），而是使用響應(yīng)填充緩存（如果 response header 允許此操作），
• ?"no-cache"? —— 如果有一個(gè)已緩存的響應(yīng)，則創(chuàng)建一個(gè)有條件的請求，否則創(chuàng)建一個(gè)普通的請求。使用響應(yīng)填充 HTTP 緩存，
• ?"force-cache"? —— 使用來自 HTTP 緩存的響應(yīng)，即使該響應(yīng)已過時(shí)（stale）。如果 HTTP 緩存中沒有響應(yīng)，則創(chuàng)建一個(gè)常規(guī)的 HTTP 請求，行為像正常那樣，
• ?"only-if-cached"? —— 使用來自 HTTP 緩存的響應(yīng)，即使該響應(yīng)已過時(shí)（stale）。如果 HTTP 緩存中沒有響應(yīng)，則報(bào)錯(cuò)。只有當(dāng) ?mode? 為 ?same-origin? 時(shí)生效。

redirect

通常來說，fetch 透明地遵循 HTTP 重定向，例如 301，302 等。

redirect 選項(xiàng)允許對此進(jìn)行更改：

• ?"follow"? —— 默認(rèn)值，遵循 HTTP 重定向，
• ?"error"? —— HTTP 重定向時(shí)報(bào)錯(cuò)，
• ?"manual"? —— 允許手動(dòng)處理 HTTP 重定向。在重定向的情況下，我們將獲得一個(gè)特殊的響應(yīng)對象，其中包含 ?response.type="opaqueredirect"? 和歸零/空狀態(tài)以及大多數(shù)其他屬性。

integrity

integrity 選項(xiàng)允許檢查響應(yīng)是否與已知的預(yù)先校驗(yàn)和相匹配。

正如 規(guī)范 所描述的，支持的哈希函數(shù)有 SHA-256，SHA-384，和 SHA-512，可能還有其他的，這取決于瀏覽器。

例如，我們下載一個(gè)文件，并且我們知道它的 SHA-256 校驗(yàn)和為 “abcdef”（當(dāng)然，實(shí)際校驗(yàn)和會(huì)更長）。

我們可以將其放在 integrity 選項(xiàng)中，就像這樣:

fetch('http://site.com/file', {
  integrity: 'sha256-abcdef'
});

然后 fetch 將自行計(jì)算 SHA-256 并將其與我們的字符串進(jìn)行比較。如果不匹配，則會(huì)觸發(fā)錯(cuò)誤。

keepalive

keepalive 選項(xiàng)表示該請求可能會(huì)在網(wǎng)頁關(guān)閉后繼續(xù)存在。

例如，我們收集有關(guān)當(dāng)前訪問者是如何使用我們的頁面（鼠標(biāo)點(diǎn)擊，他查看的頁面片段）的統(tǒng)計(jì)信息，以分析和改善用戶體驗(yàn)。

當(dāng)訪問者離開我們的網(wǎng)頁時(shí) —— 我們希望能夠?qū)?shù)據(jù)保存到我們的服務(wù)器上。

我們可以使用 window.onunload 事件來實(shí)現(xiàn)：

window.onunload = function() {
  fetch('/analytics', {
    method: 'POST',
    body: "statistics",
    keepalive: true
  });
};

通常，當(dāng)一個(gè)文檔被卸載時(shí)（unloaded），所有相關(guān)的網(wǎng)絡(luò)請求都會(huì)被中止。但是，keepalive 選項(xiàng)告訴瀏覽器，即使在離開頁面后，也要在后臺(tái)執(zhí)行請求。所以，此選項(xiàng)對于我們的請求成功至關(guān)重要。

它有一些限制：

• 我們無法發(fā)送兆字節(jié)的數(shù)據(jù)：?keepalive? 請求的 body 限制為 64KB。
• 如果我們需要收集有關(guān)訪問的大量統(tǒng)計(jì)信息，我們則應(yīng)該將其定期以數(shù)據(jù)包的形式發(fā)送出去，這樣就不會(huì)留下太多數(shù)據(jù)給最后的 ?onunload? 請求了。
• 此限制是被應(yīng)用于當(dāng)前所有 ?keepalive? 請求的總和的。換句話說，我們可以并行執(zhí)行多個(gè) ?keepalive? 請求，但它們的 body 長度之和不得超過 64KB。
• 如果文檔（document）已卸載（unloaded），我們就無法處理服務(wù)器響應(yīng)。因此，在我們的示例中，因?yàn)?nbsp;?keepalive?，所以 ?fetch? 會(huì)成功，但是后續(xù)的函數(shù)將無法正常工作。
• 在大多數(shù)情況下，例如發(fā)送統(tǒng)計(jì)信息，這不是問題，因?yàn)榉?wù)器只接收數(shù)據(jù)，并通常向此類請求發(fā)送空的響應(yīng)。