mod_http_upload: missing content types

[marc0s]

Some files uploaded via mod_http_upload will have the default Content-Type header value of application/octet-stream because their mapping of extension => mime type is missing from both mod_http_upload.erl and mod_http_fileserver.erl.

We're using the Content-Type header in our client to determine if the referenced file may be previewed in the conversation or just linked to it for the user to download it. When a file whose MIME type is not listed in the modules mentioned above, but it's a media file we want to embed into the conversation, we're unable to do so because it looks like a generic file. This happens with webm audio files, for instance.

To overcome this situation, I'd say we should do one of the following:

• allow to configure the mappings of extension => mime types in one of the module's configuration in ejabberd.yml
• create the mapping from the /etc/mime.types (or equivalent) file present in lots (almost all?) of operating systems
• fetch the IANA mediatypes' list and generate the mapping from there (exhaustive, but I think overkill)

IMHO, the first option is both flexible and enough.

Thoughts on this?

[licaon-kter]

but mod_http_fileserver has them configurable per https://docs.ejabberd.im/admin/configuration/modules/?mod_http_fileserver#mod_http_fileserver

for mod_http_upload use your web server software to define mime, what do you use, nginx, apache?

[marc0s]

for mod_http_upload use your web server software to define mime, what do you use, nginx, apache?

We have nginx, so yeah, should check there. Thanks!

[marc0s]

Allow me to reopen this one 🙂

Although we're using an nginx server in front of our ejabberd, nginx is not actually serving the files, but proxying the requests to mod_http_upload. In such scenario, the HTTP request is ultimately handled by mod_http_upload, so the Content-Type header is set there.

The guessing of the Content-Type header is done here, via mod_http_file_server:content_type/3, which "just" takes the file extension and scans ContentTypes list to check if it's in there, if not, the DefaultContentType is returned.

Both ContentTypes and DefaultContentType are fed from mod_http_upload's macros, not configuration options.

Given all that, I believe that additional MIME types are disallowed to be pretty-rendered in clients if the HTTP server is serving them as application/octet-stream (or forcing clients to rely on the extension to guess -again- the MIME type).

That's why I think that mod_http_upload should accept some map to define those additional extensions or mod_http_fileserver actually use the configured additional extensions when guessing the content type in content_type/3 (or whatever new function mod_http_upload may use to guess it).