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.

Commencez par examiner les définitions de File API pour l’attribut type de Blob ainsi que les issues associées de MIME Sniffing et HTML. Comparez les exigences actuelles concernant l’analyse MIME, la sérialisation, la casse et les valeurs non ASCII ; le travail est terminé lorsque les spécifications concernées disposent d’une résolution convenue et cohérente.