Skip to content

Remove parsable mime type requirement? #13

Closed

Description

@inexorabletash

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:

new Blob(['yo'], {type: "te?xt/plain"}).type; // "te?xt/plain"

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

cc: @annevk @Ms2ger

Activity

  1. annevk commented on Jul 17, 2015

    @annevk
    Member

    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.

  2. annevk commented on Jan 9, 2020

    @annevk
    Member

    See #43 (comment) for what we should do here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions