Add content-type to resource-timing
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
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+zipwould 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.
@abinpaul1 - can we just reflect the MIME type's essensce?
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
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
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)
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.
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.
I believe the concerns are related to https://github.com/w3c/server-timing/issues/89 and are planned to be discussed at TPAC.
Is there something blocking this PR from landing? Context: blink intent to ship
This is waiting on the Fetch PR to land.