您好,登錄后才能下訂單哦!
今天小編給大家分享一下options預檢請求的前后端解決方法是什么的相關知識點,內容詳細,邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
這件事還要從瀏覽器說起,基本上我們的請求都是CORS跨域請求(前后端分離嘛,基本上部署位置的IP\端口\協議不可能完全相同,所以就屬于跨域了),CORS跨域請求需要瀏覽器和服務器同時支持。目前,所有瀏覽器都支持該功能,IE瀏覽器不能低于IE10。
而CORS跨域請求,又分成簡單請求simple request, 和復雜請求not-so-simple request。
復雜請求就會觸發我們的options預檢請求,這是符合以下規范的。
跨域共享標準規范要求,對那些可能對服務器數據產生副作用的 HTTP 請求方法
(特別是 GET 以外的 HTTP 請求,或者搭配某些 MIME 類型的 POST 請求),
瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求(preflight request),
從而獲知服務端是否允許該跨域請求。服務器確認允許之后,才發起實際的 HTTP 請求。
(1)請求方式為`GET、HEAD、POST`時的請求;
(2)認為設置規范集合之內的首部字段,
如`
Accept/
Accept-Language/
Content-Language/
Content-Type/
DPR/
Downlink/
Save-Data/
Viewport-Width/
Width`;
(3)Content-Type 的值僅限于下列三者之一,即`
application/x-www-form-urlencoded、
multipart/form-data、
text/plain`;
(4)請求中的任意 `XMLHttpRequestUpload`對象均沒有注冊任何事件監聽器;
(5)請求中沒有使用 `ReadableStream`對象。
除了上面的以外的請求,基本上都是復雜請求。
比如自定義的token、Authorization等請求頭字段,或者是PUT、DELETE等請求方式。
因為預檢,會額外占用服務器資源,還會延遲真正請求的發起時間,導致頁面上性能變差(這一點在使用openai的api深有體會,因為是國外服務器,加上預檢,基本上每次都要返回好久)。
解決方式可以從前端或者后端入手,選其一就可以了,除了以下方法,可能還有其他的解決方式。
// 引入 import qs from 'qs' // 然后在請求攔截器的部分 axios.interceptors.request.use((config) => { if(config.method === 'post'){ config.data = qs.stringify(config.data); } return config; },(error) =>{ return Promise.reject(error); });
如下,從json格式變成了string字符串,后端獲取后需要重新格式化一下才能用。
// qs.stringify 前 config.data = { "userId": "520b0ec3229", "startTime": "15489504", "endTime": "1559999" } // qs.stringify 后,內容變為 "userId=520b0ec3229&startTime=15489504&endTime=1559999"
服務器端設置 Access-Control-Max-Age 字段,瀏覽器會根據返回的
Access-Control-Max-Age 字段緩存該請求的 OPTIONS 預檢請求的響應結果。
設置大點就可以了
比如設置30天,那就觸發一次預檢后,后續30天內,同一請求源頭不會再次觸發預檢請求。
// 后端設置,2592000單位秒,這里是30天 response.addHeader( "Access-Control-Max-Age", "2592000" )
access-control-allow-origin: *;
這種比較危險,因為允許了所有網站都可以跨域共享資源。
可以把*改為具體的網址源,也就是白名單。
以上就是“options預檢請求的前后端解決方法是什么”這篇文章的所有內容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學習更多的知識,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。