Content-type in Resource Timing

[abinpaul1]

Request for position on an emerging web specification

• WebKittens who can provide input: @achristensen07

Information about the spec

• Spec Title: Content-type in Resource Timing
• Spec URL: Add content-type to resource-timing w3c/resource-timing#341
• GitHub repository: https://github.com/w3c/resource-timing
• Issue Tracker: Include Content Type w3c/resource-timing#203
• Explainer: https://github.com/abinpaul1/resource-timing/blob/explainer-content-type/Explainers/Content-Type.md

Design reviews and vendor positions

• TAG Design Review: Content-type in Resource Timing w3ctag/design-reviews#785
• Mozilla standards-positions issue: Content-type in Resource Timing mozilla/standards-positions#705

Bugs tracking this feature

• Chromium : https://bugs.chromium.org/p/chromium/issues/detail?id=1366706
• WebKit Bugzilla:
• Radar:

Anything else we need to know

Link to entry on the Chrome Platform Status: https://chromestatus.com/feature/5156068351541248

[annevk]

I've been reviewing whatwg/fetch#1481 and from that perspective this seems like a reasonable addition. For revealing the (parsed value of the) Content-Type header it sticks to CORS for subresources and same-origin (including redirects) for navigation and as such seems like it will mainly help make it easier to categorize timing entries.

[achristensen07]

Could we restrict the allowed revealed content types to the values of Request.destination? That would prevent unique identifiers from being included in the strings.

[annevk]

Can't they already communicate unique identifiers to the requesting origin if they so desire?

[annevk]

Apologies for the delay here. I wanted to circle back with Alex when the various PRs got more concrete, but life happened.

We're supportive of this feature, but would like to see two changes to prevent passive leakage of data as this header is not otherwise broadcasted when embedding images, scripts, etc.:

• Restricting what we return to the MIME type's essence.
• Filtering the MIME type's essence to only return MIME types the browser supports, as well as deduplicating when MIME types mean the same thing (e.g., JavaScript MIME types).

I would be willing to set up the infrastructure for this in MIME Sniffing so you can pass an algorithm there a MIME type and get a filtered one back. (My tentative thinking is that it would do some deduplication for JSON/XML/JS and then fallback to https://mimesniff.spec.whatwg.org/#supported-by-the-user-agent which while not great, is probably good enough until we're happy to just write out the full list.)

Does that seem reasonable @abinpaul1 @yoavweiss?

[yoavweiss]

That works for me, thank you!! :)

[annevk]

I should have done this earlier, but let's label this as "position: support" one week from now given our feedback has been taken into account. Thanks @yoavweiss and @abinpaul1 for your help!