“目前網路協定走的是 Same-origin policy，兩個網頁 scheme, hostname, port 都相同，就算 same-origin，彼此可以存取資源 (例如圖片、CSS、JS)。”

再來看 same-site。首先我們要知道，網址有一個 Top-level domain (TLD)，.com, .tw 都算 TLD，所有的 TLD 定義在 Root Zone Database。但是後來又有問題，.co.jp, .github.io 這些不算 TLD 阿，但實際網址會使用這些後綴，所以後來又出了一個 effective TLD (eTLD)。.co.jp, .github.io 這些就是屬於 eTLD。

eTLD+1 指的則是網址的 TLD，和 TLD 前的部分。例如 my-project.github.io，eTLD 是 github.io，eTLD+1 則是 my-project.github.io。

只要 eTLD+1 相同的兩個網頁就算 same-site，不用管 scheme 同不同，不用管 port 同不同，不用管 sub-domain 同不同，只要 eTLD+1 相同就算 same-site。

https://web.dev/schemeful-samesite/
後來為了更好的安全性，尤其 same-site 的判斷跟 cookie 是否能發送有關，又出了一個 schemeful same-site。其中 scheme 會納入考量，即使網址完全相同，HTTP / HTTPS 視為 cross-site。

但必須提醒讀者，schemeful same-site 還算是新東西 (目前是 2021 年 8 月)，每種瀏覽器，每個瀏覽器版本行為可能不同。但大趨勢應該是往這方向走。

上方連結有特別舉例，http://site.example, https://site.example 兩站互相站外連結。兩站本來算 same-site，SameSite=Strict cookie 可被送回。但如果用 schemeful same-site 規則，兩站算 corss-site，SameSite=Strict cookie 不會被送回。但因為是簡單站外連結，SameSite=Lax cookie 仍可以送回。

如果 http://site.example 中嵌入 https://site.example 的圖片。兩站本來算 same-site，SameSite=Strict cookie 可被送回。但如果用 schemeful same-site 規則，兩站算 corss-site，SameSite=Strict cookie 不會被送回。SameSite=Lax 嵌入資源的情況，cookie 也不會被送回。

SameSite=Strict, Lax, None;Secure 行為上的不同，請參考之前的文章 Chrome 80 開始更新 SameSite 規則，預設禁止存取第三方 cookie

要知道一個 request 到底屬於哪一種，檢查它的 HTTP header Sec-Fetch-Site。它有四種值：1) cross-site, 2) same-site, 3) same-origin, 4) none

文件有說 Sec-Fetch-Site 不包含 schemeful same-site，所以 Sec-Fetch-Site 的 same-site 應該是不看 scheme 的。再來，因為 same-origin 的條件是 scheme, hostname, port 都要相同，比 same-site 還嚴謹，所以如果是 same-origin 的話資源、cookie 傳輸都沒問題。

結論

現代網站一定要使用 HTTPS，不使用的話從安全性到 SEO，各個角度來講都不行。如果使用 HTTPS 是前提的話，倒是不用糾結 schemeful same-site。

至於 cookie 的傳輸，Google 已宣布長期的方向是完全不支援第三方 cookie，SameSite=None;Secure 只是一個暫時的解法。

本篇走了一遍 same-site 的來龍去脈，因為 same-site 的定義以及 cookie 傳輸的協定，將來還會再改。我們要知道的是脈絡，而不是死背現在的規格。

上面是一篇很好關於跨源資源共享 Cross-Origin Resource Sharing (以下簡稱 CORS) 的文章，我喜歡它把 request/response http header 完整列出來的部分。

https://developer.mozilla.org/zh-TW/docs/Web/Security/Same-origin_policy
目前網路協定走的是 Same-origin policy，兩個網頁 scheme, hostname, port 都相同，就算 same-origin，彼此可以存取資源 (例如圖片、CSS、JS)。scheme, hostname, port 只要有一不同，sub-domain 不同，就算 cross-origin，如需存取資源，要特別處理。

這個連結有 App Engine 如何將 Access-Control-Allow-Origin 加入 config file：
https://cloud.google.com/appengine/docs/python/config/appconfig

Google Cloud Storage 的 CORS 文件：
https://cloud.google.com/storage/docs/cross-origin

“The client (e.g., browser) checks this response header to verify that the domain in the response matches the domain specified in original request, and if these match, the request proceeds.”

所以對照 Origin 的工作是在 browser 在接到 response header 後發生，而不是在 server 端判斷。跨源資源共享 (CORS) 時，可以在 server handler 裡用程式碼判斷，將允許的 Origin 加上 Access-Control-Allow-Origin，甚至每個 sub url 可以加上不同的 access control。以 webapp2 框架來說，語法為：

self.response.headers.add('Access-Control-Allow-Origin', your_url)

跨源存取資源分兩種，上方是 簡單請求 (simple requests)。

如果 HTTP method 不是 GET, POST, HEAD，或是非一般簡單 Content-Type。例如 HTTP method 是 PUT, DELETE，Content-Type 是 application/xml，則需要用 預檢請求 (preflighted requests)。

預檢請求會先以 HTTP OPTIONS method 詢問 server，哪些 method 允許，哪些標頭允許。收到允許後，再實際去存取資源，所以是兩段式的流程。

下面例子是一個自定義標頭 (X-PINGOTHER)，和一個非簡單 Content-Type 的跨源請求，server 端的處理方式，以 webapp2 框架來說：

def options(self):
    self.response.headers.add('Access-Control-Allow-Origin', your_url)
    self.response.headers.add('Access-Control-Allow-Headers', 'X-PINGOTHER, Content-Type')

def post(self):
    self.response.headers.add('Access-Control-Allow-Origin', your_url)

也就是藉由 OPTIONS method 先確定哪個 Origin 可以存取主機資源，哪些自定義或非簡單標頭，主機可以接受。Preflight 通過了，才能執行主要 Get / Post request。

以上藉由 Google App Engine 走一遍 跨源資源共享 的觀念和實作。也許讀者的開發環境不是 App Engine 或是 Python，可以再看一下上面 MDN 的文件，是一篇很好關於 CORS 的文章。