Believe me, I’ve spent days figuring this out, and it seemed strange to me too, but setting content-disposition: attachment; filename=X to all media files except images perfectly mimics how media files are currently served from local storage.
In brief, NO! I can stream them using oneboxing if needed, but direct download link [media_file](path_to_media_file)—where path is either local or S3—should download the file using its original filename the same way it does on local storage (and for files migrated to S3).
But this is suddenly not possible for direct uploads to S3: [media_file](S3_path_to_media_file) link streams the media file in new tab (not needed, as this is what oneboxing does), and when trying to download it from the media player controls it also loses its original filename.
I would expect that files hosted locally and on S3 should behave the same, agreed? With your proposal the functionality would be completely reversed for S3 hosted uploads, not only for new ones but for migrated ones as well.
Here is a detailed case file, and why I believe my proposal is correct (i.e. it retains the same functionality for uploads hosted both locally and on S3):
Files hosted locally
I have a large (5k+) repository of audio (speech) files ranging from 1–10MB, with sum total of ~40GB, which are currently hosted on local storage and are now being transferred to S3 (this is by design, I don’t want them hosted on 3rd party service). This already works quite well from the performance perspective, but it now makes sense to migrate to S3 because of the rising storage costs and the option to use CDN with S3.
These files are optimised for size and are not meant to be streamed, but rather downloaded and listened to locally (for clients with limited bandwidth/connectivity). Files are uploaded in bulk and then referenced in raw post using links generated from their respective SHA1 values using: [dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3) and can be downloaded using their original file name by clicking the direct link to the file (see example here).
If, on the other hand, this links were oneboxed they could still be streamed directly from the Discourse server (and also downloaded from the player controls, again with the original filename).
Files which were migrated to S3
When uploads are migrated from local storage to S3 using the uploads:migrate_to_s3 two things happen:
content-disposition: attachment; filename=X is set for all uploads except for images- direct local links
[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3) in raw posts are replaced with S3 links [dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)
This mimics the locally hosted uploads in every way (download links with original filenames as well as oneboxing).
Files newly uploaded to S3
content-disposition: attachment; filename=X is not set for all media files- newly uploaded files are referenced using short-url in raw, but cooked links still point directly to
https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3
- clicking the short-url link or the manually inserted S3 link
[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3) opens the file in new tab instead of downloading it.
Because content-disposition is not set this now differs from how media files are served from local storage (oneboxing still works, but the download links with original filenames are not available any more).
If you need any additional info please let me know.