Impossibile scaricare file multimediali non immagine, i nomi originali dei file sono persi dopo il caricamento su S3

md-misko · 26 Maggio 2020, 5:00pm

I file multimediali non immagine residenti sull’archiviazione locale o quelli migrati su S3 utilizzando rake uploads:migrate_to_s3 vengono scaricati con i nomi originali quando si fa clic sul link di caricamento, mentre i file multimediali non immagine caricati direttamente su S3 vengono aperti in una nuova scheda e il nome originale viene perso.

rake uploads:migrate_to_s3 imposta content_disposition per tutti i caricamenti non immagine

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

mentre il caricamento su S3 imposta content_disposition solo per tutti i caricamenti non multimediali

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

La soluzione consiste nel sostituire is_supported_media con is_supported_image (testato e funzionante come previsto).

codinghorror · 28 Maggio 2020, 2:02am

Abbiamo bisogno di questa correzione, @sam?

sam · 28 Maggio 2020, 2:24am

forse @martin, secondo te questa modifica è corretta?

martin · 28 Maggio 2020, 3:03am

Penso che questa correzione sia corretta: lasciami testare le modifiche proposte sul mio ambiente locale e, se sembrano a posto, farò una PR.

martin · 28 Maggio 2020, 3:16am

Ripensandoci, credo che la soluzione sia esattamente il contrario: il task uploads:migrate_to_s3 dovrebbe essere condizionato da if !FileHelper.is_supported_media?(name). Non ha senso aggiungere l’intestazione content-disposition: attachment; filename=X per video e audio. Questi file vengono riprodotti in streaming all’interno di un post di Discourse, non scaricati, vero?

Quindi, ciò che dovremmo ottenere è:

Nessuna intestazione content-disposition attachment

Immagini
Video
Audio

Intestazione content-disposition attachment con il nome file originale

Tutti gli altri allegati/caricamenti (PDF, TXT, CSV, ecc.)

Se sto tralasciando qualcosa, sentiti libero di aggiungere ulteriori informazioni o esempi.

md-misko · 28 Maggio 2020, 8:43am

Credimi, ho passato giorni a capire questa cosa, e anche a me sembrava strano, ma impostare content-disposition: attachment; filename=X per tutti i file multimediali tranne le immagini imita perfettamente come i file multimediali vengono attualmente serviti dallo storage locale.

In breve, NO! Posso trasmetterli in streaming usando l’oneboxing se necessario, ma il link per il download diretto [media_file](percorso_file_media)—dove il percorso è locale o S3—dovrebbe scaricare il file usando il suo nome originale, esattamente come avviene sullo storage locale (e per i file migrati su S3).

Ma improvvisamente questo non è più possibile per i caricamenti diretti su S3: il link [media_file](percorso_S3_file_media) trasmette in streaming il file multimediale in una nuova scheda (non necessario, poiché è ciò che fa l’oneboxing), e quando si tenta di scaricarlo dai controlli del lettore multimediale, perde anche il nome originale.

Mi aspetto che i file ospitati localmente e su S3 si comportino allo stesso modo, d’accordo? Con la tua proposta, la funzionalità sarebbe completamente invertita per i caricamenti ospitati su S3, non solo per quelli nuovi ma anche per quelli migrati.

Ecco un caso dettagliato e il motivo per cui credo che la mia proposta sia corretta (cioè, mantiene la stessa funzionalità per i caricamenti ospitati sia localmente che su S3):

File ospitati localmente

Ho un repository grande (5k+) di file audio (parlato) che vanno da 1 a 10 MB, con un totale di circa 40 GB, che sono attualmente ospitati sullo storage locale e ora vengono trasferiti su S3 (questo è per design, non voglio che siano ospitati su un servizio di terze parti). Questo funziona già abbastanza bene dal punto di vista delle prestazioni, ma ora ha senso migrare su S3 a causa dell’aumento dei costi di archiviazione e dell’opzione di utilizzare un CDN con S3.

Questi file sono ottimizzati per le dimensioni e non sono destinati allo streaming, ma piuttosto al download e all’ascolto locale (per client con larghezza di banda/connettività limitata). I file vengono caricati in blocco e poi riferiti nel post grezzo utilizzando link generati dai rispettivi valori SHA1 usando: [dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3) e possono essere scaricati con il loro nome originale cliccando sul link diretto al file (vedi esempio qui).

Se, d’altra parte, questi link fossero oneboxed, potrebbero ancora essere trasmessi in streaming direttamente dal server Discourse (e anche scaricati dai controlli del lettore, ancora una volta con il nome originale).

File migrati su S3

Quando i caricamenti vengono migrati dallo storage locale a S3 usando uploads:migrate_to_s3, accadono due cose:

content-disposition: attachment; filename=X viene impostato per tutti i caricamenti tranne le immagini
i link locali diretti [dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3) nei post grezzi vengono sostituiti con link S3 [dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)

Questo imita i caricamenti ospitati localmente in ogni modo (link di download con nomi originali, nonché oneboxing).

File caricati di recente su S3

content-disposition: attachment; filename=X non viene impostato per tutti i file multimediali
i file caricati di recente sono riferiti usando un URL breve nel grezzo, ma i link cotti puntano ancora direttamente a https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3
cliccando sul link URL breve o sul link S3 inserito manualmente [dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3) il file si apre in una nuova scheda invece di essere scaricato.

Poiché content-disposition non è impostato, ora questo differisce da come i file multimediali sono serviti dallo storage locale (l’oneboxing funziona ancora, ma i link di download con i nomi originali non sono più disponibili).

Se hai bisogno di ulteriori informazioni, fammelo sapere.

martin · 29 Maggio 2020, 4:28am

È fantastico, grazie per aver fornito tutto quel contesto aggiuntivo. Ci giocherò un po’ e mi impegnerò a inviare una pull request la prossima settimana.

md-misko · 15 Giugno 2020, 4:09pm

C’è la possibilità che questo arrivi nella versione finale 2.5, che è prevista a breve?

martin · 15 Giugno 2020, 11:10pm

Per essere sincero, non ho approfondito ulteriormente la questione a causa di altri impegni urgenti. Ho ora riservato del tempo nel mio calendario per esaminarla adeguatamente questa settimana. La modifica sembra minima, quindi non dovrebbe richiedere molto tempo. Farò rapporto non appena la PR sarà completata.

martin · 17 Giugno 2020, 12:55am

@md-misko Ho confermato il tuo caso d’uso e, dopo aver corretto il content-disposition, riesco ancora a trasmettere audio e video correttamente. La correzione è in fase di build e dovrebbe essere unita entro la fine di oggi:

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.

Grazie per la pazienza!

martin · 20 Giugno 2020, 8:00am

Questo argomento è stato automaticamente chiuso dopo 3 giorni. Non sono più consentite nuove risposte.

Argomento		Risposte	Visualizzazioni
A bug when files were migrated to S3 Bug s3	0	47	Gennaio 13, 2025
Download links for .txt (and .yaml) attachments show raw text instead of dowload Support	1	29	Aprile 10, 2026
Broken pipe error when uploading to a S3 clone, a pdf with a name containing é,ï etc Bug	4	1128	Giugno 26, 2020
Attachment filename not set on download Support unsupported-install	5	2592	Febbraio 24, 2017
Broken Images and Their S3 URLs Support	33	4609	Settembre 30, 2020

Impossibile scaricare file multimediali non immagine, i nomi originali dei file sono persi dopo il caricamento su S3

File ospitati localmente

File migrati su S3

File caricati di recente su S3

Argomenti correlati