Chrome 擴大 +xml MIME 類型判定範圍
Chrome Platform Status · 2026-09-26
Chromium 把「子類型以 +xml 結尾就算 XML」的判定範圍，從只認 application/ 開頭擴大到所有頂層類型——text/example+xml、image/example+xml、font/example+xml 都會被算進去，取代舊有只挑 application/*+xml 的窄判斷。這項改動已經以實驗旗標 SpecCompliantXmlMimeTypes 併入 Chromium 原始碼（CL 8301932，2026-09-04 merge），對應 Chrome Platform Status feature 5092584283308032，並帶著 bug 362282752。
原本的問題
Chromium 內部用來判斷「這個 MIME 類型算不算 XML」的共用函式 blink::IsXMLMimeType，長期只比對 application/ 開頭的 +xml 子類型。但WHATWG MIME Sniffing Standard 定義的 XML MIME 類型，是「任何合法 MIME 類型、只要子類型以 +xml 結尾」，並不限定頂層類型必須是 application。落差的直接後果出現在 PerformanceResourceTiming.contentType 上：伺服器若回應 text/example+xml 或 image/example+xml 這類 vendor-specific 子類型，這個屬性不會像規格要求的那樣被歸一化成 application/xml，而是原封不動吐回伺服器寫的字串。這不是當機或資料遺失，而是同一種資源類型在瀏覽器之間、甚至同一個瀏覽器的不同 Content-Type 前綴下，統計出來的分類不一致。
核心改動
旗標開啟後，blink::IsXMLMimeType 改用規格定義的後綴比對，不再限制頂層類型；image/svg+xml 的既有特例維持不變，不會被通用化吐成 application/xml。以下是 PerformanceResourceTiming.contentType 的行為對照：
| 回應 Content-Type | 旗標關閉（現行） | 旗標開啟（新行為） |
|---|---|---|
text/example+xml | 原樣回傳，不歸類 | application/xml |
image/example+xml | 原樣回傳，不歸類 | application/xml |
image/svg+xml | image/svg+xml | 不變，特例保留 |
application/rss+xml | application/xml | 不變 |
測試覆蓋寫在 mimesniff/mime-types/resources/mime-types-minimized.json，由 resource-timing/content-type-minimization.html 執行，涵蓋 text/example+xml、image/example+xml、font/example+xml、MIME 類型大小寫混用、以及帶參數的 MIME 字串五種案例。對應的 WPT PR #62420 由 chromium-wpt-export-bot 於 2026-09-03 開出，目前仍是 open 狀態、尚未合併進 upstream。
Chromium 把這項改動歸類為「Chromium catches up」——也就是補齊既有規格，而不是提出新規格或新 API。WPT PR 的描述裡也提到這次的做法「沿用 SpecCompliantJsonMimeTypes 的模式」，代表 Chromium 近期在把好幾種 MIME 類型判定（JSON、XML）逐一補齊到跟 WHATWG 規格一致，屬於同一系列的收斂工作。因為改動的是既有共用函式的比對邏輯而非新增介面，chromestatus 頁面上特別註記「為這項小型一致性修正申請 TAG review 豁免」，理由是沒有引入新的 API 介面或設計。
影響範圍
用 PerformanceObserver 讀取 Resource Timing 條目、依 contentType 把資源分桶統計的前端監控程式，如果原本假設「XML 類資源的 contentType 一定是 application/xml」，過去會漏掉非 application 開頭的個案；旗標開啟後這些個案會被歸進同一類，既有的分類統計數字可能因此變動，需要重新核對監控儀表板的分類邏輯。回應裡帶 vendor-specific +xml 子類型（例如自訂 feed 用 text/ 或 font/ 前綴）的伺服器維運者不需要改任何東西，這只影響前端讀到的分類值，不影響實際回應內容。換句話說，這次改動動到的是「瀏覽器怎麼標記資源類型」，不是「伺服器該回傳什麼」，維運端不必調整任何 Content-Type 設定。
比較需要留意的是安全審查：blink::IsXMLMimeType 這個共用函式同時被 Chrome Actor 的危險 MIME 類型導覽檢查使用，旗標開啟後，更多非 application 開頭的 +xml 回應可能被判定為需要攔截的導覽，Chromium 團隊在 feature 頁面上明確把這個交互作用列為安全審查項目，目前 security review 狀態是 Pending，privacy review 狀態同樣是 Pending，兩項都還沒有結論。這是一個行為變更而非新 API，沒有開發者需要做的 opt-in 或遷移步驟，一旦 SpecCompliantXmlMimeTypes 未來預設開啟，contentType 的回傳值就會直接改變。
目前 Chrome Platform Status 上的狀態是「Proposed」，對應的 milestone 是 158（desktop、android、webview），尚未預設啟用，須加上 --enable-experimental-web-platform-features 才能在本機測試。Firefox 與 Safari 對這五項新增的 WPT 案例都標記「No signal」：2026-09-04 的 Firefox Nightly 157.0a1 執行結果五個案例全數失敗、contentType 回傳原始字串；同一天的 Safari Technology Preview 251 執行結果則是 contentType 直接是 undefined。
原始來源：Chrome Platform Status、Chromium CL 8301932、Chromium bug 362282752、WHATWG MIME Sniffing Standard、web-platform-tests PR #62420