從輸入URL到渲染的完整過程

腹黑的可樂發表於2022-12-26

瀏覽器有一個重要的安全策略，稱之為「同源策略」

其中，源=協議+主機+埠，**兩個源相同，稱之為同源，兩個源不同，稱之為跨源或跨域

同源策略是指，若頁面的源和頁面執行過程中載入的源不一致時，出於安全考慮，瀏覽器會對跨域的資源訪問進行一些限制

image-20210916104747296

同源策略對 ajax 的跨域限制的最為兇狠，預設情況下，它不允許 ajax 訪問跨域資源

image-20210916105741041

所以，我們通常所說的跨域問題，就是同源策略對 ajax 產生的影響

有多種方式解決跨域問題，常見的有：

  • 代理，常用
  • CORS，常用
  • JSONP

無論使用哪一種方式，都是要讓瀏覽器知道，我這次跨域請求的是自己人，就不要攔截了。

跨域解決方法1-代理

對於前端開發而言，大部分的跨域問題，都是透過代理解決的

代理適用的場景是：生產環境不發生跨域，但開發環境發生跨域

因此，只需要在開發環境使用代理解決跨域即可，這種代理又稱之為開發代理

image-20210916125008693

在實際開發中，只需要對開發伺服器稍加配置即可完成

// vue 的開發伺服器代理配置
// vue.config.js
module.exports = {
  devServer: { // 配置開發伺服器
    proxy: { // 配置代理
      "/api": { // 若請求路徑以 /api 開頭
        target: "http://dev.taobao.com", // 將其轉發到 http://dev.taobao.com
      },
    },
  },
};

跨域解決方法2-JSONP

在CORS出現之前，人們想了一種奇妙的辦法來實現跨域，這就是JSONP。

要實現JSONP，需要瀏覽器和伺服器來一個天衣無縫的絕妙配合。

JSONP的做法是：當需要跨域請求時，不使用AJAX，轉而生成一個script元素去請求伺服器，由於瀏覽器並不阻止script元素的請求，這樣請求可以到達伺服器。伺服器拿到請求後，響應一段JS程式碼，這段程式碼實際上是一個函式呼叫，呼叫的是客戶端預先生成好的函式，並把瀏覽器需要的資料作為引數傳遞到函式中，從而間接的把資料傳遞給客戶端

image-20210916151516184

JSONP有著明顯的缺點，即其只能支援GET請求

跨域解決方法3-CORS

概述

CORS是基於http1.1的一種跨域解決方案，它的全稱是Cross-Origin Resource Sharing，跨域資源共享。

它的總體思路是：如果瀏覽器要跨域訪問伺服器的資源，需要獲得伺服器的允許

image-20200421152122793

而要知道，一個請求可以附帶很多資訊，從而會對伺服器造成不同程度的影響

比如有的請求只是獲取一些新聞，有的請求會改動伺服器的資料

針對不同的請求，CORS 規定了三種不同的互動模式，分別是：

  • 簡單請求
  • 需要預檢的請求
  • 附帶身份憑證的請求

這三種模式從上到下層層遞進，請求可以做的事越來越多，要求也越來越嚴格。

下面分別說明三種請求模式的具體規範。

簡單請求

當瀏覽器端執行了一段 ajax 程式碼（無論是使用 XMLHttpRequest 還是 fetch api），瀏覽器會首先判斷它屬於哪一種請求模式

參考 前端進階面試題詳細解答

簡單請求的判定

當請求同時滿足以下條件時，瀏覽器會認為它是一個簡單請求：

  1. 請求方法屬於下面的一種：

    • get
    • post
    • head

  2. 請求頭僅包含安全的欄位，常見的安全欄位如下：

    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type
    • DPR
    • Downlink
    • Save-Data
    • Viewport-Width
    • Width

  3. 請求頭如果包含Content-Type，僅限下面的值之一：

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

如果以上三個條件同時滿足，瀏覽器判定為簡單請求。

下面是一些例子：

// 簡單請求
fetch('http://crossdomain.com/api/news');

// 請求方法不滿足要求，不是簡單請求
fetch('http://crossdomain.com/api/news', {
  method: 'PUT',
});

// 加入了額外的請求頭，不是簡單請求
fetch('http://crossdomain.com/api/news', {
  headers: {
    a: 1,
  },
});

// 簡單請求
fetch('http://crossdomain.com/api/news', {
  method: 'post',
});

// content-type不滿足要求，不是簡單請求
fetch('http://crossdomain.com/api/news', {
  method: 'post',
  headers: {
    'content-type': 'application/json',
  },
});

簡單請求的互動規範

當瀏覽器判定某個ajax 跨域請求是簡單請求時，會發生以下的事情

  1. 請求頭中會自動新增Origin欄位

比如，在頁面http://my.com/index.html中有以下程式碼造成了跨域

// 簡單請求
fetch('http://crossdomain.com/api/news');

請求發出後，請求頭會是下面的格式：

GET /api/news/ HTTP/1.1
Host: crossdomain.com
Connection: keep-alive
...
Referer: http://my.com/index.html
Origin: http://my.com

看到最後一行沒，Origin欄位會告訴伺服器，是哪個源地址在跨域請求

  1. 伺服器響應頭中應包含Access-Control-Allow-Origin

當伺服器收到請求後，如果允許該請求跨域訪問，需要在響應頭中新增Access-Control-Allow-Origin欄位

