Add content-type to resource-timing

[abinpaul1]

Introducing Content type. (https://github.com/w3c/resource-timing/issues/203) Fetch changes : https://github.com/whatwg/fetch/pull/1481

Explainer : https://github.com/abinpaul1/resource-timing/blob/explainer-content-type/Explainers/Content-Type.md

---

:boom: Error: Server Error :boom:

PR Preview failed to build. (Last tried on May 8, 2023, 11:28 AM UTC).

More

_If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please [file an issue](https://github.com/tobie/pr-preview/issues/new?title=Error%20not%20surfaced%20properly&body=See%20w3c/resource-timing%23341.)._

[abinpaul1]

I was trying to spec this out keeping in mind, the points mentioning not to reflect the header directly and only a set of relevant MIME types.

• It is currently(in this PR) specified to allow any MIME type that matches the groups presented in https://mimesniff.spec.whatwg.org/#mime-type-groups.
• Taking the case of say a ZIP-based MIME type, its described as any MIME type whose subtype ends in "+zip". So a content type such as application/u.26363-43323-42424+zip would be valid and reflected, which is not desired.
• To get around this, AFAIU we would need to define an exhaustive list of allowed MIME types to match against. I don't think we can go with the list that was mentioned in the WG call (https://www.iana.org/assignments/media-types/media-types.xhtml) because a good majority of those do not seem to be relevant for the use cases.
• If we were to keep an exhaustive list, which would be the more appropriate place to keep this? (MIME sniffing/Resource Timing). Such a list would have to updated as well when a new relevant content-type gains traction as well.

[yoavweiss]

@abinpaul1 - can we just reflect the MIME type's essensce?

[abinpaul1]

Yeah, but when we reflect the essence wouldn't this be a valid essence : application/u.26363-43323-42424+zip ? Here application would be type and u.26363-43323-42424+zip is the subtype

[yoavweiss]

Yeah, you're right.. Maybe it'd be possible to convince the MIMESNIFF editors to modify that definition, or otherwise monkeypatch it, if ZIP is the only mimetype that can expose such UIDs

/cc @domenic @annevk

[abinpaul1]

I don't think ZIP is the only one that can have such UIDs. JSON, XML MIME types also only requires subtype to end with +json, +xml. Morover, Image and audio/video MIME types does not have any restrictions on subtype (only requires the type to be image/audio/video)

[domenic]

Why is the full MIME type string not reflected? I couldn't find any reasoning in the explainer at https://github.com/abinpaul1/resource-timing/blob/explainer-content-type/Explainers/Content-Type.md#content-type-values.

[abinpaul1]

During the WG call when this was discussed, a concern was raised regarding reflecting the exact same value returned by server. From what I could understand the concern was mainly to protect against having any unique identifier as part of content-type in server response being relflected through resource timing API. @achristensen07, it would be great if you could please confirm or expand on the concern.

[yoavweiss]

I believe the concerns are related to https://github.com/w3c/server-timing/issues/89 and are planned to be discussed at TPAC.

[RByers]

Is there something blocking this PR from landing? Context: blink intent to ship

[yoavweiss]

This is waiting on the Fetch PR to land.