I'm not sure about extending the default MIME type list with such lesser used types.

This is just adding a random type. There are hundreds of MIME types a webserver needs to know about. There are many much more important than .wasm (just think about image formats like PNG or GIF). If we start going this path, we should go even further and provide a more extensive MIME database from the start.

The trouble is, if we include a considerably sized database by default, people will expect it to be comprehensive. And I don't think the Crystal developers should be bothered with maintaining this. That's typically the system or application administrator's job. If we just provide a minimal default set, it is clear that this is not meant for anything useful and you need to use a proper MIME database. With #5765 this is going to be much easier and typically don't require any configuration whatsoever.

The existing defaults are really just a bare minimum to get at least "something" going, but can't honestly provide anything useful.

@straight-shoota You thought the importance of wasm on Web is tooo little. It is the standard ranked with JavaScript in near future.

And other important point is, repeatedly, browser does not accept wasm file without correct Content-Type. This experience is so bad. What do you thikn if the image served by your server is not shown in browser?

Come on, it's just one line, it doesn't hurt anyone :-)

@makenowjust I know the current state is not satisfactory. That's why I did #5765. That's actually the better solution to your problem. Let's wait for it to get merged, and there shouldn't be any issues with missing MIME types (or it's easy to fix with MIME.register(".wasm", "application/wasm")).

@asterite it'll be 2000 lines if we allow crystal to maintain it's own complete mime registry. The fact is that wasm isn't that common a mime type. It's even too new to be in my /etc/mime.types! We should merge the mime registry, then people can super easilly register their own mime type in their own apps with one line of code.

It is true #5765 is better of course 😄

I don't hope crystal to maintain the entire mime db. It is too large. I think so too. I hope only to add just one line. In other words, wasm mime type should be contained in the smallest fallback mime db of crystal. I feel it is valuable because I'm sure wasm becomes the important Web standard and it can prevent the worst experience: wasm is not ran due to no mime type. In fact Go's standard library contains wasm mime type.

To be honest I'm embarrassed to need to use the server written Go to develop wasm 😢

Here's the thing, which happens a lot in this project: we have a simple fix that can improve a developer's life. Then we have a monolith that's a super good, flexible alternative, but it's being discussed, it's in review, etc. People in this community prefer to not add a single line now, which will be gone anyway later, and instead stay with a poor solution until the really good one comes. I'm seeing this a lot lately, unfortunately.

My only concern is that this line of code wouldn't be removed by #5765. But since you can just do MIME.register(".wasm", "application/wasm") in your user code until wasm makes it into the standard mime.types, it shouldn't be too big a deal to not include this in #5765's fallback registry.