こんにちは！
Discourse がいくつかのファイルの種類に対して誤った Content-Type ヘッダーを設定していることに気づきました。
/uploads/ の mp4 ファイルは video/mp4 の代わりに content-type: application/mp4 で送信されます
私のアップロードは S3 から行われたため、S3 ホスティングプロバイダー次第です。
一部の JavaScript (.js) ファイル（例: /brotli_asset/ のもの）は text/javascript の代わりに application/javascript で送信されます。
私は Discourse_docker を変更なしで使用しています。含まれている nginx を確認しましたが、正しい mime-types 設定ファイルが含まれています。これは、この誤った mime-types を送信しているのが Discourse のバックエンドであるように思われます。
こんにちは！アップロードに関する問題は、私の側でS3プロバイダーによって引き起こされていたものでした（nginxの設定を上書きすることで正常に解決しました）。そして、/brotli_asset/からのJSの問題は、Discourseの「内部」nginxのどこかにあるようです。そのため、discourse_dockerのバグのようです。
恥ずかしながら、フォーラムのこの部分よりも良いバグ報告の場所を見つけることができませんでした。教えていただけますか？
ここが正しい場所です。見つけられましたね。
なぜこれが私たちが気にかけるべき問題なのでしょうか？ 何か壊れますか？
要するに、ディスコースは異なる場所から異なるMIMEタイプでJavaScriptを送信します。例えば、/theme-javascripts/ff3c633d0d4192c83a194066eaa9d823b5c2d8f6.js は text/javascript (正しい) で送信され、以前言及した /brotli_asset/... は application/javascript で送信されます。これは、ディスコースとクライアント間のプロキシサーバーや、問題に気づいた分析システムを混乱させる可能性があります。
ディスコースのDockerイメージ内の内部Nginxを、brotliアセット用に正しく設定するだけで良いようです。
このせいで壊れたプロキシ/分析システムの名前を教えていただけますか？実際に問題が発生している例を共有していただけますか？
GoAccess レポートの Discourse の Mime-Types ダッシュボードで、js が text/javascript と application/javascript の 2 つの値に分割されています。
2 番目の値について: nginx の gzip_types と brotli_types の両方のディレクティブは、Mime-Types によって操作されます。そのため、Discourse では text/javascript と不正確な application/javascript の両方を正しく設定する必要があります。
Mime-Type に基づいてコンテンツを再圧縮するプロキシでも同様です。
このトピックを再度取り上げます。これは小さな問題、または少なくとも望ましくない動作を引き起こす可能性があると考えています。
Discourseでホストされているビデオファイルを開くと、ブラウザで再生されるのではなく、ビデオのダウンロードが強制されます。
右クリックしてビデオアドレスをコピーし、ブラウザのアドレスバーにリンクを貼り付けます。
奇妙なことに、ローカル開発環境では、ブラウザでビデオが正しく再生されます。
ビデオURLを読み込むと、通常のインストールと開発インストールでヘッダーが異なります。
通常の本番環境のインストールでは、ビデオのcontent typeはapplication/mp4に設定されていますが、開発環境のインストールではvideo/mp4に設定されています。
PDFに関する同様の望ましくない動作を修正したDiscourse send PDF inline
mp4が強制的にダウンロードされるのを防ぐ方法があれば、ぜひ教えてください。
おお、良い発見ですね。これは奇妙です。
使用しているライブラリであるMiniMime（当社所有）がこれらの値を返している可能性があります。
pry(main)> MiniMime.lookup_by_filename("a.mp4").content_type
=> "application/mp4"
PRを作成し、これらの値を変更することが問題かどうかを議論します。
ちょっとしたアップデートです。
上記で使用している ext_mime_db は、こちらで定義されている IANA Media Types に従っています - https://www.iana.org/assignments/media-types/media-types.xhtml。残念ながら、これは mp4 が正しくは application/mp4 であることを意味します 
ただし、S3アップローダーの実装をさらに詳しく見ると、画像ではないほぼすべてのアップロードに対して Content-Disposition ヘッダー \"attachment\" を追加していることがわかりますが、これはSVGに対してのみ追加されることを意図していたようです。\"attachment\" を使用すると、コンテンツは新しいタブで開かれるのではなくダウンロードされます。動画の場合、application/video と attachment の両方が混在していることが原因です。
少なくともこのヘッダーは削除できると思います。
よく理解できていないので、このPRについて簡単な質問があります 
S3を使用していない場合でも強制ダウンロードが発生するのに、なぜ変更は specifically s3 関連のファイルのみを対象としているのですか？ 
いずれにしても、この問題は全体的に解決されますか？
ブラウザで開くことができるPDFなどの他のファイルに対する強制ダウンロードも解決されますか？
S3 にアップロードする際には、ファイルの Content-Disposition や Content-Type のようなヘッダーを指定する必要があります。これらは、ファイルをロードする際に返される値です - PutObject - Amazon Simple Storage Service
これがいつ発生するか説明していただけますか？
PR は、ダウンロードを強制する Content-Disposition: attachment ヘッダーを削除します。これにより、どのブラウザを使用してもダウンロードが強制されます。
サイトをアップグレードすると、代わりに Content-Type が使用され、ブラウザがそれに対して何を行うかを決定します。注意点として、Content-Type: application/mp4 は Safari および Firefox では問題ありませんが、Chrome では（おそらく Chrome が mp4 ファイルタイプに関して抱えている悪い履歴のため）ダウンロードが強制されます。
