nginx should take advantage of the system wide /etc/mime.types, its own pales in comparison to the system one. Unfortunately the syntax is different and /etc/mime.types cannot be used as is, but for example this small shell script can be used to generate one suitable for nginx from it: { echo "types {" sed -e 's/#.*//' -e 's/$/;/' -ne '/[^[:space:]][[:space:]]\{1,\}[^[:space:]]/p' echo "}" } < /etc/mime.types This could be run either at nginx package build time or perhaps even as a %trigger on mailcap if you're adventurous, although that's probably a can of worms. Anyway the script could also be shipped with the package so people can use it on demand.
Hi, thanks your your bug report! I agree that the mime.types shipped with nginx is not as exhaustive as the system mime.types, but I'm not convinced that we need to change the status quo. Admins can add any additional types they need. The overwhelming majority of admins don't need to add any types at all. Also, AFAIK the nginx mime.types is shipped un-edited in every major distribution. In my eyes, a default web server configuration should provide sane defaults and no surprises.
(In reply to Jamie Nguyen from comment #1) > In my eyes, a > default web server configuration should provide sane defaults and no > surprises. I agree, but to me the only sane default without surprises mime types mapping file is the global, consistent system one which is /etc/mime.types. Closing this as WONTFIX is very disappointing and against the movement of consistent distro wide defaults in many areas, and to me it's pretty much as bad as shipping private copies of say libraries already provided by the system. We have centralized configurations for things like this for a reason. I urge you to reconsider and will therefore reopen this.
The proposed solution is not centralizing the configuration, as changes to /etc/mime.types won't be carried over to /etc/nginx/mime.types (unless a new nginx package is pushed to the repositories). This is not the same as bundling a private copy of a library already provided by the system, as /etc/mime.types is not provided in a format that nginx can make use of. I'm sorry you're disappointed but the correct solution for properly centralizing mime.types in this case is for upstream to patch nginx to be able to make use of /etc/mime.types directly.
(In reply to Jamie Nguyen from comment #3) > the correct solution for properly centralizing > mime.types in this case is for upstream to patch nginx to be able to make > use of /etc/mime.types directly. It's not "the" correct solution, it's just one, and there are no guarantees nginx upstream would be interested in that because they don't need to care about consistency issues that are important within a distro. Or at least it is much less priority for them than it is for us. We could just do what I proposed and solve the problem ourselves, there's precedent for that for example with how our central timezone and CA certs data gets formatted/packaged for Java so it can use it.
Another correct solution would be for the mailcap package to provide a mime.types file in a format that nginx can use.
I could output one from the mailcap package (I'm its maintainer) but the "format that nginx can use" is in my opinion better handled by the nginx maintainers, not that I expect it the format to change. Granted, it makes things simpler in some respects if I just do it in mailcap. If you don't want to do this in nginx, let me know the package name and filename you would like. nginx-mimetypes? (mailcap shouldn't be in the name IMO because this really is about nginx and mime.types, not mailcap.)
Yes, please do provide one with the mailcap package. I'm not fussed about the filename, though something like /etc/mime.types.nginx might be better.
I think it's best to place it in /etc/nginx, why not just as /etc/nginx/mime.types like it currently is. BTW I can take care of the nginx side as well (provenpackager), all in F-24+ only at least for now. Let me know if you don't want this, otherwise I'll take care of the whole shebang later this week or next week latest.
Fine with me :)
(On a 2nd thought I'll probably wait a bit longer and do this update at the same time as the mailcap that goes to F-23 final to avoid some update churn.)
nginx-1.8.0-13.fc23 mailcap-2.1.45-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-471e2c7417
mailcap-2.1.45-1.fc23, nginx-1.8.0-13.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update mailcap nginx' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-471e2c7417
mailcap-2.1.45-1.fc23, nginx-1.8.0-13.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.