軟體主廚的程式料理廚房

以前聽過有個笑話是這樣說的：

某A：聽說 iOS 在瀏覽網頁的時候很省電
某B：對，因為它什麼事都沒做。

原來這件事是真的，根據 RFC 7234 5.2.1.4 的定義，如果我們在發送 Request 的時候，加上 cache-control: no-cache，在沒有從伺服器成功取得內容之前，不得使用已儲存的快取來滿足目前的 Request，但是 iOS 它連 Request 都沒送，自然就不需要理會這個定義。

當我們建立一個 ASP.NET Core Web 應用程式專案的時候，預設在 Startup.cs 中就會呼叫 UseStaticFiles() 使用 StaticFileMiddleware，讓專案中的靜態檔案可以透過 HTTP 被存取到，現在我想要將這些靜態檔案 Cache 在 CDN 上，我需要在 Response Headers 裡面加上 Cache-Control: public, max-age=n，我們來看要怎麼做？

這件事情是這樣的，在 ASP.NET MVC 有一個 Display Mode 功能，我們公司把它應用在 AWD（Adaptive Web Design） 機制上，雖然在 ASP.NET Core 被拿掉了，但是我們可以實作 IViewLocationExpander 把它給弄回來，某天發現某個 Mobile 網頁的內容套到了 Desktop 版的 Layout，百思不得其解，最後爬了 ASP.NET Core 的原始碼才知道怎麼回事。

Cache 是在 Web 應用程式開發領域，無論前端或後端都需要深入了解的一件事情，良好的 Cache 機制是可以降低網頁的回應時間，以及同時節省後端伺服器的運算資源，其中關乎到 Cache 品質的兩項因素是：新鮮度、命中率，而影響到這兩項因素的關鍵就在於我們的更新策略。

ASP.NET Core 的 ResponseCache 觸發伺服器端快取的條件尤為嚴格，限制很多，這也是它跟過去我們所熟悉的 OutputCache 特別不一樣的地方，所以 ResponseCache 我們也沒辦法就這樣直接當做 OutputCache 來使用，缺的部分我們只好自己來補足。

這天在追查為何 A 客戶的訂單會出貨到 B 客戶哪裡去？　於是我看到了下面這段程式碼：

在 Login 的 Action 上面被加了 OutputCacheAttribute，Duration 屬性被設成 3，其中還用到了 VaryByParam 屬性，我猜寫這段 Code 的工程師應該是想要為每個登入的帳號做 OutputCache，這樣設定沒有問題，問題出在 HTTP Request 的發送內容。

有一些網頁的內容是有時效性的，甚至有一些操作是不可逆的，但是瀏覽器的歷程記錄（History）卻會逆轉這些特性，在使用者按下「上一頁」的那一刻，不該出現的卻出現了、不該消失的卻消失了，怎麼會這樣？

這是個對 IIS 的誤會，這個跟各個瀏覽器如何處理 Cache-Control 有關，IIS 在靜態檔案上預設沒有回應 Cache-Control 這個標頭，我比較了三款瀏覽器 Chrome（70.0.3538.77）、Firefox（63.0）、Edge（44.17763.1.0）來看看它們各自如何處理這種情況？以及 IIS 該如何來調整？

長期在 ASP.NET 打滾，講到 Cache 第一時間就會想到 Redis、Memcached、... 這種伺服器端的 Cache 服務，但是在 Web 技術領域內還有瀏覽器端的 Cache，如果沒有特別指定，檯面上這些主流的瀏覽器都會把 Web 伺服器回應的內容存起來，我們應該要好好地利用它們來降低伺服器跟網路的壓力。