On 10/5/26 11:24 p.m., Chromestatus wrote:
*Contact emails*
[email protected]
*Specification*
https://mimesniff.spec.whatwg.org/#xml-mime-type
*Summary*
Chrome is updating how it Detects XML MIME types to fully align with
Web standards. Chrome will now recognize valid MIME types whose
subtype ends in `+xml` as XML across Chrome and Android WebView,
including non-application types such as `text/example+xml` and
`image/example+xml`. For these responses,
`PerformanceResourceTiming.contentType` returns application/xml. The
value for image/svg+xml remains unchanged. Enterprise web applications
that rely on previous `contentType` values may observe behavior
changes. Chrome Actor also uses this shared XML classification for
dangerous MIME type navigation checks, so it may block navigations to
additional non-application +xml responses. IT admins should check
whether their applications depend on these MIME types or the previous
`contentType` values.
*Blink component*
Blink>Network
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22>
*Web Feature ID*
/No information provided/
*Motivation*
Chromium currently applies generic +xml suffix matching only to
application/* MIME types, although the WHATWG MIME Sniffing Standard
defines any valid MIME type whose subtype ends in +xml as an XML MIME
type. As a result, non-application types such as text/example+xml are
not minimized to application/xml in
PerformanceResourceTiming.contentType. This change aligns Chromium's
classification with the existing standard and improves
interoperability. Implementation (merged behind an experimental
feature):
https://chromium-review.googlesource.com/c/chromium/src/+/8301932
*Initial public proposal*
/No information provided/
*TAG review*
Requesting a TAG review exception for this small conformance change to
the existing WHATWG MIME Sniffing Standard. The change broadens XML
MIME type suffix matching to include non-application types. No new API
surface or API design is introduced.
*TAG review status*
Not applicable
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
This change aligns XML MIME type classification with the existing
WHATWG MIME Sniffing Standard. The web-visible change is that
PerformanceResourceTiming.contentType returns "application/xml" for
additional non-application MIME types whose subtype ends in "+xml".
Code that depends on the previous contentType value may observe a
different result. The special handling of "image/svg+xml" is
preserved. The change is controlled by SpecCompliantXmlMimeTypes,
allowing the previous behavior to be restored by disabling the feature.
From what I can tell this change is just scoped to resource timing, so
only a handful of RUM providers would be affected (in the hypothetical
that some script is expecting "application/atom+xml" via
PerformanceResourceTiming.contentType but now seeing "application/xml"
and exploding). Is there some issue where RUM providers are asking for
this / might find out about the change?
Even so, I'd love to better understand the compat risk of this proposed
change. Above it mentions "Enterprise web applications that rely on
previous `contentType` values may observe behavior changes" - do we
think enterprises are more likely to be affected by this change? Are we
able to estimate or reason about breakage for non-enterprise use cases?
e.g., some site is expecting "application/atom+xml" via
PerformanceResourceTiming.contentType but now seeing "application/xml"
going to break something (that sounds far-fetched, I dunno)?
As an aside,
https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/actor/execution_engine.cc;l=288-299
should probably be looked at by the security reviewer/other owners for
this change. "image/svg+xml" will start to return true here with this
change, when it return false before, if I'm reading the code correctly.
I see in your CL
<https://chromium-review.git.corp.google.com/c/chromium/src/+/8301932/comments/dabacf37_52e1d902>
you wrote "MIMETypeRegistry::IsXMLMIMEType unification is intentionally
left as follow-up" - can you explain your plan there? That seems like a
riskier change to me, since it will affect navigation & loading.
/Gecko/: No signal Firefox recognizes non-application "+xml" MIME
types in its XHR implementation, but the Resource Timing minimization
behavior differs. In the WPT PR #62420 run dated 2026-09-04, Firefox
Nightly 157.0a1 failed all five added XML cases. For example,
contentType returned "text/example+xml" instead of "application/xml".
Results:
https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=6323630396145664
No formal standards position has been requested. An exception is
requested for this small conformance change, subject to API owner review.
We should probably request a formal position at
https://github.com/mozilla/standards-positions, because the ideal
outcome is all browsers are doing the same thing rather than diverging
in subtle ways.
/WebKit/: No signal WebKit recognizes non-application "+xml" MIME
types in its XML MIME classification code. This does not establish
support for PerformanceResourceTiming.contentType. In the WPT PR
#62420 run dated 2026-09-04, Safari Technology Preview 251 failed all
five added XML cases because contentType was undefined. Results:
https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=5125540410556416
No formal standards position has been requested. An exception is
requested for this small conformance change, subject to API owner review.
Ditto here - https://github.com/WebKit/standards-positions please.
/Web developers/: No signals
/Other signals/:
*Ergonomics*
No new API or calling convention is introduced. Developers continue to
read PerformanceResourceTiming.contentType through the existing
Resource Timing API.
*Activation*
No developer opt-in is required. Applications that rely on the
previous contentType value for non-application "+xml" responses may
need to adjust their expectations.
*Security*
The change broadens the MIME types classified as XML by
blink::IsXMLMimeType. It does not change the existing response-access
checks that govern exposure of PerformanceResourceTiming.contentType.
The shared helper is also used by Chrome Actor's dangerous-MIME-type
navigation checks. When those checks and SpecCompliantXmlMimeTypes are
enabled, additional non-application "+xml" types may be blocked.
*WebView application risks*
Does this intent deprecate or change behavior of existing APIs, such
that it has potentially high risk for Android WebView-based applications?
Applications that inspect PerformanceResourceTiming.contentType may
observe "application/xml" for additional non-application "+xml" MIME
types. Applications that depend on the previous value may behave
differently. The change is guarded by SpecCompliantXmlMimeTypes, which
provides a way to restore the previous behavior.
*Debuggability*
1. Basic support Manually checked on macOS using Content Shell with
--enable-features=SpecCompliantXmlMimeTypes and DevTools attached to
the test page. Console evaluation and autocomplete worked during the
check. Chrome DevTools for agents was not separately tested. 2.
Inspectability A local server returned Content-Type: text/example+xml.
The response was fetched and its PerformanceResourceTiming entry was
obtained through PerformanceObserver. Reading entry.contentType in the
DevTools Console returned "application/xml" as expected. Autocomplete
for contentType was also verified. The server's original Content-Type
header and the minimized Resource Timing value are distinct. 3.
Extended support No dedicated DevTools workflow is proposed. The
changed value can be inspected through existing Console functionality.
4. Automated testing Yes. The existing WPT
resource-timing/content-type-minimization.html exercises the added
non-application "+xml" cases. Implementation:
https://chromium-review.googlesource.com/c/chromium/src/+/8301932 WPT
export: https://github.com/web-platform-tests/wpt/pull/62420
*Will this feature be supported on all six Blink platforms (Windows,
Mac, Linux, ChromeOS, Android, and Android WebView)?*
Yes
The change uses shared Chromium MIME classification code with no
platform-specific restrictions. Support is intended for Windows,
macOS, Linux, ChromeOS, Android, and Android WebView.
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
The implementation adds test cases to:
mimesniff/mime-types/resources/mime-types-minimized.json These cases
are exercised by: resource-timing/content-type-minimization.html
Coverage includes text/example+xml, image/example+xml,
font/example+xml, uppercase MIME types, and MIME parameters.
Parameterized C++ unit tests cover both enabled and disabled feature
states, existing XML MIME types, additional "+xml" types, and invalid
MIME inputs. Implementation and tests:
https://chromium-review.googlesource.com/c/chromium/src/+/8301932 WPT
export: https://github.com/web-platform-tests/wpt/pull/62420 The WPT
additions were merged upstream on September 30, 2026:
https://github.com/web-platform-tests/wpt/pull/62420 PR-level browser
results are available, including the five added XML cases:
https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=6323630396145664&run_id=5125540410556416
<https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=6323630396145664&run_id=5125540410556416>
*Flag name on about://flags*
enable-experimental-web-platform-features
*Finch feature name*
SpecCompliantXmlMimeTypes
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://issues.chromium.org/issues/362282752
*Measurement*
No dedicated UseCounter is added by this change. The occurrence of
affected non-application "+xml" MIME types is not separately measured
by this implementation.
*Availability expectation*
Expected to be available by default on Blink platforms after launch
approval and default enablement of SpecCompliantXmlMimeTypes.
*Adoption expectation*
Existing users of PerformanceResourceTiming.contentType will receive
spec-compliant values for additional XML MIME types without changing
their API usage. No quantitative adoption estimate is available.
*Adoption plan*
Communicate the behavior change through the Blink intent process and
track any necessary documentation and browser compatibility updates.
*Non-OSS dependencies*
Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
None. The implementation uses Chromium code and its existing
open-source dependencies.
*Estimated milestones*
Shipping on desktop 158
Shipping on Android 158
Shipping on WebView 158
*Anticipated spec changes*
Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github
issues in the project for the feature specification) whose resolution
may introduce web compat/interop risk (e.g., changing to naming or
structure of the API in a non-backward-compatible way).
None anticipated. This change implements the existing XML MIME type
definition and MIME type minimization rules in the WHATWG MIME
Sniffing Standard.
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5092584283308032?gate=6712519581368320
*Links to previous Intent discussions*
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a922400.e8a51b51.6abb3.033c.GAE%40google.com
This intent message was generated by Chrome Platform Status
<https://chromestatus.com>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ac46a00.082f26cb.22c2b.02d5.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ac46a00.082f26cb.22c2b.02d5.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a001784-feac-458e-8045-aa6433e898b8%40chromium.org.
