Use correct Content-Type for SVG files

[stefan-muc]

With miniweb, SVG files aren't displayed properly in browser, because he uses Content-Type: application/octet-stream instead of the correct one image/svg+xml

I added this in my branch https://github.com/stefan-muc/miniweb/tree/stefan-muc/SVG_Content-Type maybe you want to cherry-pick one or both changes (67319d8 and eebbe28) I made there? Sadly I can't create a pull request as Github doesn't recognize my repository as a fork (despite it is one). I just haven't all changes that you made, because I didn't get them to compile on Windows, neither with Visual Studio nor with cygwin, but cherry picking should be possible when you add my repository as remote.

[avih]

Thanks, both patches look good, but won't take them because I don't plan to maintain this project further, as it's too hard to keep secure. See #6 (I do have the fix for that issue, but been lazy to actually push it, nevertheless, there surely are more issues).

Re this specific svg issue, it appears that browsers are actually quite good at deducing the correct mime type from the file name and content - if you don't mislead them with incorrect type. While it's easy to add types, if you plan to keep using miniweb, I'd suggest instead to just not send the content-type if you don't know it exactly, though I didn't try such patch myself.

[stefan-muc]

Oh I didn't know that, thanks for the advice! Maybe it would be good to state that in the README.md of this project?
I only used miniweb for a local environment, but of course miniweb opened a port on the computer, so that it was vulnerable by other computers in the network (which I basically trust, but you never know...)

I searched for an alternative, but I didn't find something neat as miniweb - so I finally came to using nginx which was a pain to configure for a read-only drive/path [https://trac.nginx.org/nginx/ticket/1592](one issue left...), but now I have a full-blown webserver which I can configure properly (e.g. only take localhost connections). The downsides are that executable size went from 207 KiB to 2.97 MiB and that nginx always needs a configuration file (if you can't live with the defaults - which I can't as this is using port 80)

One word regarding mime type: Yes, some browser do auto discovery, but that's not what's standard compliant (IE e.g. does have some severe flaws in that e.g. executing JavaScript in files that are images). In web there are no file extensions, there are just mime types - stick to that and it makes it more secure and convenient.

[avih]

Yeah, I will update the readme. As an alternative (for myself) I've written a tiny cross platform web server which is easier to keep secure as it has much less code, and also has better directory listing and correct partial content (unlike the buggy one in miniweb). I was planning to update the readme once I upload the new project it to github, which will hopefully happen soon. Famous last words ;)

In web there are no file extensions, there are just mime types - stick to that and it makes it more secure and convenient.

While correct, recall that what miniweb and your patches and most other servers do is exactly that - set a mime type by the file extension. And if it's the mechanism anyway, IMO it's best left for the browser to decide, as it can also do content detection - which miniweb doesn't do, as well as probably a more extensive extension -> mime type database than a server will maintain.

[avih]

only take localhost connections

Most servers, including miniweb and sandbird (the new tiny server I wrote) support this by binding to 127.0.0.1 rather than the (usually) default of 0.0.0.0 .

The downsides are that executable size went from 207 KiB to 2.97 MiB

sandbird is smaller than miniweb. ~30k on most platforms, and ~16k upx'ed ;) though practically, does anyone really care about 3M executable? (well, I do, sometimes)