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 供作調整；等吧…