ajax 請求 的一些殘念

2022-02-06 19:17:47 字數 2939 閱讀 5642

本文是篇真正的隨筆 是我在寫乙份前端優化ppt時  想到哪寫到哪 產生的乙份  羅里吧嗦的 東東...有點懶的整理 ...所以就發布到這個旮旯吧.

ajax 優化 

一 . 給被請求資源設定有效的長遠的 expires 的同時設定乙個相對短 且合理的 max-age值

比如  對某一檔案  伺服器的響應頭 中應該包含

expires:tue, 01 jun 2030 15:43:46 gmt

cache-control:max-age=60

以及last modified頭或 etag頭 的其中乙個.

對於ie瀏覽器來說頭兩項 缺一不可 的原因在於

假如 對於某檔案 即沒有 expires 又沒有 max-age的話 那麼 快取檔案就無 過期時間…一旦某快取檔案無過期時間 而 我們又去使用 xhr 物件對伺服器請求 該檔案. 則會導致 ie直接使用本地快取檔案給我們 而不會發起乙個http 連線請求給伺服器.

我們需要給動態檔案使用獨立的etag演算法或lastmodified 演算法 以便確定內容的及時更新 .原因在於ie瀏覽器 對於動態檔案 如 aspx php等 一樣會固執的快取他們 並在 xhr物件請求時 不發起http請求 此處應根據不同情況差異  選擇性 確保ie 快取檔案的expires 時間 和max-age或乾脆禁止 ie快取檔案. 

永遠不要期待ie像firefox chrome safari 等瀏覽器那樣 對於aspx php等動態檔案型別. 在預設http頭中沒有expires 和max-age 以及last modified 或etag時.自作主張的快取檔案並在xhr請求時不發起http請求.

補充:對於動態檔案 如aspx  iis預設不會傳送 last modified 或etag頭 即 iis認為 對於動態檔案 應該總是輸出新的內容給客戶端. 所以 客戶端對於 動態檔案 也總是不會有 if modified since 和if none match頭  這就導致 瀏覽器 的xhr物件 對動態檔案做請求 不可能出現304狀態碼 也就是說 一旦發起http請求 並成功返回資料那麼只有 200 的可能 這很合理 但是ie的問題在於如上面所說 於其他瀏覽器的區別之處就 在於  預設 無epxires的情況下的處理差別. 好在 設定 expires和 max-age 可以完善的解決這些問題 而不會產生瀏覽器差異. 

只使用expires而不使用max-age 雖然沒問題 但是 這裡需要乙個預期 即 我們首先要 預期 客戶端 與伺服器端 時間相差不是很離譜 但因為這個是無法保證的 所以 我們需要 用max-age來保證過期時間的準確性.

但如果只有max-age ie瀏覽器 的xhr 物件發起的請求 仍然會有bug  他會導致 瀏覽器 直接放棄 本地cache而每次都發起請求 到伺服器 .這顯然也不是我們想要的結果

所以同時 設定max-age和 expires 可以確保ie及 其他瀏覽器 都遵守以下原則

1在快取檔案過期之前的xhr請求 直接去 本地快取讀 而不發起http連線請求

2一旦快取檔案過期 才會發起請求 如果伺服器響應頭中 有last modified 或 etag頭 則 請求同時會帶有 對應的 if-modified-since頭或 if-none-match 頭  以便讓伺服器判斷 是否需要返回新的 檔案內容 或者 只返回 304 頭 通知瀏覽器 本地快取可以信任 它於伺服器上的 檔案相同.

二 對於不期待先後順序的xhr請求 應放棄所謂xhr 資源管理.

即 通過一系列瀏覽器探測 以及http協議版本的 預期 以及當前 資源載入 所占用http連線數 等等狀況 最終控制 例項化出的xhr物件個數 以及他們的用途…

這種行為看起來 可以避免 同時宣告過多的xhr物件 而又不滿足對應連線數 使可能過多的 xhr物件在瀏覽器佇列中 空耗這 記憶體.

但恰恰相反 我們應在每次需要xhr時 立刻建立乙個 並使其傳送 需要的 請求 即可  我們要做的 只是在 success **函式處 即刻銷毀xhr即可

這樣做才可以 100% 有把握的 保證xhr的最大併發數而不需要我們自己去 分析 判斷 猜測.

令乙個需要注意的問題是 關於 主動給xhr 新增http請求頭內容

我的建議是 

新增 accept 頭 比如 */*   因為一旦不設定此頭  則個個瀏覽器的預設 accept頭 都不一樣 比如firefox 就可能是乙個很長的頭 浪費頻寬 . 所以同意使用 accept 並制定為我們需要的型別 可以減少http請求中的資料量.

乙個有趣的問題 在於 如果 我們沒有主動向xhr新增乙個 if-modified-since 頭的話則無論伺服器返回碼 是不是304   xhr.status 都將是200  除非 我們明確的新增了乙個包含if-modified-since的請求頭  這時xhr.status== 200 才是可信任的否則 . 一旦 是從快取中讀取的 內容  則狀態總是200 而不是我們期望的 304 . 手動新增 if-modified-since 頭 為乙個 過早或過晚的日期(相對該檔案在伺服器上的 last modified 日期) 都將導致 伺服器端校驗快取檔案可靠性失效.從而伺服器端 總是傳送乙個 200 狀態碼 並將最新檔案資料異同 傳送過來. 所以人為新增 if-modified-since頭 需要謹慎 且保證其正確性. 如果我們並不需要確定 到底是從快取讀出資料還是 伺服器端傳送的資料 則 不建議人為新增 if-modified-since頭.

另外 xhr請求時 永遠不要嘗試 人工傳送 乙個 if-none-match 頭 給伺服器 我們一般將會得到乙個 400狀態碼即 bad request 即使 我們的內容是乙個看起來 合法的 有效的etag值. 

對於ajax跨域請求的一些相關知識

響應頭部access control allow origin 第二個頭部貌似不重要,主要是如果是ajax請求就要設定接收的頭部 route rule index upload index index upload index header access control allow origin h...

http的一些請求

get 和 post get 從指定的資源請求資料。get 請求可被快取 get 請求保留在瀏覽器歷史記錄中 get 請求可被收藏為書籤 get 請求不應在處理敏感資料時使用 get 請求有長度限制 get 請求只應當用於取回資料 post 向指定的資源提交要被處理的資料 post 請求不會被快取 ...

我的一些AJAX感想

1 ajax應用的基本流程 1 建立xmlhttprequest物件 2 從web表單中獲取需要的資料 3 設定連線的url 4 建立到伺服器的連線 5 設定伺服器在完成執行後的 函式 6 傳送請求 如上面的過程我們可以看到ajax的核心在於那個xmlhttprequest物件。基本上的流程都與這個...