La correction consiste à remplacer `is_supported_media` par `is_supported_image` (testé et fonctionnel comme prévu).
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [Mai 28, 2020, 2:02 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/2 "2020-05-28T02:02:56Z")
Avons-nous besoin de ce correctif @sam ?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Mai 28, 2020, 2:24 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/3 "2020-05-28T02:24:14Z")
C’est peut-être @martin, qu’en penses-tu ? Cette modification est-elle correcte ?
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Mai 28, 2020, 3:03 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/4 "2020-05-28T03:03:45Z")
Je _pense_ que cette correction semble correcte — laissez-moi tester vos modifications proposées localement et si tout semble bon, je ferai une PR.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Mai 28, 2020, 3:16 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/6 "2020-05-28T03:16:01Z")
En y repensant, je pense que la solution est l’inverse : la tâche `uploads:migrate_to_s3` devrait être conditionnée par `if !FileHelper.is_supported_media?(name)`. Il n’a pas de sens d’ajouter l’en-tête `content-disposition: attachment; filename=X` pour les vidéos et les fichiers audio. Vous diffusez ces fichiers directement dans un message Discourse, vous ne les téléchargez pas ?
Donc, ce que nous voudrions, c’est :
**Aucun en-tête content-disposition attachment**
- Image
- Vidéo
- Audio
**En-tête content-disposition attachment avec le nom d’origine**
- Tous les autres fichiers joints/téléchargements (PDF, TXT, CSV, etc.)
Si je passe à côté de quelque chose, n’hésitez pas à ajouter plus d’informations ou d’exemples.
---
### Author:  [@md-misko](https://meta.discourse.org/u/md-misko)
#### Post date: [Mai 28, 2020, 8:43 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/7 "2020-05-28T08:43:11Z")
> [@martin](#):
>
> En y repensant, je pense que la solution devrait être inversée : la tâche `uploads:migrate_to_s3` devrait inclure la condition `if !FileHelper.is_supported_media?(name)`. Il n’a pas de sens d’ajouter l’en-tête `content-disposition: attachment; filename=X` aux vidéos et aux fichiers audio.
Croyez-moi, j’ai passé des jours à élucider ce problème, et cela m’a semblé étrange aussi. Cependant, définir `content-disposition: attachment; filename=X` pour tous les fichiers multimédias _sauf_ les images _imite parfaitement_ la façon dont les fichiers multimédias sont actuellement servis depuis le _stockage local_.
> [@martin](#):
>
> Vous diffusez ces fichiers depuis un message Discourse, vous ne les téléchargez pas ?
En bref, NON ! Je peux les diffuser via une onebox si nécessaire, mais le lien de téléchargement direct `[media_file](chemin_vers_fichier_média)` — où le chemin est soit local, soit S3 — devrait _télécharger_ le fichier en conservant son _nom d’origine_, exactement comme cela se passe avec le stockage local (et pour les fichiers _migrés_ vers S3).
Or, cela n’est soudainement plus possible pour les téléversements directs vers S3 : le lien `[media_file](chemin_S3_vers_fichier_média)` diffuse le fichier multimédia dans un nouvel onglet (ce qui n’est pas nécessaire, car c’est ce que fait la onebox), et lorsqu’on tente de le télécharger depuis les contrôles du lecteur, il perd également son nom d’origine.
Je m’attendrais à ce que les fichiers hébergés localement et sur S3 se comportent de la même manière, n’est-ce pas ? Avec votre proposition, la fonctionnalité serait complètement inversée pour les téléversements hébergés sur S3, non seulement pour les nouveaux, mais aussi pour ceux qui ont été migrés.
> [@martin](#):
>
> Si je passe à côté de quelque chose, n’hésitez pas à ajouter plus d’informations ou d’exemples.
Voici un dossier détaillé expliquant pourquoi je pense que ma proposition est correcte (c’est-à-dire qu’elle conserve la même fonctionnalité pour les téléversements hébergés localement et sur S3) :
### Fichiers hébergés localement
Je possède un vaste dépôt de plus de 5 000 fichiers audio (discours) allant de 1 à 10 Mo, pour un total d’environ 40 Go, qui sont actuellement hébergés sur le stockage local et sont en cours de transfert vers S3 (c’est intentionnel, je ne souhaite pas qu’ils soient hébergés sur un service tiers). Cela fonctionne déjà très bien en termes de performances, mais il est maintenant logique de migrer vers S3 en raison de la hausse des coûts de stockage et de la possibilité d’utiliser un CDN avec S3.
Ces fichiers sont optimisés pour leur _taille_ et ne sont pas destinés à être diffusés, mais plutôt téléchargés et écoutés localement (pour les clients ayant une bande passante ou une connectivité limitée). Les fichiers sont téléversés en masse, puis référencés dans le message brut à l’aide de liens générés à partir de leurs valeurs SHA1 respectives, via : `[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3)`. Ils peuvent être téléchargés en conservant leur _nom d’origine_ en cliquant sur le lien direct vers le fichier (voir l’exemple [ici](https://discourse.suttacentral.net/t/bhante-sujato-metta-meditation-retreat-2019/15951)).
Si, en revanche, ces liens étaient _oneboxed_, ils pourraient toujours être diffusés directement depuis le serveur Discourse (et également téléchargés depuis les contrôles du lecteur, toujours avec le nom d’origine).
### Fichiers migrés vers S3
Lorsque les téléversements sont migrés du stockage local vers S3 à l’aide de la commande `uploads:migrate_to_s3`, deux choses se produisent :
- `content-disposition: attachment; filename=X` est défini pour tous les téléversements _sauf_ les images
- les liens locaux directs `[dl_link](https://discourse.forum.tld/uploads/default/original/3X/0/1/0123..sha1.mp3)` dans les messages bruts sont remplacés par des liens S3 `[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)`
Cela imite à tous égards les téléversements hébergés localement (liens de téléchargement avec noms d’origine, ainsi que la onebox).
### Fichiers nouvellement téléversés sur S3
- `content-disposition: attachment; filename=X` n’est **pas** défini pour tous les fichiers multimédias
- les fichiers nouvellement téléversés sont référencés par une URL courte dans le texte brut, mais les liens cuisinés pointent toujours directement vers `https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3`
- cliquer sur le lien d’URL courte ou sur le lien S3 inséré manuellement `[dl_link](https://cdn_url/uploads/original/3X/0/1/0123..sha1.mp3)` ouvre le fichier dans un nouvel onglet au lieu de le télécharger.
Comme `content-disposition` n’est pas défini, cela diffère désormais de la façon dont les fichiers multimédias sont servis depuis le stockage local (la onebox fonctionne toujours, mais les liens de téléchargement avec les noms d’origine ne sont plus disponibles).
Si vous avez besoin d’informations supplémentaires, n’hésitez pas à me le faire savoir.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Mai 29, 2020, 4:28 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/9 "2020-05-29T04:28:21Z")
C’est super, merci d’avoir fourni tout ce contexte supplémentaire. Je vais tester cela et viser à soumettre une PR la semaine prochaine.
---
### Author:  [@md-misko](https://meta.discourse.org/u/md-misko)
#### Post date: [Juin 15, 2020, 4:09 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/10 "2020-06-15T16:09:35Z")
> [@martin](#):
>
> Je vais essayer cela et prévoir de soumettre une PR la semaine prochaine.
Y a-t-il une chance que cela soit intégré dans la version finale 2.5 qui arrive bientôt ?
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juin 15, 2020, 11:10 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/11 "2020-06-15T23:10:43Z")
Pour être honnête, je n’ai pas approfondi ce sujet en raison d’autres priorités urgentes. J’ai maintenant réservé du temps dans mon emploi du temps pour examiner cela correctement cette semaine. Le changement semble mineur, donc cela ne devrait pas prendre longtemps. Je ferai un retour dès que la PR sera terminée.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juin 17, 2020, 12:55 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/12 "2020-06-17T00:55:30Z")
@md-misko J’ai confirmé votre cas d’usage et, après avoir corrigé le content-disposition, je peux toujours diffuser correctement l’audio et la vidéo. La correction est en cours de compilation et devrait être fusionnée d’ici la fin de la journée :
>
>
> 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.
Merci de votre patience !
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [Juin 20, 2020, 8:00 UTC](https://meta.discourse.org/t/cannot-download-non-image-media-files-original-filenames-lost-when-uploaded-to-s3/152797/13 "2020-06-20T08:00:01Z")
Ce sujet a été automatiquement fermé après 3 jours. De nouvelles réponses ne sont plus autorisées.