Spinning off from #36 to discuss this specific issue.
In https://github.com/jsdom/content-type-parser we, for some reason, preserved the separator between MIME type parameters. (So, e.g., it maybe ; or ; with a space or something else.) This means that when you parse-then-serialize, the separators are preserved.
I believe this might have been necessary to pass some of the XMLHttpRequest or File API web platform tests? I'm not sure; perhaps @nicolashenry, the original author of that code, remembers.
Browsing through usages in jsdom it appears we make use of this ability in FileReader, which (at least in our implementation) parses-then-serializes the Blob's type when creating the data: URL. We also use it when creating a Blob xhr.response, to set the blob's type value from the parse-then-serialize of the Content-Type header.
Maybe there are web platform tests that assume this, but should not, because it's pretty silly?
I suppose we could try changing this in jsdom and see what tests start failing.
Spinning off from #36 to discuss this specific issue.
In https://github.com/jsdom/content-type-parser we, for some reason, preserved the separator between MIME type parameters. (So, e.g., it maybe
;or;with a space or something else.) This means that when you parse-then-serialize, the separators are preserved.I believe this might have been necessary to pass some of the XMLHttpRequest or File API web platform tests? I'm not sure; perhaps @nicolashenry, the original author of that code, remembers.
Browsing through usages in jsdom it appears we make use of this ability in FileReader, which (at least in our implementation) parses-then-serializes the Blob's
typewhen creating thedata:URL. We also use it when creating aBlobxhr.response, to set the blob'stypevalue from the parse-then-serialize of the Content-Type header.Maybe there are web platform tests that assume this, but should not, because it's pretty silly?
I suppose we could try changing this in jsdom and see what tests start failing.