As part of my work on defining the multipart/form-data parser, I noticed a couple things in the File API standard related to MIME types:

• The MIME Sniffing standard's "parsable MIME type" definition is no longer present. It was removed as part of Revamp MIME type section whatwg/mimesniff#36.
• Blob's type attribute is defined as an ASCII string, perhaps assuming that every string that would be successfully parsed as a MIME type, as well as every serialization of a MIME type, would be ASCII strings. This is not the case, as per The values of the MIME type parameters aren't parsed as ASCII strings whatwg/mimesniff#141.
• Blob's type attribute is also defined as being lowercase. And while the MIME parsing algorithm does ASCII-lowercase the MIME record's type, subtype, and parameter names, it doesn't lowercase parameter values. See enforce lowercase letter on multipart boundary whatwg/html#6251 for a case where it matters.

The second point implies that on a response coming from the fetch API that for whatever reason happened to have the MIME type multipart/form-data; boundary=cadena-de-separación (notice the ó), response.formData() might succeed but response.blob() would fail, which would seem paradoxical.

The third point implies that if, for whatever reason, there was a response coming from the fetch API which contained an actual multipart/form-data payload coming from Chromium or WebKit (since they start their boundary strings with WebKitFormBoundary), and a developer decoded it as a Blob; trying to parse that blob afterwards with new Request(blob).formData() would fail, since the boundary string seems to be parsed case-sensitively.