[w3c/FileAPI] Issues with MIME types (#170)

As part of my work on [defining the `multipart/form-data` parser](https://github.com/andreubotella/multipart-form-data), 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 payload with `new Request(blob).formData()` would fail, since the boundary string is parsed case-sensitively (at least in Chromium).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/170