Closed Bug 1619451 Opened 5 years ago Closed 5 years ago

WebAssembly.{instantiate,compile}Streaming reject MIME type "application/wasm; charset=utf8"

Categories

(Core :: JavaScript: WebAssembly, defect, P3)

73 Branch
defect

Tracking

()

RESOLVED INVALID

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:

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

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

  1. Let response be unwrappedSource’s response.
  2. Let mimeType be the result of extracting a MIME type from response’s header list.
  3. If mimeType is not application/wasm, reject returnValue with a TypeError and abort these substeps.
    Note: extra parameters are not allowed, including the empty application/wasm;.
Component: Untriaged → Javascript: WebAssembly
Flags: needinfo?(surma)
Product: Firefox → Core

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.

Flags: needinfo?(surma)

I filed a bug with Chrome: https://crbug.com/1057973

thanks!

Keywords: parity-chrome

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.

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&regexp=false&path=)

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

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?

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

(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 :)

You need to log in before you can comment on or make changes to this bug.