首頁 > web前端 > js教程 > 【整理總結】前端必知必會的幾個實用響應頭

【整理總結】前端必知必會的幾個實用響應頭

青灯夜游
發布: 2022-09-14 19:43:07
轉載
2878 人瀏覽過

【整理總結】前端必知必會的幾個實用響應頭

閱讀本文,你將:

  • #學會幾個超級超級實用的回應頭,解決你工作上遇到的問題。

  • 不僅解決問題,還能讓你在 和後端、維運撕逼時 佔上風。

學習 回應頭 很重要嗎?

真的很重要。

不信你看看下面的場景,眼熟不?

一、預覽、下載讓人操碎了心?

#1.1 場景

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

「後端提供了一個

txt#(或pdf/'json' 等)檔案的下載url,可以當我用a 標籤打開時,卻變成了預覽…怎麼辦?救!!!」

此時,就會有人上去推薦

FileSaver.js 或「手寫讀流另存為」。

然後還有人附和...

我:? ? ?

【整理總結】前端必知必會的幾個實用響應頭

這是需要寫程式碼才能解決的問題嗎?

如果你有了解過

Content-Disposition 這個 Response Header,那你一定知道,只需要回應頭上增加一行,問題就能迎刃而解。

1.2 介紹

Content-Disposition:這個回應頭可以決定內容是預覽#還是下載

它支援三種格式的值:

  • Content-Disposition: inline此時,訊息體會以頁面的一部分或者整個頁面的形式展示。 (預覽)

  • Content-Disposition: attachment訊息體應該被下載,預設檔名和
    url 格式有關。

  • Content-Disposition: attachment; filename="filename.jpg"訊息體應該下載,預設檔名可指定。

註:如果需要預覽,需要配合適當的

Content-Type 食用;

##1.3 範例

為此,我特意寫了一個

express

小範例。 大抵是在

express

應用程式下寫了三個路由,如下:<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">const user = {   name: &quot;摸鱼的春哥&quot;,   blogUrl: &quot;https://juejin.cn/user/1714893870865303&quot; } const contentDispositionInline = async (req, res, next) =&gt; {   res.setHeader('Content-Disposition', 'inline')   res.send(user) } const contentDispositionFilename = async (req, res, next) =&gt; {   res.setHeader('Content-Disposition', 'attachment; filename=&quot;chunge.json&quot;')   res.send(user) } const contentDispositionNoFilename = async (req, res, next) =&gt; {   res.setHeader('Content-Disposition', 'attachment')   res.send(user) }</pre><div class="contentsignin">登入後複製</div></div>然後我分別存取三個路由,效果差異:

【整理總結】前端必知必會的幾個實用響應頭

二、專案升級了,需要客戶清空快取?

2.1 場景

實作:「客戶回饋

Bug

還是沒修復。」你:「哥,真修復了,要不要讓客戶清一下快取?」實作:「啊?客戶說他不會清除…」


永遠不要期望你的客戶會進行

「那些研發才懂」

的操作。也不要把你的問題,歸因到 瀏覽器快取 上。

瀏覽器快取

是被發明出來優化使用者體驗的,並不是發明出來阻礙使用者的。 因此,理解如何使用

Cache-Control

這個回應頭,是前端的必知技能。

2.2 介紹

Cache-Control:用來指定快取機制。 緩存,作為前端八股文必考知識,相信大家已經耳熟能詳。 常見的

Cache-Control 屬性如下:

Response Header屬性 #意思
cache-control no-store 不緩存,這會讓客戶端、伺服器都不緩存,也就沒有所謂的強緩存、協商緩存了。
cache-control public 表示回應可以被任何物件(包括:發送請求的客戶端,代理伺服器,等等)緩存,即使是通常不可緩存的內容。 (例如:1.該回應沒有max-age指令或Expires訊息標頭;2. 此回應對應的請求方法是POST。)
cache-control # private 表示回應只能被單一使用者緩存,不能作為共享快取(即代理伺服器不能快取它)。私有快取可以快取回應內容,例如:對應使用者的本機瀏覽器。
cache-control max-age= 設定快取儲存的最大週期,超過這個時間快取被認為過期(單位秒)。與Expires相反,時間是相對於請求的時間。
  • 不快取
    不快取是最容易理解,每個請求都會從服務端重新獲取,不進行任何快取。
    此策略只需要賦予 Cache-Control: no-store 回應頭即可。
  • 強快取
    有些資源文件,幾乎不會改變(例如已經hash化命名的文件),則可以直接從本地快取獲取,這就是所謂的強緩存 ;
    透過cache-control: public/privatecache-control: max-age= 都可以指定機制為強緩存。
  • 協商快取
    這是一種更為複雜快取機制,無法再透過回應頭 簡單粗暴地 指定實現,而是需要前後端協作配合。
    簡單來說,每次請求資源前前端會寫代前一次的回應hash,問詢服務端資源是否發生過變化,從而達到準確快取的效果。
    本文不贅述,如果有興趣,可以參考此文:juejin.cn/post/703078…

