Content-type response header incorrect for .wasm

[ZacJW]

I've just started using sfz 0.6.1 for some WebAssembly development and I've noticed some odd behaviour.

When I request a .wasm file, sfz responds with content-type: application/wasm; charset=utf-8 but this isn't a utf-8 encoded file, it's a binary format. As a result when I try to load the WebAssembly in Firefox 92, it complains about the MIME type not being as expected and having to fallback to a slower instantiation method as a result.

`WebAssembly.instantiateStreaming` failed because your server does not serve wasm with `application/wasm` MIME type. Falling back to `WebAssembly.instantiate` which is slower. Original error:
 TypeError: WebAssembly: Response has unsupported MIME type 'application/wasm; charset=utf-8' expected 'application/wasm'

Here's a curl -v with sfz serving the file

*   Trying 127.0.0.1:5000...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 5000 (#0)
> GET /pkg/web_rust_bg.wasm HTTP/1.1
> Host: 127.0.0.1:5000
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: sfz/0.6.1
< cache-control: public, max-age=0
< last-modified: Sat, 02 Oct 2021 14:34:33 GMT
< etag: "1633185273-23174"
< accept-ranges: bytes
< content-type: application/wasm; charset=utf-8
< content-length: 23174
< date: Sat, 02 Oct 2021 19:10:56 GMT
< 

For extra context, here's a curl -v with python3 -m http.server serving the file, which does not produce the error

*   Trying 127.0.0.1:8000...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8000 (#0)
> GET /pkg/web_rust_bg.wasm HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.8.10
< Date: Sat, 02 Oct 2021 19:11:38 GMT
< Content-type: application/wasm
< Content-Length: 23174
< Last-Modified: Sat, 02 Oct 2021 14:34:33 GMT
< 

[weihanglo]

Hi, I am going to fix this with a naive patch #77. See if this is suitable for your case. Thanks.

[weihanglo]

The situation become better after #77 but still not good to blindly guess that all contents defaults to UTF-8. I'll keep this issue to track the integration of charset detection library, such as chardetng. Charset detection may introduce extra I/O on the content, so we need to be careful. Follow how Firefox integrates chardetng may be a good start.

Besides, sfz doesnot leverage hyper Body stream and instead it read all content into memory (as #33 described). This lack might also affect how charset detection would look like in sfz. We'd better address this as well if possible.

[fasterthanlime]

I understand charset detection isn't ideal yet, but I had that same issue and #77 did fix it. Could a new version of the crate be published with this fix before the new charset detection stuff is worked in?

[weihanglo]

Hi, @fasterthanlime. Just release 0.6.2. Thanks for your suggestion!

[weihanglo]

Thank you for the PR. Unfortunately I have no time working on it. See #108.