HTTP 壓縮的 workaround : ProgressEvent & Cache-Control

這幾個月前後經手處理兩個 HTTP 壓縮相關的問題,寫個紀錄…

第一個問題跟 ProgressEvent 有關。
敝單位有個 PWA ( Progressive Web Application ),幾個月前釋出一個新模組,讓 user 可獲取公司內部發佈的公告訊息。考量到訊息內容長度與行動裝置所在網路環境,我們便試著在訊息載入時加上進度條 (Progress Bar)。
實作期間,我們發現只能取得 ProgressEvent.loaded,抓不出 ProgressEvent.total,而且這個現象僅發生在 server response,瀏覽器發出請求/上傳檔案無此狀況。
確認這現象跟 HTTP 壓縮有關後,我們也發現 ProgressEvent.loaded 的值是未壓縮前的大小。
目前我們採用的解法是在讀取內容前先發個 HTTP request 取得內容長度,用該值取代 ProgressEvent.total

第二個問題被發現時,我們正在調整 Cache-Control 設定;而且這問題只跟 Apache HTTPD 有關。
我們讓 HTTP server 壓縮 .js , .css , .htm 這類固定文字檔,也加上這串 HTTP header :

Cache-Control: public, max-age=86400, no-cache

但我們發現瀏覽器在 nginx 可正確獲得 304 Not Modified,但遇上 Apache HTTPD 永遠都是 200 OK
花一堆時間測試/追蹤後發現兇手是 mod_deflate;原因是檔案被壓縮處理後,傳給瀏覽器的 HTTP ETag 後面被加上 “-gzip” 這串後綴。
目前的解法是參考這篇,用下面這段設定處理 .js , .css , .htm 這類固定文字檔的 Cache-Control

RequestHeader edit "If-None-Match" "^\"(.*)-gzip\"$" "\"$1\""
Header edit "ETag" "^\"(.*[^g][^z][^i][^p])\"$" "\"$1-gzip\""

Apache HTTPD 2.5 版的 mod_deflate 應該會多個 DeflateAlterETag 供作調整;等吧… XD

Tweet 20
fb-share-icon20