I think it would be better more predictable not use mimetypes module, but add a simple module that parse handle mimetypes queries and parse the data file.

@HelloZeroNet, why? mimetypes is a small module, it's included in standard Python library and already bundled&used in ZeroNet.

@HelloZeroNet Any progress on this?

I still think it would be easier/faster to include a small list of known popular filetypes without using the mimetypes module. For example: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types

@HelloZeroNet What if program first checks some common MIME types from your list. If none of them matches, the program also checks mimetypes module (because it contains more types). If it still doesn't match, it uses application/octet-stream.

It's also possible, but I think its better if it's does not depends on system settings, but works the same way on for every client. So if there is any problem related to content-type, then we can find the problem and reproduce it easier.

@HelloZeroNet Are you aware that mimetypes module just loads my list and parses it, without using system mime types? Are you still want to replace it with a custom one? I don't understand the reason.

I usually try to avoid using packages if I can do the same with a few lines of code to avoid unwanted side effects.
Eg for in this case mimetypes.guess_type("any.html.xz")[0] returns text/html, but probably we want to serve it xz file as browsers won't be able to display the xz file content as html
Other problem could be if any other module uses the mimetypes before our mimtes.init called, then it won't be inited from our file.

Unfortunately I don't have much spare time recently.
I propose the following: use this modification for Python 2 version, and for Python 3 version I (or somebody else) will make a proper mime types implementation.