溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

web前端實用的響應(yīng)頭是什么

發(fā)布時間:2022-09-14 11:34:17 來源:億速云 閱讀:141 作者:iii 欄目:web開發(fā)

這篇文章主要介紹了web前端實用的響應(yīng)頭是什么的相關(guān)知識,內(nèi)容詳細(xì)易懂,操作簡單快捷,具有一定借鑒價值,相信大家閱讀完這篇web前端實用的響應(yīng)頭是什么文章都會有所收獲,下面我們一起來看看吧。

一、預(yù)覽、下載 讓人操碎了心?

1.1 場景

我不止一次聽到同事、群友們討論這個問題:

“后端提供了一個 txt(或者 pdf/'json' 等)文件的下載 url,可以當(dāng)我用 a 標(biāo)簽打開時,卻變成了預(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)該被下載,默認(rèn)文件名和 url 格式有關(guān)。

  • Content-Disposition: attachment; filename="filename.jpg"
    消息體應(yīng)該被下載,默認(rèn)文件名可指定。

注:如果需要預(yù)覽,需要配合適當(dāng)?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)
}

然后我分別訪問三個路由,效果差異:

web前端實用的響應(yīng)頭是什么

二、項目升級了,需要客戶 清空緩存 ?

2.1 場景

實施:“客戶反饋Bug 還是沒修復(fù)?!?br/>你:“哥,真修復(fù)了,要不你讓客戶清一下緩存?”
實施:“???客戶說他不會清……”
……web前端實用的響應(yīng)頭是什么

永遠(yuǎn)不要期望你的客戶會進(jìn)行 “那些研發(fā)才懂” 的操作。也不要把你的問題,歸因到 瀏覽器緩存 上。

瀏覽器緩存 是被發(fā)明出來優(yōu)化用戶體驗的,并不是被發(fā)明出來阻礙用戶的。

因此,理解如何使用 Cache-Control 這個響應(yīng)頭,是前端的必知技能。

2.2 介紹

Cache-Control:用來指定緩存機(jī)制。

緩存,作為前端八股文必考知識,相信大家已經(jīng)耳熟能詳。 常見的 Cache-Control 屬性如下:

Response Header屬性含義
cache-controlno-store不緩存,這個會讓客戶端、服務(wù)器都不緩存,也就沒有所謂的強(qiáng)緩存、協(xié)商緩存了。
cache-controlpublic表明響應(yīng)可以被任何對象(包括:發(fā)送請求的客戶端,代理服務(wù)器,等等)緩存,即使是通常不可緩存的內(nèi)容。(例如:1.該響應(yīng)沒有max-age指令或Expires消息頭;2. 該響應(yīng)對應(yīng)的請求方法是 POST 。)
cache-controlprivate表明響應(yīng)只能被單個用戶緩存,不能作為共享緩存(即代理服務(wù)器不能緩存它)。私有緩存可以緩存響應(yīng)內(nèi)容,比如:對應(yīng)用戶的本地瀏覽器。
cache-controlmax-age=<1000>設(shè)置緩存存儲的最大周期,超過這個時間緩存被認(rèn)為過期(單位秒)。與Expires相反,時間是相對于請求的時間。
  • 不緩存
    不緩存是最容易理解,每一次請求都會從服務(wù)端重新獲取,不進(jìn)行任何緩存。
    此策略只需要賦予 Cache-Control: no-store 響應(yīng)頭即可。

  • 強(qiáng)緩存
    有些資源文件,幾乎不會發(fā)生變化(比如已經(jīng) hash化命名的文件),則可以直接從本地緩存獲取,這就是所謂的 強(qiáng)緩存 ;
    通過 cache-control: public/private 或者 cache-control: max-age=<1000> 都可以指定機(jī)制為強(qiáng)緩存。

  • 協(xié)商緩存
    這是一種更為復(fù)雜緩存機(jī)制,無法再通過響應(yīng)頭 簡單粗暴地 指定實現(xiàn),而是需要前后端協(xié)作配合。
    簡單來說,每次請求資源前前端會寫代前一次的響應(yīng) hash,問詢服務(wù)端 資源是否發(fā)生過變化,從而達(dá)到準(zhǔn)確緩存的效果。
    本文不贅述,如果有興趣,可以參考此文:juejin.cn/post/703078…

2.3 實際生產(chǎn)如何運用?

  • 凡是名稱帶有 hash 值的資源,一律可以強(qiáng)緩存。
    (畢竟內(nèi)容一旦有變化,名稱的hash 也跟著變了)

  • 凡是通過 cdn 引入的第三方庫,均建議攜帶版本信息,這樣也可以強(qiáng)緩存。
    (比如 /xx/xx/jquery.min.js 切換為 jquery@3.6.0/dist/jquery.min.js

  • 凡是 html、ico 這類命名固定的文件,建議一律 不緩存 或者 協(xié)商緩存。

三、我的 Cookie 不可能這么可愛!

3.1 場景

"春哥春哥,為啥我登錄成功了,請求還是 401 ?"

"春哥春哥,為啥我存進(jìn) cookie 的值取不到?"

"春哥春哥,這破 cookie 是不是壞了,瀏覽器里看明明有值,為啥我訪問不了?"

我:“兄弟,你有了解過一個叫 set-cookie 的響應(yīng)頭嗎?”

是它!是它!就是它!關(guān)于 cookie 的各種異常,全靠它!

3.2 介紹

Cookie 曾經(jīng)是 Web 開發(fā)無法繞開的一道門檻,而現(xiàn)在它的存在感越來越弱,但海量的存量項目并不會因為技術(shù)的趨勢而消失,它們依然很有價值,依然需要維護(hù)。

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 更為細(xì)致的控制策略,甚至指定了 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 的值作為識別,判斷你是否出于當(dāng)前會話。

    而 "登錄了,卻還 401" 這個現(xiàn)象,如果服務(wù)端沒有問題的話,多半是 瀏覽器其實并未存儲Cookie

    換個說法,你每次發(fā)起請求,服務(wù)端都認(rèn)為你是一次 新的會話,和上一次 登錄的你 并非同一人。

    如果你正處于 http 環(huán)境,那你可能需要暫時移除 Secure 屬性。

  • 存不進(jìn)、取不出?
    先確認(rèn) 是否有域的限制是否有路徑的限制、是否有 HttpOnly?
    逐一排查下來,問題不難解決。

關(guān)于“web前端實用的響應(yīng)頭是什么”這篇文章的內(nèi)容就介紹到這里,感謝各位的閱讀!相信大家對“web前端實用的響應(yīng)頭是什么”知識都有一定的了解,大家如果還想學(xué)習(xí)更多知識,歡迎關(guān)注億速云行業(yè)資訊頻道。

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI