前端(vue)入門到精通課程:進入學(xué)習(xí)
閱讀本文,你將:
-
學(xué)會幾個超級超級實用的 響應(yīng)頭,解決你工作中遇到的問題。
-
不僅解決問題,還能讓你在 和后端、運維撕逼時 占據(jù)上風。
學(xué)習(xí) 響應(yīng)頭 很重要嗎?
真的很重要。
不信你看看下面的場景,眼熟不?
一、預(yù)覽、下載 讓人操碎了心?
1.1 場景
我不止一次聽到同事、群友們討論這個問題:
“后端提供了一個
txt
(或者url
,可以當我用a
標簽打開時,卻變成了預(yù)覽……怎么辦?救?。?!”
此時,就會有人上去推薦 FileSaver.js
或者 “手寫讀流另存為”。
然后還有人附和…
我:???
這是需要寫代碼才能解決的問題嗎?
如果你有了解過 Content-Disposition
這個 Response Header
,那你一定知道,只需要響應(yīng)頭上增加一行,問題就能迎刃而解。
1.2 介紹
Content-Disposition
:這個響應(yīng)頭可以決定內(nèi)容是 預(yù)覽 還是 下載。
它支持三種格式的值:
-
Content-Disposition: inline
此時,消息體會以頁面的一部分或者整個頁面的形式展示。(預(yù)覽) -
Content-Disposition: attachment
消息體應(yīng)該被下載,默認文件名和url
格式有關(guān)。 -
Content-Disposition: attachment; filename="filename.jpg"
消息體應(yīng)該被下載,默認文件名可指定。
注:如果需要預(yù)覽,需要配合適當?shù)?
Content-Type
食用;
1.3 示例
為此,我特意寫了一個 express
小示例。
大抵是在 express
應(yīng)用下寫了三個路由,如下:
const user = { name: "摸魚的春哥", blogUrl: "https://juejin.cn/user/1714893870865303" } const contentDispositionInline = async (req, res, next) => { res.setHeader('Content-Disposition', 'inline') res.send(user) } const contentDispositionFilename = async (req, res, next) => { res.setHeader('Content-Disposition', 'attachment; filename="chunge.json"') res.send(user) } const contentDispositionNoFilename = async (req, res, next) => { res.setHeader('Content-Disposition', 'attachment') res.send(user) }
然后我分別訪問三個路由,效果差異:
二、項目升級了,需要客戶 清空緩存 ?
2.1 場景
實施:“客戶反饋Bug
還是沒修復(fù)?!?br />你:“哥,真修復(fù)了,要不你讓客戶清一下緩存?”
實施:“???客戶說他不會清……”
……
永遠不要期望你的客戶會進行 “那些研發(fā)才懂” 的操作。也不要把你的問題,歸因到 瀏覽器緩存 上。
瀏覽器緩存 是被發(fā)明出來優(yōu)化用戶體驗的,并不是被發(fā)明出來阻礙用戶的。
因此,理解如何使用 Cache-Control
這個響應(yīng)頭,是前端的必知技能。
2.2 介紹
Cache-Control
:用來指定緩存機制。
緩存,作為前端八股文必考知識,相信大家已經(jīng)耳熟能詳。 常見的 Cache-Control
屬性如下:
Response Header屬性 | 值 | 含義 |
---|---|---|
cache-control | no-store | 不緩存,這個會讓客戶端、服務(wù)器都不緩存,也就沒有所謂的強緩存、協(xié)商緩存了。 |
cache-control | public | 表明響應(yīng)可以被任何對象(包括:發(fā)送請求的客戶端,代理服務(wù)器,等等)緩存,即使是通常不可緩存的內(nèi)容。(例如:1.該響應(yīng)沒有max-age指令或Expires消息頭;2. 該響應(yīng)對應(yīng)的請求方法是 POST 。) |
cache-control | private | 表明響應(yīng)只能被單個用戶緩存,不能作為共享緩存(即代理服務(wù)器不能緩存它)。私有緩存可以緩存響應(yīng)內(nèi)容,比如:對應(yīng)用戶的本地瀏覽器。 |
cache-control | max-age=<1000> | 設(shè)置緩存存儲的最大周期,超過這個時間緩存被認為過期(單位秒)。與Expires相反,時間是相對于請求的時間。 |
- 不緩存
不緩存是最容易理解,每一次請求都會從服務(wù)端重新獲取,不進行任何緩存。
此策略只需要賦予Cache-Control: no-store
響應(yīng)頭即可。 - 強緩存
有些資源文件,幾乎不會發(fā)生變化(比如已經(jīng)hash化命名的文件
),則可以直接從本地緩存獲取,這就是所謂的 強緩存 ;
通過cache-control: public/private
或者cache-control: max-age=<1000>
都可以指定機制為強緩存。 - 協(xié)商緩存
這是一種更為復(fù)雜緩存機制,無法再通過響應(yīng)頭 簡單粗暴地 指定實現(xiàn),而是需要前后端協(xié)作配合。
簡單來說,每次請求資源前前端會寫代前一次的響應(yīng)hash
,問詢服務(wù)端 資源是否發(fā)生過變化,從而達到準確緩存的效果。
本文不贅述,如果有興趣,可以參考此文:juejin.cn/post/703078…
2.3 實際生產(chǎn)如何運用?
- 凡是名稱帶有
hash
值的資源,一律可以強緩存。
(畢竟內(nèi)容一旦有變化,名稱的hash
也跟著變了) - 凡是通過
cdn
引入的第三方庫,均建議攜帶版本信息,這樣也可以強緩存。
(比如/xx/xx/jquery.min.js
切換為jquery@3.6.0/dist/jquery.min.js
) - 凡是
html
、ico
這類命名固定的文件,建議一律 不緩存 或者 協(xié)商緩存。
三、我的 Cookie
不可能這么可愛!
3.1 場景
"春哥春哥,為啥我登錄成功了,請求還是
401
?"
"春哥春哥,為啥我存進
cookie
的值取不到?"
"春哥春哥,這破
cookie
是不是壞了,瀏覽器里看明明有值,為啥我訪問不了?"
我:“兄弟,你有了解過一個叫 set-cookie
的響應(yīng)頭嗎?”
是它!是它!就是它!關(guān)于 cookie
的各種異常,全靠它!
3.2 介紹
Cookie
曾經(jīng)是 Web
開發(fā)無法繞開的一道門檻,而現(xiàn)在它的存在感越來越弱,但海量的存量項目并不會因為技術(shù)的趨勢而消失,它們依然很有價值,依然需要維護。
而 set-cookie
響應(yīng)頭正是 Cookie
體系中最為核心的 第一主角。
Set-Cookie
: 是一個響應(yīng)頭,服務(wù)端賦值,讓瀏覽器端產(chǎn)生 Cookie
,并限定 Cookie
的各種特性。
這些特性就包括:
- 過期時限;
Expires=<date>
- 存活周期;
Max-Age=<number>
在 cookie 失效之前需要經(jīng)過的秒數(shù)。0
或-1
直接失效;此屬性的優(yōu)先級高于Expires
。 - 域名;
Domain=<domain-value>
指定cookie
只能在什么域下生成;(允許通配,這個屬性主要出于安全性) - 路徑;
Path=<path-value>
比Domain
更為細致的控制策略,甚至指定了xx
路徑下才能發(fā)送Cookie
。 - 只在
Https
產(chǎn)生;Secure
如果set-cookie
頭中有Secure
屬性,那么瀏覽器只會在Https
環(huán)境產(chǎn)生和發(fā)送Cookie
。 - 禁用
js
操作API
;HttpOnly
如果set-cookie
頭中有HttpOnly
屬性,那么Cookie
屬性的生成、讀寫、發(fā)送就只能由瀏覽器通過 "響應(yīng)頭" 控制了,不在允許前端通過js
操作Cookie
。 - 是否允許跨域攜帶;
SameSite=<samesite-value>
支持屬性包括Strict
、Lax
、None
,分別表示:Strict
: 完全不能跨域攜帶;Lax
: 只允許從外站導(dǎo)航到源站時攜帶Cookie
None
:跨域也行,不限制。
3.3 開發(fā)常見問題分析
-
為啥你登錄成功了,請求還是
401
?早期非常多的項目,使用
Cookie
作為用戶身份識別的手段,比如Spring MVC
項目就是通過給Cookie
一個JSeesionId
的值作為識別,判斷你是否出于當前會話。而 "登錄了,卻還
401
" 這個現(xiàn)象,如果服務(wù)端沒有問題的話,多半是 瀏覽器其實并未存儲Cookie。換個說法,你每次發(fā)起請求,服務(wù)端都認為你是一次 新的會話,和上一次 登錄的你 并非同一人。
如果你正處于
http
環(huán)境,那你可能需要暫時移除Secure
屬性。 -
存不進、取不出?
先確認 是否有域的限制、是否有路徑的限制、是否有HttpOnly
?
逐一排查下來,問題不難解決。
(學(xué)習(xí)視頻分享:web前端)