Types MIME incorrects (en-tête Content-Type) pour mp4 et js

Bonjour !

Je viens de remarquer que Discourse attribue des en-têtes Content-type incorrects à plusieurs types de fichiers :
les fichiers mp4 de /uploads/ ont le content-type : application/mp4 au lieu de video/mp4
mes téléchargements proviennent de S3, c’est donc au fournisseur d’hébergement S3.

Certains fichiers JavaScript (.js) par exemple de /brotli_asset/ ont le type application/javascript au lieu de text/javascript.

J’utilise discourse_docker sans aucune modification, j’ai vérifié le nginx inclus, il contient le fichier de configuration correct des types MIME. Il semble que ce soit le backend de Discourse qui est coupable de l’envoi de ces types MIME incorrects.

Bonjour ! Pour autant que j’aie compris, le problème avec les téléchargements venait de mon côté et était causé par le fournisseur S3 (je l’ai résolu avec succès en remplaçant le paramètre dans mon nginx). Et le problème avec le JS de /brotli_asset/ se situe quelque part dans le nginx “interne” de Discourse, donc cela semble être un bug dans discourse_docker.
Honte à moi, mais je n’ai pas réussi à trouver un meilleur endroit pour signaler un bug que cette partie du forum. Pouvez-vous m’indiquer s’il vous plaît ?

C’est le bon endroit, vous l’avez bien trouvé.

Pouvez-vous expliquer pourquoi c’est un problème qui devrait nous préoccuper ? Est-ce que cela casse quelque chose ?

En bref, Discourse envoie du JavaScript depuis différents emplacements avec différents types MIME. Par exemple, /theme-javascripts/ff3c633d0d4192c83a194066eaa9d823b5c2d8f6.js est envoyé avec text/javascript (correct) et /brotli_asset/... mentionné précédemment avec application/javascript. Cela peut prêter à confusion pour les serveurs proxy entre Discourse et le client, ainsi que pour les systèmes d’analyse, où j’ai remarqué le problème.

Il semble que vous ayez juste besoin de configurer correctement Nginx en interne dans l’image Docker de Discourse pour les ressources brotli.

Pouvez-vous nommer le système proxy / analytique qui a été brisé à cause de cela ? Partagez un exemple du problème qui se produit dans la nature ?

Dans le tableau de bord des types MIME de mes rapports goaccess pour Discourse, les valeurs de js sont divisées : une pour text/javascript et une autre pour application/javascript.
La seconde : les directives gzip_types et brotli_types dans nginx sont toutes deux gérées par les types MIME. Ainsi, pour Discourse, les gens doivent configurer à la fois le bon text/javascript et le mauvais application/javascript.
Il en va de même pour tout proxy qui recompresse le contenu en se basant sur le type MIME.

Je fais remonter ce sujet car je pense qu’il crée un petit problème, ou du moins un comportement indésirable.

Ouvrir un fichier vidéo hébergé sur Discourse force le téléchargement de la vidéo au lieu de la lire dans le navigateur.

Clic droit, copier l’adresse de la vidéo, coller le lien dans la barre d’adresse du navigateur.

La chose étrange est que sur une installation de développement locale, la vidéo est correctement lue dans le navigateur :

Lors du chargement de l’URL de la vidéo, les en-têtes sont différents entre une installation normale et une installation de développement.

Sur l’installation de production normale, le type de contenu de la vidéo est défini sur application/mp4, alors qu’il est défini sur video/mp4 sur une installation de développement.

Crossposting Discourse send PDF inline car l’auteur a corrigé un comportement indésirable similaire avec les PDF.

Je suis tout ouïe si quelqu’un a une solution pour empêcher les mp4 d’être téléchargés de force.

4 « J'aime »

Ah, bonne trouvaille - c’est étrange.

Il semble que MiniMime (une bibliothèque que nous utilisons et possédons) pourrait retourner ces valeurs

pry(main)> MiniMime.lookup_by_filename("a.mp4").content_type
=> "application/mp4"

Je vais créer une PR et nous discuterons si cela pose problème de les modifier.

5 « J'aime »

Juste une petite mise à jour -

Le ext_mime_db ci-dessus que nous utilisons suit les types de médias IANA définis ici - https://www.iana.org/assignments/media-types/media-types.xhtml. Malheureusement, cela signifie que mp4 est correctement application/mp4 :sweat_smile:


Cependant, en examinant plus en détail notre implémentation de l’upload S3, je vois que nous ajoutons l’en-tête Content-Disposition "attachment" pour à peu près tous les uploads qui ne sont pas des images, mais il semble que cela n’était prévu que pour les svgs. L’utilisation de "attachment" entraînerait le téléchargement du contenu plutôt que son ouverture dans un nouvel onglet. Pour les vidéos, c’est un mélange de application/video et attachment qui en est la cause.

Nous pouvons au moins supprimer cet en-tête, je pense.

2 « J'aime »

Je ne suis pas sûr de bien comprendre, donc une question rapide à propos de cette PR :person_raising_hand:

Pourquoi les modifications ciblent-elles spécifiquement les fichiers liés à s3, alors que le téléchargement forcé se produit même lorsque s3 n’est pas utilisé ? :thinking:

Cela résoudra-t-il le problème en général de toute façon ?
Cela résoudra-t-il également le téléchargement forcé pour d’autres fichiers qui pourraient être ouverts dans le navigateur, tels que les PDF ?

Lors du téléchargement vers S3, nous devons spécifier des en-têtes tels que la Content-Disposition et le Content-Type du fichier. Ce sont les valeurs qui seront retournées lors du chargement du fichier - PutObject - Amazon Simple Storage Service

Pouvez-vous expliquer quand cela se produit ?

La PR supprimera l’en-tête Content-Disposition: attachment qui force le téléchargement quel que soit le navigateur que vous utilisez.

Une fois que vous aurez mis à jour votre site, le Content-Type sera utilisé à la place, et le navigateur décidera quoi en faire. Une chose à noter, il n’y a pas de problème avec Content-Type: application/mp4 sur Safari et Firefox, mais sur Chrome, cela force toujours un téléchargement (probablement en raison d’une mauvaise historique que Chrome a avec le type de fichier mp4).

2 « J'aime »