You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the definition for the type attribute, the spec has:
The ASCII-encoded string in lower case representing the media type of the Blob. On getting, user agents must return the type of a Blob as an ASCII-encoded string in lower case, such that when it is converted to a byte sequence, it is a parsable MIME type [MIMESNIFF], or the empty string -- 0 bytes -- if the type cannot be determined.
There's a fair bit weird about that paragraph (e.g. 'ASCII-encoded' when the entry points which set the type already reject non-ASCII input, referring to the length of the string in bytes...). But neither Chrome nor Firefox appear to do the filtering of non-parsable MIME types:
Even if we decide to keep the spec and file/fix implementation bugs, can we rejigger the spec so that the entry points that set type (constructors, slice()) do all of the filtering work, rather than spreading it across two parts of the spec? (Unless there's subtlety I'm missing...)
I agree that this logic should be in the constructor. My hope of enforcing it there was that you could then use it reliably for logic elsewhere. E.g. we want to use this value and put it in Content-Type for various networking features.
Activity
annevk commentedon Jul 17, 2015
I agree that this logic should be in the constructor. My hope of enforcing it there was that you could then use it reliably for logic elsewhere. E.g. we want to use this value and put it in
Content-Typefor various networking features.annevk commentedon Jan 9, 2020
See #43 (comment) for what we should do here.