WebAssembly.{instantiate,compile}Streaming reject MIME type "application/wasm; charset=utf8"
Categories
(Core :: JavaScript: WebAssembly, defect, P3)
Tracking
()
People
(Reporter: surma, Unassigned)
Details
(Keywords: parity-chrome)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0
Steps to reproduce:
- Use
http-server
from npm (https://npm.im/http-server) to serve a page loading a Wasm module
Actual results:
Error "TypeError: Response has unsupported MIME type"
Expected results:
The module should have been instantiated/compiled successfully.
Comment 1•5 years ago
|
||
Is it loaded on other browsers?
according to the spec, parameters are not allowed there.
https://www.w3.org/TR/wasm-web-api-1/#streaming-modules
- Let response be unwrappedSource’s response.
- Let mimeType be the result of extracting a MIME type from response’s header list.
- If mimeType is not
application/wasm
, reject returnValue with aTypeError
and abort these substeps.
Note: extra parameters are not allowed, including the emptyapplication/wasm;
.
Oh interesting. It does load in Chrome, Safari hasn’t shipped {compile,instantiate}Streaming. My hunch is that Chrome is unlikely to align with the spec now as it could break sites.
I filed a bug with Chrome: https://crbug.com/1057973
Comment 5•5 years ago
|
||
I wonder what charset would mean in this context. The content of application/wasm is binary with no real room for alternative interpretations. There may be text strings in some sections but they are invariably utf8 (https://webassembly.github.io/spec/core/binary/values.html#names). I guess it is conceivable that there could be browser-defined custom sections and that they could be subject to interpretation by the browser and could be subject to the charset, but it seems far-fetched.
Comment 6•5 years ago
|
||
Mostly this is about WASM_CONTENT_TYPE (ending up here: https://searchfox.org/mozilla-central/source/dom/fetch/FetchUtil.cpp#475) but in general the assumption that the mimetype is === "application/wasm" is scattered throughout (https://searchfox.org/mozilla-central/search?q=application%2Fwasm&case=true®exp=false&path=)
Chrome accepted my patch, so Chrome’s behavior is now aligned with the spec and Firefox’s behavior :) See https://crbug.com/1057973
I think this can be closed?
Updated•5 years ago
|
Comment 8•5 years ago
|
||
(In reply to surma from comment #7)
Chrome accepted my patch, so Chrome’s behavior is now aligned with the spec and Firefox’s behavior :) See https://crbug.com/1057973
I think this can be closed?
Fabulous :)
Description
•