Opened 14 months ago

Last modified 14 months ago

#2552 new enhancement

Correct xsl and xslt mimetypes missing from ngxinx mime.types file

Reported by: apotek@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.25.x
Keywords: config, mimetypes, xsl, mime, mime.types Cc:
uname -a: All OSs
nginx -V: Issue exists in latest dev code here https://trac.nginx.org/nginx/browser/nginx/conf/mime.types

Description

Since the default mimetype configured in nginx.conf is application/octet-stream, and there is no entry in the mime.types to override this, xsl and xslt files are served with

content-type: application/octet-stream

This is not the correct mimetype. According to W3 docs <https://www.w3.org/TR/xslt20/#media-type-registration>, xsl and xslt files should now be served as

content-type: application/xslt+xml 

I would be happy to contribute a patch if there is agreement.

Change History (2)

comment:1 by Maxim Dounin, 14 months ago

Keywords: mime mime.types added
Type: defectenhancement

Note that nginx does not try to include all possible MIME types and corresponding extensions into the mime.types file as shipped with nginx. Instead, the file contains only MIME types sufficient for a typical web server. If you need some additional types, you can add types to the file you are using, or add additional types via a separate types directive.

As for xsl, xslt (and probably also dtd), it might make sense to add them, as these might be usable for sites doing XSLT-processing on the client. Not sure though (in particular, not sure if this use case is still valid).

Some quick facts:

  • In Apache mime.types, xsl is returned as application/xml, while xslt as application/xslt+xml.
  • There seems to be some compatibility issues with application/xslt+xml type, see here, and it might be the reason for the different type in Apache, needs checking.

Keeping this open for now.

comment:2 by apotek@…, 14 months ago

Thank you for your thoughtful reply. I based my suggested fix on the shipping /etc/mime.types in Debian/Ubuntu. On those OS's apache just sources /etc/mime.types for its mimetypes configuration.

head -2 /etc/os-release
NAME="Ubuntu"
VERSION="16.04.7 LTS (Xenial Xerus)"

grep xsl /etc/mime.types
application/xslt+xml xsl xslt

==================

head -1 /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"

grep xsl /etc/mime.types
application/xslt+xml xsl xslt

==================

Both of these server containers quoted run apache, which sources its mime-types from the OS /etc/mime.types, so these containers apache servers serve xsl as application/xslt+xml.

It's really too bad that the standard mimetype for xml, xsl, and xslt has meandered as much as it has. I still don't understand what was wrong with text/xml or text/xsl. Those are both fully honest descriptions of the content type. Let the client do what it will. Calling xsl an application has always struck me as odd.

In any case, back to the task at hand. Thank you again for responding so thoughtfully. I wanted to respond with some examples of shipping configurations in a major distribution to lend weight to my documentation.

I understand too though, that of course I can add these manually. In a containerized world, though, that requires writing extra steps in the Dockerfile, doing odd things with awk or sed and whatnot. It would just be easier if nginx was ready to go out of the box, or if it used the same mimetypes as the OS.

Note: See TracTickets for help on using tickets.