Nicht-Bilddateien können nicht heruntergeladen werden; ursprüngliche Dateinamen gehen beim Hochladen nach S3 verloren

md-misko · 26. Mai 2020 um 17:00

Nicht-Bild-Mediendateien, die sich im lokalen Speicher befinden oder mithilfe von rake uploads:migrate_to_s3 nach S3 migriert wurden, werden beim Klicken auf den Upload-Link mit dem ursprünglichen Dateinamen heruntergeladen. Nicht-Bild-Mediendateien, die direkt nach S3 hochgeladen werden, hingegen werden in einem neuen Tab geöffnet, wobei der ursprüngliche Dateiname verloren geht.

rake uploads:migrate_to_s3 setzt content_disposition für alle Nicht-Bild-Uploads

github.com/discourse/discourse

lib/file_store/to_s3_migration.rb

666823d4b


      
          end
          
          options = {
            acl: "public-read",
            body: File.open(path, "rb"),
            bucket: bucket,
            content_type: MiniMime.lookup_by_filename(name)&.content_type,
            key: key,
          }
          
          if !FileHelper.is_supported_image?(name)
            upload = Upload.find_by(url: "/#{file}")
          
            if upload&.original_filename
              options[:content_disposition] =
                %Q{attachment; filename="#{upload.original_filename}"}
            end
          
            if upload&.secure
              options[:acl] = "private"
            end

während das Hochladen nach S3 content_disposition nur für alle Nicht-Medien-Uploads setzt

github.com/discourse/discourse

lib/file_store/s3_store.rb

d9a02d133


      
          
            filename = opts[:filename].presence || File.basename(path)
            # cache file locally when needed
            cache_file(file, File.basename(path)) if opts[:cache_locally]
            options = {
              acl: opts[:private_acl] ? "private" : "public-read",
              cache_control: 'max-age=31556952, public, immutable',
              content_type: opts[:content_type].presence || MiniMime.lookup_by_filename(filename)&.content_type
            }
            # add a "content disposition" header for "attachments"
            options[:content_disposition] = "attachment; filename=\"#{filename}\"" unless FileHelper.is_supported_media?(filename)
          
            path.prepend(File.join(upload_path, "/")) if Rails.configuration.multisite
          
            # if this fails, it will throw an exception
            path, etag = @s3_helper.upload(file, path, options)
          
            # return the upload url and etag
            [File.join(absolute_base_url, path), etag]
          end

Die Lösung besteht darin, is_supported_media durch is_supported_image zu ersetzen (getestet und funktioniert wie erwartet).

codinghorror · 28. Mai 2020 um 02:02

Brauchen wir diese Korrektur @sam?

sam · 28. Mai 2020 um 02:24

Vielleicht, @martin, was denkst du, ist diese Änderung korrekt?

martin · 28. Mai 2020 um 03:03

Ich denke, diese Korrektur klingt richtig – lass mich deine vorgeschlagenen Änderungen lokal testen, und wenn alles in Ordnung aussieht, werde ich einen PR erstellen.

martin · 28. Mai 2020 um 03:16

Wenn ich mir das noch einmal ansehe, denke ich, dass die Lösung genau umgekehrt ist – die Aufgabe uploads:migrate_to_s3 sollte if !FileHelper.is_supported_media?(name) lauten. Es ergibt keinen Sinn, bei Videos und Audiodateien den Header content-disposition: attachment; filename=X zu setzen. Diese Dateien werden doch innerhalb eines Discourse-Beitrags gestreamt, nicht heruntergeladen, oder?

Also wäre das gewünschte Verhalten:

Kein Header content-disposition: attachment

Bilder
Videos
Audiodateien

Header content-disposition: attachment mit Originaldateiname

Alle anderen Anhänge/Uploads (PDF, TXT, CSV usw.)

Falls ich etwas übersehe, fügen Sie gerne weitere Informationen oder Beispiele hinzu.

md-misko · 28. Mai 2020 um 08:43

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=X wird 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=X wird 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.

martin · 29. Mai 2020 um 04:28

Das ist toll, vielen Dank für den zusätzlichen Kontext. Ich werde mich damit auseinandersetzen und versuchen, nächste Woche einen PR einzureichen.

md-misko · 15. Juni 2020 um 16:09

Gibt es eine Chance, dass dies noch in die finale Version 2.5 aufgenommen wird, die bald erscheint?

martin · 15. Juni 2020 um 23:10

Um ehrlich zu sein, habe ich mich aufgrund anderer dringender Arbeiten bisher nicht weiter damit befasst. Ich habe mir jetzt etwas Zeit in meinem Kalender freigemacht, um diese Woche einen gründlichen Blick darauf zu werfen. Die Änderung scheint geringfügig zu sein, daher sollte es nicht lange dauern. Ich melde mich, sobald der PR abgeschlossen ist.

martin · 17. Juni 2020 um 00:55

@md-misko Ich habe deinen Use Case bestätigt, und nachdem ich den Content-Disposition-Header korrigiert habe, kann ich Audio und Video weiterhin korrekt streamen. Der Fix wird derzeit gebaut und sollte bis Ende des Tages gemerged werden:

github.com/discourse/discourse

FIX: Add attachment content-disposition for all non-image files (#10058)

master ← issue/add-attachment-content-disposition-for-all-non-image-uploads

merged 01:16AM - 17 Jun 20 UTC

martin-brennan

+60 -4

This will make it so the original filename is used when downloading all non-imag…e files, bringing S3Store into line with the to_s3 migration and local storage. Video and audio files will still stream correctly in HTML players as well. See https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797 for a lot of extra context.

Danke für deine Geduld!

martin · 20. Juni 2020 um 08:00

Dieses Thema wurde automatisch nach 3 Tagen geschlossen. Neue Antworten sind nicht mehr möglich.

Thema		Antworten	Aufrufe
A bug when files were migrated to S3 Bug s3	0	47	13. Januar 2025
Download links for .txt (and .yaml) attachments show raw text instead of dowload Support	1	30	10. April 2026
Broken pipe error when uploading to a S3 clone, a pdf with a name containing é,ï etc Bug	4	1128	26. Juni 2020
Attachment filename not set on download Support unsupported-install	5	2592	24. Februar 2017
Broken Images and Their S3 URLs Support	33	4610	30. September 2020

Nicht-Bilddateien können nicht heruntergeladen werden; ursprüngliche Dateinamen gehen beim Hochladen nach S3 verloren

Lokal gehostete Dateien

Zu S3 migrierte Dateien

Neu zu S3 hochgeladene Dateien

Verwandte Themen