Use a more common serialization for MIME types

[annevk]

This is a defense-in-depth for the issues that arised at #84. In theory they are all solved by whatwg/xhr#224, but given how quickly several sites turned up that relied on a space, it seems prudent to standardize on that serialization to avoid similar issues elsewhere.

---

Preview | Diff

[annevk]

cc @wisniewskit

[domenic]

I'm curious to what extent this is more or less compatible with what browsers do today in non-overrideMimeType contexts. But, editorially LGTM.

[annevk]

The issues are not due to overrideMimeType(), but manipulating Content-Type. This change would affect the former though. For both cases browsers historically only scanned the input string and only changed it in place. The only other context we have to compare with is Blob I think and like other contexts browsers don't really parse/serialize there (just pass the string through) at the moment.

[domenic]

Yeah, if the only other case where browsers serialize (or should serialize) is blobs, then I guess this will probably work out ok.

[annevk]

As noted in web-platform-tests/wpt#13544 (comment) I'm no longer convinced we should do this. The XMLHttpRequest change addresses all known issues, so let's keep the MIME type serializer stable for now.

[domenic]

Shall we close this then?

I'll note that the original implementation in jsdom actually included the inter-segment whitespace in the parsed data structure, for this sort of reason :(

[annevk]

Yeah, let's close this. To your aside, if sites actually depend on that they might depend on much more (such as text/html;garbage;charset=windows-1252 being preserved), so fingers crossed they don't and it's just XMLHttpRequest that needs more special casing.