WHATWG HTML 規定 COOP 與 COEP 標頭必須是 structured field 型別
WHATWG HTML 規格 commit · 2026-10-03
COOP 與 COEP 標頭的值，過去只是「長得像 token 就好」，現在規格明確要求它必須真的是 structured field 的 token，report-to 參數則必須是 string。不符合的值不再被半解析，而是整個被當成沒設定。
這是 Anne van Kesteren 在 commit bf84f3c 做的修改，標題為 "Require structured field types for COOP and COEP"，對應的測試在 web-platform-tests/wpt 的 PR #63239。
原本的問題
規格早就說這兩個標頭是 structured header，值要是 token。但解析步驟本身沒有檢查型別：只要 structured field 解析出非 null 的 parsedItem，就直接拿 parsedItem[0] 去比對 policy 值。對 COEP 來說，這一步只檢查 parsedItem[0] 是否「compatible with cross-origin isolation」。
至於 report-to 參數，COOP 的解析步驟本來就要求是 string，COEP 卻只檢查「參數存在」，連型別都不看。同一組概念在兩個標頭上的寫法不一致，實作者只能各自猜。
核心改動
commit 在四個解析演算法裡（COOP、COOP report-only、COEP、COEP report-only）加上同一個前置條件：parsedItem[0] 必須是 token。COEP 的 report-to 也補上「必須是 string」的檢查，與 COOP 對齊。
| 情況 | 改動前 | 改動後 |
|---|---|---|
| COOP 值不是 token | 規格只判斷 parsedItem 非 null | 需同時滿足 parsedItem[0] 是 token |
| COEP 值不是 token | 只檢查是否相容 cross-origin isolation | 先要求是 token，再檢查相容性 |
COEP 的 report-to | 存在即採用 | 存在且是 string 才採用 |
用 structured field 的語法看，差別在引號：
Cross-Origin-Embedder-Policy: require-corp; report-to="coep" # token + string，合規
Cross-Origin-Embedder-Policy: "require-corp" # string，不是 token
Cross-Origin-Embedder-Policy: require-corp; report-to=coep # report-to 是 token，不是 string依新規則，第二行整個值不是 token，所以標頭被忽略；第三行的 report-to 不是 string，所以不會設定 reporting endpoint。
一個刻意的不對稱
commit message 自己承認：要求 report-to 是 string「是出乎意料的」，因為 endpoint name 本質上是 token，而且 Permissions-Policy 等其他標頭的 report-to 用的是 token。規格這樣寫的理由是「Chromium 與 WebKit 就是這樣實作的」，所以暫時讓規格去貼合現況。換句話說，這次是把規格寫成與瀏覽器行為一致，而不是新增限制。
commit message 沒有提到 Firefox 的行為，這點本文不做推測。
影響範圍
- 手寫跨源隔離標頭的人（為了用
SharedArrayBuffer之類需要 cross-origin isolation 的功能）：檢查report-to的值有沒有用雙引號包起來；commit message 指出 Chromium 與 WebKit 實作的是 string，未加引號的寫法不符合這個型別。 - CDN、反向代理、框架的標頭範本：若是用字串拼接產生 COOP／COEP，要確認輸出的是 token 而不是帶引號的 string。
- 瀏覽器與測試工具實作者：以 WPT PR #63239 的測試對照自己的解析邏輯，特別是 COEP 的
report-to型別檢查。
已經照 Chromium 與 WebKit 行為正確設定標頭的網站，不需要改任何東西。需要留意的是那些「剛好在某個瀏覽器能動」的寫法，之後規格與測試都不會再替它背書。