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.

まず、Blob の type 属性に関する File API の定義と、関連する MIME Sniffing および HTML の issue を確認します。MIME の解析、シリアライズ、大文字と小文字の扱い、非 ASCII 値に関する現在の要件を比較します。影響を受ける仕様について合意された一貫した解決策が得られた時点で、作業は完了です。