ローカルストレージに存在する画像以外のメディアファイル、または rake uploads:migrate_to_s3 を使用して S3 に移行された画像以外のメディアファイルは、アップロードリンクをクリックすると元のファイル名でダウンロードされます。一方、S3 に直接アップロードされた画像以外のメディアファイルは新しいタブで開かれ、元のファイル名は失われます。
rake uploads:migrate_to_s3 は、すべての画像以外のアップロードに対して content_disposition を設定します。
一方、S3 へのアップロードは、メディア以外のアップロードに対してのみ content_disposition を設定します。
修正方法は、is_supported_media を is_supported_image に置き換えることです（テスト済みで期待通りに動作します）。
この修正は必要ですか、@sam？
おそらく @martin さん、その変更は正しいと思いますか？
この修正は正しいと思います – ローカルで提案された変更をテストし、問題がなければ PR を作成します。
再度確認しましたが、解決策は逆ではないかと思います。uploads:migrate_to_s3 タスクは if !FileHelper.is_supported_media?(name) とすべきです。動画や音声に content-disposition: attachment; filename=X ヘッダーを設定するのは理にかなっていません。それらのファイルは Discourse の投稿内でストリーミング再生されるのであって、ダウンロードするものではないはずです。
したがって、以下のようにすべきです：
content-disposition attachment ヘッダーなし
元のファイル名付きの content-disposition attachment ヘッダーあり
何か見落としている場合は、追加の情報や例をご自由に追加してください。
信じてください、これには数日かけて調査しましたし、私にとっても奇妙に思えました。しかし、画像以外のすべてのメディアファイルに content-disposition: attachment; filename=X を設定することは、現在ローカルストレージから提供されているメディアファイルの動作を完全に模倣しています。
端的に言うと、いいえ！必要に応じてワンボックス機能を使ってストリーミングすることはできますが、直接のダウンロードリンク [media_file](path_to_media_file)（パスはローカルまたは S3 のどちらか）は、ローカルストレージの場合と同様に、元のファイル名を使用してファイルをダウンロードするはずです（S3 に移行されたファイルも含みます）。
しかし、S3 への直接アップロードではこれが突然不可能になっています。[media_file](S3_path_to_media_file) リンクはメディアファイルを新しいタブでストリーミングしてしまいます（これはワンボックス機能が行うことなので不要です）。また、メディアプレイヤーのコントロールからダウンロードを試みると、元のファイル名が失われてしまいます。
ローカルホストと S3 ホストのファイルは同じように動作するべきだと考えますが、同意されますか？あなたの提案では、S3 ホストのアップロード（新規のものだけでなく、移行されたものも含む）の機能が完全に逆転してしまいます。
以下に詳細なケーススタディと、なぜ私の提案が正しいのか（つまり、ローカルと S3 の両方でホストされているアップロードの機能を維持するものなのか）を説明します。
私は音声（スピーチ）ファイルの大容量（5,000 以上）のリポジトリを持っており、サイズは 1〜10MB、合計約 40GB です。これらは現在ローカルストレージにホストされていますが、S3 へ移行されています（これは設計上のもので、サードパーティのサービスにホストしたくありません）。パフォーマンスの観点からはすでに非常にうまく機能していますが、ストレージコストの上昇と S3 を使用した CDN の利用オプションにより、S3 への移行が理にかなっています。
これらのファイルはサイズ最適化されており、ストリーミング用ではなく、ダウンロードしてローカルで再生する（帯域幅や接続性が限られたクライアント向け）ことを想定しています。ファイルはバッチでアップロードされ、それぞれの SHA1 値から生成されたリンクを使用して生投稿内で参照されます：[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3)。ファイルへの直接リンクをクリックすることで、元のファイル名でダウンロードできます（例はこちらを参照：here）。
一方、これらのリンクがワンボックス化されている場合、Discourse サーバーから直接ストリーミングすることも可能です（プレイヤーコントロールからもダウンロード可能で、これも元のファイル名になります）。
ローカルストレージから S3 へアップロードを移行する際、uploads:migrate_to_s3 を実行すると以下の 2 点が行われます。
content-disposition: attachment; filename=X が設定される[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3) が S3 リンク [dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3) に置き換えられるこれにより、ダウンロードリンクに元のファイル名が含まれること、およびワンボックス機能などが、ローカルホストのアップロードと完全に同じように動作します。
content-disposition: attachment; filename=X が設定されないhttps://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3 を直接指す[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3) をクリックすると、ダウンロードではなく新しいタブでファイルが開いてしまうcontent-disposition が設定されていないため、これはローカルストレージから提供されるメディアファイルの動作と異なります（ワンボックス機能は依然として機能しますが、元のファイル名を持つダウンロードリンクはもう利用できません）。
追加情報が必要な場合はお知らせください。
それは素晴らしいですね、追加のコンテキストを提供してくださりありがとうございます。これでいろいろ試してみますし、来週中にプルリクエストを提出できるよう目指します。
まもなくリリース予定の最終版 2.5 にこの変更は含まれる見込みはありますか？
正直なところ、他の優先度の高い業務のせいで、これ以上調べていませんでした。今週は改めて詳しく確認する時間をスケジュールに確保しました。変更点は小さいようですので、それほど時間はかからないはずです。PR が完了し次第、改めて報告します。
@md-misko 使用ケースを確認し、content-disposition を修正した後も、オーディオとビデオを正常にストリーミングできることを確認しました。修正は現在ビルド中で、本日中にマージされる予定です。
ご辛抱いただき、ありがとうございます！
このトピックは 3 日後に自動的に閉鎖されました。新しい返信は受け付けられていません。