該欄位的值可以是：

  • *：表示我很開放，什麼人我都允許訪問
  • 具體的源：比如http://my.com，表示我就允許你訪問

實際上，這兩個值對於客戶端http://my.com而言，都一樣，因為客戶端才不會管其他源伺服器允不允許，就關心自己是否被允許

當然，伺服器也可以維護一個可被允許的源列表，如果請求的Origin命中該列表，才響應*或具體的源

為了避免後續的麻煩，強烈推薦響應具體的源

假設伺服器做出了以下的響應：

HTTP/1.1 200 OK
Date: Tue, 21 Apr 2020 08:03:35 GMT
...
Access-Control-Allow-Origin: http://my.com
...

訊息體中的資料

當瀏覽器看到伺服器允許自己訪問後，高興的像一個兩百斤的孩子，於是，它就把響應順利的交給 js，以完成後續的操作

下圖簡述了整個互動過程

image-20200421162846480

需要預檢的請求

簡單的請求對伺服器的威脅不大，所以允許使用上述的簡單互動即可完成。

但是，如果瀏覽器不認為這是一種簡單請求，就會按照下面的流程進行：

  1. 瀏覽器傳送預檢請求，詢問伺服器是否允許
  2. 伺服器允許
  3. 瀏覽器傳送真實請求
  4. 伺服器完成真實的響應

比如，在頁面http://my.com/index.html中有以下程式碼造成了跨域

// 需要預檢的請求
fetch('http://crossdomain.com/api/user', {
  method: 'POST', // post 請求
  headers: {
    // 設定請求頭
    a: 1,
    b: 2,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ name: '袁小進', age: 18 }), // 設定請求體
});

瀏覽器發現它不是一個簡單請求，則會按照下面的流程與伺服器互動

  1. 瀏覽器傳送預檢請求，詢問伺服器是否允許
OPTIONS /api/user HTTP/1.1
Host: crossdomain.com
...
Origin: http://my.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: a, b, content-type

可以看出，這並非我們想要發出的真實請求，請求中不包含我們的請求頭，也沒有訊息體。

這是一個預檢請求，它的目的是詢問伺服器，是否允許後續的真實請求。

預檢請求沒有請求體，它包含了後續真實請求要做的事情

預檢請求有以下特徵：

  • 請求方法為OPTIONS
  • 沒有請求體

  • 請求頭中包含

    • Origin：請求的源，和簡單請求的含義一致
    • Access-Control-Request-Method：後續的真實請求將使用的請求方法
    • Access-Control-Request-Headers：後續的真實請求會改動的請求頭
  • 伺服器允許

伺服器收到預檢請求後，可以檢查預檢請求中包含的資訊，如果允許這樣的請求，需要響應下面的訊息格式

HTTP/1.1 200 OK
Date: Tue, 21 Apr 2020 08:03:35 GMT
...
Access-Control-Allow-Origin: http://my.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: a, b, content-type
Access-Control-Max-Age: 86400
...

對於預檢請求，不需要響應任何的訊息體，只需要在響應頭中新增：

  • Access-Control-Allow-Origin：和簡單請求一樣，表示允許的源
  • Access-Control-Allow-Methods：表示允許的後續真實的請求方法
  • Access-Control-Allow-Headers：表示允許改動的請求頭
  • Access-Control-Max-Age：告訴瀏覽器，多少秒內，對於同樣的請求源、方法、頭，都不需要再傳送預檢請求了
  • 瀏覽器傳送真實請求

預檢被伺服器允許後，瀏覽器就會傳送真實請求了，上面的程式碼會發生下面的請求資料

POST /api/user HTTP/1.1
Host: crossdomain.com
Connection: keep-alive
...
Referer: http://my.com/index.html
Origin: http://my.com

{"name": "xiaoming", "age": 18 }
  1. 伺服器響應真實請求
HTTP/1.1 200 OK
Date: Tue, 21 Apr 2020 08:03:35 GMT
...
Access-Control-Allow-Origin: http://my.com
...

新增使用者成功

可以看出，當完成預檢之後，後續的處理與簡單請求相同

下圖簡述了整個互動過程

image-20200421165913320

附帶身份憑證的請求

預設情況下，ajax 的跨域請求並不會附帶 cookie，這樣一來，某些需要許可權的操作就無法進行

不過可以透過簡單的配置就可以實現附帶 cookie

// xhr
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

// fetch api
fetch(url, {
  credentials: 'include',
});

這樣一來，該跨域的 ajax 請求就是一個附帶身份憑證的請求

當一個請求需要附帶 cookie 時，無論它是簡單請求，還是預檢請求，都會在請求頭中新增cookie欄位

而伺服器響應時，需要明確告知客戶端：伺服器允許這樣的憑據

告知的方式也非常的簡單，只需要在響應頭中新增：Access-Control-Allow-Credentials: true即可

對於一個附帶身份憑證的請求，若伺服器沒有明確告知，瀏覽器仍然視為跨域被拒絕。

另外要特別注意的是：對於附帶身份憑證的請求，伺服器不得設定 Access-Control-Allow-Origin 的值為*。這就是為什麼不推薦使用*的原因

一個額外的補充

在跨域訪問時，JS 只能拿到一些最基本的響應頭，如：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要訪問其他頭，則需要伺服器設定本響應頭。

Access-Control-Expose-Headers頭讓伺服器把允許瀏覽器訪問的頭放入白名單，例如：

Access-Control-Expose-Headers: authorization, a, b

這樣 JS 就能夠訪問指定的響應頭了。

相關文章