Static Site Hosting 服務需求

前陣子研究了一下用 GCP 來放靜態網站,那時候有整理了一下需求,這篇文章把需求的緣由也整理出來,先說在前面,這些需求並不是要求單一家服務就可以達成所有目標,內文也盡量不提到特定服務,所以不同服務要怎樣達到這些需求就有賴各位自行研究了。

支援 CDN

這個需求沒什麼好說了吧。

支援 HTTP/2

主要的服務應該都支援了,不過還是列一下。

支援加上 Security Headers

現在大家對於安全性的要求很高,所以可以加上 security headers 對我來說已經是一個必備的功能了,像是 CSP、HSTS 等,這項需求看廣一點,其實就是要自定義回傳 header 的功能,如果可以根據路徑調整就更好了,基本上應該只有 HTML 文件本身需要這些 header。

支援 HTTP 轉成 HTTPS

在各家瀏覽器的推波助瀾之下,不支援 HTTPS 的網站感覺就是次一等了,所以把 HTTP protocol 的 traffic 全部轉到 HTTPS 這件事情我也列為必備,有兩種支援的方式,一種是服務內建支援 protocol 轉址,這種最好,因為它會保留請求的路徑(path),而不是把訪客導到首頁,另外一種就是用下面要提到的全站轉址的方式來達成。

雖然我自己是都會把 HTTP 轉到 HTTPS,不過看網站目標,也還是有可能需要繼續支援 HTTP 的。

支援全站轉址

主要的需求是把www.example.com轉址到example.com,或是反過來,像www.apple.com那樣,當然最好還能保留請求的路徑,這個看似很基本的設定,其實現在還蠻常會發現有網站沒做到這件事,尤其是台灣的,我真的是黑人問號?_?

除了 host name 的轉換之外,還有一種情形是需要把整個網站的 request 都轉到某個 URL,例如docs.example.com要關站,然後要把流量都轉到https://example.com/docs

以下算是非必備的需求

支援把 404 改寫成 200

非 SSR 的 SPA 然後配上 route 的話,會有個問題就是除了首頁的 route 都會 404,雖然一般可以用 error_document/not_found_page 之類的設定來讓內容可以正確呈現,但是 404 的 status code 還是會有不少問題,一來是影響搜尋引擎的結果,二來是不知道是不是所有瀏覽器都還會正確的處理 404 時的網頁內容,所以最好還是能回正確的 status code,可以辦到這件事的方法就我所知道的也是有兩種,一種是 rewrite 機制,另外一種就是可以寫程式處理 request/respone 的,像是 Lambda@Edge 那樣。不過在處理這個功能時要是直接全部的路徑回應都變 200 其實也不太好,要完美有點麻煩啊。

支援 CORS

如果會有需要靜態的 JSON 檔案,然後跨網域直接抓下來當資料使用,那就會需要支援 CORS header,和上面自定義回傳 header 那一項不太一樣的是,CORS header 其實是有互動而不是寫死的,應該是要根據 request 的 header 內容來改變回傳的 CORS header,如果需要 preflight request 那還要支援 OPTIONS method 和相對應的回應,不過如果單純只是靜態 JSON 檔案,靠自訂回傳 header 的功能直接寫死應該也是夠用了。

支援 Basic Auth

如果有尚未公開的網站,還是希望至少有個基本的保護,Basic Auth 只是其中一種方法。

支援根據 Header 切換 origin

這個需求的來源就是用手機的訪客可以看到手機版網頁,用桌上型電腦的訪客看到桌面版網頁,然後網址想要維持一致而且兩種版本的網站想要分開開發,不一定會有這個需求。然後不得不說,AWS 的CloudFront-Is-*-Viewerheader真是蠻方便的,不過他們沒洩漏過判斷方式,Cloudflare 則是只有企業方案有支援,但是有提供他們如何判斷 device type。

支援根據路徑切換 origin

如果有特定路徑下的網頁是另外開發的,有支援這個功能的話就會比較好處理,一個比較常見的情境是開發文件的 API spec 是用其他工具或服務產生的,例如用 OpenAPI 文件產生的那種就很常見,或是有些語言也都有常用的文件產生工具,例如 Python 的 Sphinx。

支援 brotli

Google 開發的壓縮格式,對文字資料的壓縮表現比以前主流的 gzip 還好,主要的服務應該都支援了,不過還是列一下。

comments powered by Disqus