should Response.blob() type include parameters like charset?

[wanderview]

Writing this issue based on this gecko bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1362824

To summarize, if you visit this test in different browsers you will get different blob types:

https://bl.ocks.org/jhabdas/87f8bc3573cf91b4c35e0c799addd762

You get:

• Chrome: text/css
• Safari: text/css
• Yandex: text/css
• Firefox: text/css; charset=utf-8
• Edge: text/css; charset=utf-8

Alternatively, if you run this code in the console in various browsers you get a different set of types:

new Response(new URLSearchParams('name=value')).blob().then(b => console.log(b.type))

You get:

• chrome: application/x-www-form-urlencoded;charset=utf-8
• safari: application/x-www-form-urlencoded
• firefox: application/x-www-form-urlencoded;charset=utf-8
• edge: does not support URLSearchParams

As you can see, browsers are inconsistent in whether to include the charset param in the Blob.type content-type value. Firefox always includes it. Safari never includes it. Chrome sometimes includes it.

What do people think these different cases should do?

Sorry if this should go on a different spec, but behavior seems somewhat dependent on source, so thought fetch might be a reasonable place to start.

[ghost]

For traceability, thread starts here: https://github.com/jhabdas/fetch-inject/pull/14

[youennf]

The spec talks about mime type, which blob type is related, and content type.
I would expect mime type to have no charset contrary to content type.
Is the issue about consistency between browsers or about missing sometimes information from the blob type?

[wanderview]

I think its browser consistency.

FF and Edge always include the charset parameter in the blob type if the source has it.

Chrome and Safari seems to remove the charset parameter when coming from some sources, like network. They include the charset parameter when coming from other sources, like a manually created blob.

It feels like we should converge to some common behavior.

[annevk]

Right, and we should probably convergence on "content type" since "MIME type" doesn't include sufficient information in all cases.

[ghost]

I'm dropping in some links here which I believe most developers in the know use when referencing APIs for development in 2017, and the descriptions of those items:

http://devdocs.io/dom/blob/type

The type property of a Blob object provides the MIME type of the file. It returns an empty string if the type couldn't determined.

http://devdocs.io/dom/response/headers

The headers read-only property of the Response interface contains the Headers object associated with the response.

---

As things are, common knowledge suggests blob.type is the MIME type and Content-Type (including properties such as charset) can be pulled from a response header in a network context.

What would be the value in converging on something which is not common knowledge and that which can already be determined using other available mechanisms?

[annevk]

If you consume a Blob object someone handed you, there's no way to determine the boundary of application/form-data through other mechanisms than having access to the "content type".

[ghost]

This is greek to me, but it seems it may bear relevance to this discussion:

fetch/fetch.bs

Lines 423 to 430 in a38ae96

	<li>`<code>Content-Type</code>` and whose <a for=header>value</a>,
	<a lt="extract header values">once extracted</a>, has a MIME type (ignoring parameters)
	that is `<code>application/x-www-form-urlencoded</code>`,
	`<code>multipart/form-data</code>`, or `<code>text/plain</code>`
	</ul>
	<!-- XXX * needs better xref
	* ignoring parameters has been the standard for a long time now
	* interesting test: "Content-Type: text/plain;" -->

[annevk]

That's about which headers can emitted across origins without CORS preflight. Unrelated.

[ghost]

The application/form-data is a MIME type I'm not familiar with and have not seen registered with IANA or elsewhere, so I'm not sure what to make of it. Assuming we're discussing multipart/form-data for POST requests the following SO discussion may be useful. But until I have a better understanding or time to do more research I'm not going to be of much more use here.

http://stackoverflow.com/a/23152871/712334

I know this is 3 years too late, but Matt's (accepted) answer is incomplete and will eventually get you into trouble. The key here is that, if you choose to use multipart/form-data, the boundary must not appear in the file data that the server eventually receives.

The problem with multipart/form-data is that the boundary separator must not be present in the file data (see RFC2388; section 5.2 also includes a rather lame excuse for not having a proper aggregate MIME type that avoids this problem).

Please let me know if I can help issue browser bugs to help with behavioral normalization when it makes sense to help me level-up my understanding. Cheers.

[annevk]

@JHabdas ah yeah, multipart/form-data. Sorry about that. If you're interested in doing more this could use some web-platform-tests. Both for the Blob constructor and for the Fetch APIs.

There's also w3c/FileAPI#43 that needs to be sorted in some way I suppose.

[ghost]

Chrome bug submitted and linked: https://bugs.chromium.org/p/chromium/issues/detail?id=724433

[annevk]

This relates to whatwg/mimesniff#30.

[annevk]

FWIW, I basically concluded here that yes, it should include parameters.

web-platform-tests/wpt#7764 tests this and implementation bugs have been filed as well, so I think this can be closed?