Glaub mir, ich habe Tage damit verbracht, das herauszufinden, und es kam mir auch seltsam vor. Aber das Setzen von content-disposition: attachment; filename=X für alle Mediendateien außer Bildern imitiert perfekt, wie Mediendateien derzeit aus dem lokalen Speicher bereitgestellt werden.
Kurz gesagt: NEIN! Ich kann sie bei Bedarf über Oneboxing streamen, aber der direkte Download-Link [media_file](path_to_media_file) – wobei der Pfad entweder lokal oder S3 ist – sollte die Datei mit ihrem Originaldateinamen herunterladen, genau wie bei lokaler Speicherung (und für Dateien, die zu S3 migriert wurden).
Dies ist jedoch plötzlich für direkte Uploads zu S3 nicht mehr möglich: Der Link [media_file](S3_path_to_media_file) streamt die Mediendatei in einem neuen Tab (nicht erforderlich, da dies genau das ist, was Oneboxing tut), und beim Versuch, sie über die Steuerelemente des Media-Players herunterzuladen, geht auch der Originaldateiname verloren.
Ich erwarte, dass Dateien, die lokal und auf S3 gehostet werden, sich gleich verhalten, oder? Mit deinem Vorschlag würde die Funktionalität für auf S3 gehostete Uploads vollständig umgekehrt werden, nicht nur für neue, sondern auch für migrierte Dateien.
Hier ist ein detaillierter Fallbericht, und warum ich glaube, dass mein Vorschlag korrekt ist (d. h. er behält die gleiche Funktionalität für Uploads bei, die sowohl lokal als auch auf S3 gehostet werden):
Lokal gehostete Dateien
Ich habe ein großes Repository mit über 5.000 Audiodateien (Sprache) im Bereich von 1–10 MB, mit einer Gesamtgröße von ca. 40 GB, die derzeit im lokalen Speicher gehostet werden und nun zu S3 übertragen werden (dies ist beabsichtigt, ich möchte nicht, dass sie bei einem Drittanbieter gehostet werden). Dies funktioniert bereits aus Leistungssicht ziemlich gut, aber aufgrund der steigenden Speicherkosten und der Möglichkeit, ein CDN mit S3 zu nutzen, macht es nun Sinn, auf S3 zu migrieren.
Diese Dateien sind auf Größe optimiert und sollen nicht gestreamt, sondern heruntergeladen und lokal angehört werden (für Clients mit begrenzter Bandbreite/Konnektivität). Dateien werden im Bulk-Verfahren hochgeladen und dann in rohen Beiträgen über Links referenziert, die aus ihren jeweiligen SHA1-Werten generiert werden: [dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3), und können durch Klicken auf den direkten Link zur Datei mit ihrem Originaldateinamen heruntergeladen werden (siehe Beispiel hier).
Wenn diese Links hingegen geoneboxed wären, könnten sie direkt vom Discourse-Server gestreamt werden (und ebenfalls über die Player-Steuerelemente heruntergeladen werden, wiederum mit dem Originaldateinamen).
Zu S3 migrierte Dateien
Wenn Uploads mit uploads:migrate_to_s3 vom lokalen Speicher zu S3 migriert werden, passieren zwei Dinge:
content-disposition: attachment; filename=Xwird für alle Uploads außer Bildern gesetzt.- Direkte lokale Links
[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3)in rohen Beiträgen werden durch S3-Links[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)ersetzt.
Dies imitiert lokal gehostete Uploads in jeder Hinsicht (Download-Links mit Originaldateinamen sowie Oneboxing).
Neu zu S3 hochgeladene Dateien
content-disposition: attachment; filename=Xwird nicht für alle Mediendateien gesetzt.- Neu hochgeladene Dateien werden in rohen Beiträgen über eine Short-URL referenziert, aber die gekochten Links zeigen immer noch direkt auf
https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3. - Das Klicken auf den Short-URL-Link oder den manuell eingefügten S3-Link
[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)öffnet die Datei in einem neuen Tab, anstatt sie herunterzuladen.
Da content-disposition nicht gesetzt ist, unterscheidet sich dies nun von der Art und Weise, wie Mediendateien aus dem lokalen Speicher bereitgestellt werden (Oneboxing funktioniert weiterhin, aber Download-Links mit Originaldateinamen sind nicht mehr verfügbar).
Wenn du weitere Informationen benötigst, lass es mich bitte wissen.