Issues with MIME types

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 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 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 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.

Beginne mit der Durchsicht der File API-Definitionen für das type-Attribut von Blob sowie der verknüpften MIME Sniffing- und HTML-Issues. Vergleiche die aktuellen Anforderungen an MIME-Parsing, Serialisierung, Groß-/Kleinschreibung und Nicht-ASCII-Werte; die Arbeit ist abgeschlossen, wenn für die betroffenen Spezifikationen eine abgestimmte, konsistente Lösung gefunden wurde.