I’ve just noticed that discourse is putting incorrect Content-type) headers to several file types: mp4 files from /uploads/ goes with content-type: application/mp4 instead of video/mp4
my uploads went from S3 so it is up to the S3 hosting provider.
Some javascript (.js) e.g. from /brotli_asset/ goes with application/javascript instead of text/javascript .
I use discourse_docker without any modifications, I’ve checked included nginx, it contains correct mime-types configuration file. Seems that it’s discourse backend guilty of sending this incorrect mime-types.
Hello! As far as I have got the problem with uploads was on my side and caused by S3-provider (I have successfully resolved it by overriding the setting in my nginx). And the problem with JS from /brotli_asset/ is somewhere in “internal” nginx of the discourse, so seems to be bug in discourse_docker.
Shame on me, but I failed to find any place to report bug better than this part of the forum. Can you point me please?
In short words discourse sends javascript from different location with different mime-types. E.g. /theme-javascripts/ff3c633d0d4192c83a194066eaa9d823b5c2d8f6.js goes with text/javascript (correct) and previously mentioned /brotli_asset/… with application/javascript. It can confuse proxy servers between discourse and client so as analytic systems, where I have noticed the issue.
Seems you just need to correctly setup internal nginx in discourse docker image for brotli assets.
In my goaccess reports mime-types dashboard of discourse is splitted values for js: one for text/javascript and another for application/javascript.
The second one: both gzip_types and brotli_types directives in nginx are operated by mime-types. So for discourse people have to setup both correct text/javascript and incorrect application/javascript.
The same for any proxy recompressing content that bases on mime-type.