4 ms·

Ruffle developer here. A good chunk of our incoming issue volume used to be "how do we configure the WASM mime type" disguised in various "omg it doesn't work,

Ruffle developer here. A good chunk of our incoming issue volume used to be "how do we configure the WASM mime type" disguised in various "omg it doesn't work, what does this error mean" type issues. This is because we were using WASM's instantiateStreaming function to load our module, which requires valid HTTP headers on the WASM file which most web servers weren't configured to produce. Adding a fallback to a slower WASM load approach that doesn't require a header made all those complaints go away. In our experience the average webmaster does not know how to configure proper HTTP headers and should not be expected to for a basic web library. So any web API that will not work with the standard web server configurations of Apache, nginx, or IIS is a non-starter for us. (Not to mention that the site isolation headers have non-trivial implications for sites that use iframes...)

rewq4321 5y ago
That's a fair point. I hope you're involved in the spec discussions around these topics! There's definitely room for improvement in terms of ease of use. I noticed this update on the https://web.dev/coop-coep/ https://web.dev/coop-coep/ article recently: > We've been exploring ways to deploy Cross-Origin-Resource-Policy at scale, as cross-origin isolation requires all subresources to explicitly opt-in. And we have come up with the idea of going in the opposite direction: a new COEP "credentialless" mode that allows loading resources without the CORP header by stripping all their credentials. We are figuring out the details of how it should work, but we hope this will lighten your burden of making sure the subresources are sending the Cross-Origin-Resource-Policy header.