Não é possível baixar arquivos de mídia não imagem; nomes originais perdidos ao fazer upload para o S3

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

Arquivos de mídia não-imageados armazenados localmente ou migrados para o S3 usando rake uploads:migrate_to_s3 são baixados com os nomes de arquivo originais ao clicar no link de upload, enquanto arquivos de mídia não-imageados enviados diretamente para o S3 são abertos em uma nova aba e o nome de arquivo original é perdido.

rake uploads:migrate_to_s3 define content_disposition para todas as não-imagens enviadas

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

enquanto o envio para o S3 define content_disposition para todas as não-mídias enviadas apenas

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

A correção é substituir is_supported_media por is_supported_image (testado e funcionando conforme o esperado).

codinghorror · Maio 28, 2020, 2:02am

Precisamos dessa correção, @sam?

sam · Maio 28, 2020, 2:24am

possivelmente @martin, você acha que essa mudança está correta?

martin · Maio 28, 2020, 3:03am

Acho que essa correção parece correta — deixe-me testar suas alterações propostas localmente e, se parecer tudo bem, farei um PR.

martin · Maio 28, 2020, 3:16am

Olhando isso novamente, acho que a solução é o contrário: a tarefa uploads:migrate_to_s3 deve ter a condição if !FileHelper.is_supported_media?(name). Não faz sentido adicionar o cabeçalho content-disposition: attachment; filename=X a vídeos e áudios. Você está transmitindo esses arquivos dentro de uma postagem do Discourse, não baixando-os?

Então, o que queremos é:

Sem cabeçalho content-disposition attachment

Imagem
Vídeo
Áudio

Com cabeçalho content-disposition attachment e nome de arquivo original

Todos os outros anexos/carregamentos (PDF, TXT, CSV, etc.)

Se eu não estiver vendo algo aqui, sinta-se à vontade para adicionar mais informações ou exemplos.

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

Acredite em mim, passei dias tentando resolver isso, e também me pareceu estranho, mas definir content-disposition: attachment; filename=X para todos os arquivos de mídia exceto imagens imita perfeitamente como os arquivos de mídia são atualmente servidos a partir do armazenamento local.

Em resumo, NÃO! Posso transmiti-los usando oneboxing se necessário, mas o link de download direto [media_file](path_to_media_file) — onde o caminho é local ou S3 — deve baixar o arquivo usando seu nome original, da mesma forma que funciona no armazenamento local (e para arquivos migrados para S3).

Mas isso de repente não é mais possível para uploads diretos no S3: o link [media_file](S3_path_to_media_file) transmite o arquivo de mídia em uma nova aba (não necessário, pois isso é o que o oneboxing faz), e ao tentar baixá-lo pelos controles do player de mídia, ele também perde seu nome original.

Eu esperaria que arquivos hospedados localmente e no S3 se comportassem da mesma forma, concorda? Com sua proposta, a funcionalidade seria completamente invertida para uploads hospedados no S3, não apenas para os novos, mas também para os migrados.

Aqui está um caso detalhado e por que acredito que minha proposta está correta (ou seja, ela mantém a mesma funcionalidade para uploads hospedados tanto localmente quanto no S3):

Arquivos hospedados localmente

Tenho um repositório grande (mais de 5 mil) de arquivos de áudio (fala) variando de 1 a 10 MB, com um total de ~40 GB, que atualmente estão hospedados no armazenamento local e agora estão sendo transferidos para o S3 (isso é por design, não quero que sejam hospedados em serviço de terceiros). Isso já funciona bastante bem do ponto de vista de desempenho, mas agora faz sentido migrar para o S3 devido aos custos crescentes de armazenamento e à opção de usar CDN com S3.

Esses arquivos são otimizados para tamanho e não são destinados a streaming, mas sim para download e reprodução local (para clientes com largura de banda/conectividade limitada). Os arquivos são enviados em lote e depois referenciados na postagem bruta usando links gerados a partir de seus respectivos valores SHA1, usando: [dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3) e podem ser baixados usando seu nome original ao clicar no link direto para o arquivo (veja o exemplo aqui).

Se, por outro lado, esses links fossem oneboxed, eles ainda poderiam ser transmitidos diretamente do servidor do Discourse (e também baixados pelos controles do player, novamente com o nome original).

Arquivos que foram migrados para o S3

Quando os uploads são migrados do armazenamento local para o S3 usando o uploads:migrate_to_s3, duas coisas acontecem:

content-disposition: attachment; filename=X é definido para todos os uploads exceto imagens
links locais diretos [dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3) em postagens brutas são substituídos por links S3 [dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)

Isso imita os uploads hospedados localmente em todos os aspectos (links de download com nomes originais de arquivo, bem como oneboxing).

Arquivos recém-enviados para o S3

content-disposition: attachment; filename=X não é definido para todos os arquivos de mídia
arquivos recém-enviados são referenciados usando URL curta na postagem bruta, mas os links renderizados ainda apontam diretamente para https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3
clicar no link de URL curta ou no link S3 inserido manualmente [dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3) abre o arquivo em uma nova aba em vez de baixá-lo.

Como content-disposition não é definido, isso agora difere de como os arquivos de mídia são servidos a partir do armazenamento local (oneboxing ainda funciona, mas os links de download com nomes originais de arquivo não estão mais disponíveis).

Se precisar de informações adicionais, por favor, me avise.

martin · Maio 29, 2020, 4:28am

Isso é ótimo, obrigado por fornecer todo esse contexto adicional. Vou experimentar com isso e tenho como objetivo abrir um PR na próxima semana.

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

Há alguma chance de isso entrar na versão final 2.5, que está prevista para breve?

martin · Junho 15, 2020, 11:10pm

Para ser honesto, não investiguei isso mais a fundo por causa de outras tarefas urgentes. Agora reservei um tempo na minha agenda para analisar isso direito esta semana. A mudança parece pequena, então não deve demorar. Darei um retorno assim que o PR estiver pronto.

martin · Junho 17, 2020, 12:55am

@md-misko Confirmei seu caso de uso e, após corrigir o content-disposition, ainda consigo transmitir áudio e vídeo corretamente. A correção está sendo compilada agora e deve ser mesclada até o final de hoje:

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.

Obrigado pela sua paciência!

martin · Junho 20, 2020, 8:00am

Este tópico foi automaticamente fechado após 3 dias. Novas respostas não são mais permitidas.

Tópico		Respostas	Visualizações
A bug when files were migrated to S3 Bug s3	0	47	13 de Janeiro de 2025
Download links for .txt (and .yaml) attachments show raw text instead of dowload Support	1	29	10 de Abril de 2026
Broken pipe error when uploading to a S3 clone, a pdf with a name containing é,ï etc Bug	4	1128	26 de Junho de 2020
Attachment filename not set on download Support unsupported-install	5	2592	24 de Fevereiro de 2017
Broken Images and Their S3 URLs Support	33	4609	30 de Setembro de 2020

Não é possível baixar arquivos de mídia não imagem; nomes originais perdidos ao fazer upload para o S3

Arquivos hospedados localmente

Arquivos que foram migrados para o S3

Arquivos recém-enviados para o S3

Tópicos relacionados