[draft] Set response body info's content type to type after sniffing

[abinpaul1]

Issue: https://github.com/w3c/resource-timing/issues/203

WIP(Incomplete draft) changes relating to changes for adding Content-Type to Resource Timing. Early Draft explainer : https://gist.github.com/abinpaul1/0be57f55be3b6b84a06f4ac2443842da

• [ ] At least two implementers are interested (and none opposed):
  • …
  • …
• [ ] Tests are written and can be reviewed and commented upon at:
  • …
• [ ] Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …

(See WHATWG Working Mode: Changes for more details.)

---

/images.html ( diff ) /infrastructure.html ( diff ) /input.html ( diff ) /media.html ( diff ) /semantics.html ( diff )

[domenic]

I would rather not add any more features to the web that support content-type sniffing, and servers that do that. We're trying to eliminate that through various measures, and it seems like adding something of this sort would hurt our efforts in that area.

[yoavweiss]

@domenic - can you expand on how this would hurt our efforts? IIUC, this feature would just reflect what's currently happening, not increase it. If one day we're able to get away from sniffing for some types, this wouldn't prevent us from doing so, would it?

[domenic]

Sure. This basically rewards servers for not setting MIME types: they can just have the browser tell them what was sniffed. Instead, servers should set correct MIME types, and only what the server sets should then be reflected back.

This does indeed have a chance of hurting MIME type sniffing reduction efforts, because it introduces another way to take a dependency on the sniffed MIME type.

It seems like the use cases in the explainer could be solved just as well by only reflecting the actual Content-Type header. That way, servers which have not correctly set that header need to set it, to get the correct information on their resources.

[yoavweiss]

@nicjansma - following your comment, can you expand on why reflecting the type the server sent won't necessarily be good enough?

Are you concerned about cases where the server is properly optimizing the images to the latest format, yet sending them with the wrong mime type?

[abinpaul1]

As per discussion in WG call, the plan to expose the sniffed content-type is dropped in favour of using the value returned by the server. Changed the explainer to accomodate this.

I guess I can close this draft as the server returned Content-type is directly available in fetch and can be passed in from there.