##2.3 實際生產如何運用?

    凡是名稱帶有
  • hash 值的資源,一律可以強快取。 (畢竟內容一旦有變化,名稱的
    hash 也跟著變了)
  • 凡是透過
  • cdn 引入的第三方函式庫,均建議攜帶版本信息,這樣也可以強緩存。 (例如
    /xx/xx/jquery.min.js 切換為jquery@3.6.0/dist/jquery.min.js
  • #凡是
  • htmlico 這類命名固定的文件,建議一律不快取協商快取

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

3.1 場景

"春哥春哥,為啥我登入成功了,請求還是

401 ?"

"春哥春哥,為啥我存進

cookie 的值取不到?"

"春哥春哥,這破

cookie 是不是壞了,瀏覽器裡看明明有值,為啥我訪問不了?"

我:「兄弟,你有了解過一個叫

set-cookie 的回應頭嗎?」

【整理總結】前端必知必會的幾個實用響應頭

是它!是它!就是它!關於

cookie 的各種異常,全靠它!

3.2 介紹

Cookie 曾經是Web 開發無法繞開的一道門檻,而現在它的存在感越來越弱,但海量的存量項目並不會因為技術的趨勢而消失,它們依然很有價值,依然需要維護。

set-cookie 回應頭正是 Cookie 系統中最為核心的 第一主角

Set-Cookie: 是回應頭,服務端賦值,讓瀏覽器端產生Cookie,並且限定Cookie 的各種特性。

這些特性就包含:

  • 過期時限;Expires=<date></date>
  • 存活週期;Max-Age=<number></number>
    #在cookie 失效之前需要經過的秒數。 0-1 直接失效;此屬性的優先權高於 Expires
  • 網域;Domain=<domain-value></domain-value>
    指定cookie 只能在什麼網域下產生;(允許通配,這個屬性主要出於安全性)
  • 路徑;Path=<path-value></path-value>
    Domain 更為細緻的控制策略,甚至指定了 xx 路徑下才能傳送Cookie
  • 只在Https 產生;Secure
    如果set-cookie 頭中有Secure 屬性,那麼瀏覽器只會在Https 環境產生和發送Cookie
  • 禁用js 操作APIHttpOnly
    如果set-cookie 頭中有HttpOnly 屬性,那麼Cookie 屬性的產生、讀寫、發送就只能由瀏覽器透過"回應頭" 控制了,不在允許前端透過js 動作 Cookie
  • 是否允許跨域攜帶;SameSite=<samesite-value></samesite-value>
    支援屬性包括StrictLaxNone,分別表示:
    • Strict: 完全不能跨域攜帶;
    • Lax: 只允許從外站導航到來源站時攜帶Cookie
    • None:跨域也行,不限制。

3.3 開發常見問題分析

  • #你已經登入成功了,請求還是 401

    早期非常多的項目,使用Cookie 作為使用者身分識別的手段,例如Spring MVC 項目就是透過給Cookie 一個JSeesionId 的值作為識別,判斷你是否出於當前會話。

    而 "登入了,卻還 401" 這個現象,如果服務端沒有問題的話,多半是 瀏覽器其實並未儲存Cookie

    換個說法,你每次發起請求,服務端都認為你是一次 新的會話,和上一次 登入的你 並非同一人。

    如果你正處於 http 環境,那你可能需要暫時移除 Secure 屬性。

  • 存不進、取不出?
    先確認是否有域的限制是否有路徑的限制是否有HttpOnly?
    逐一檢查下來,問題不難解決。

(學習影片分享:web前端

以上是【整理總結】前端必知必會的幾個實用響應頭的詳細內容。更多資訊請關注PHP中文網其他相關文章!

相關標籤:
來源:juejin.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板