Mime-type errati (intestazione content-type) per mp4 e js

Bug
1

Ciao!

Ho appena notato che Discourse sta inserendo intestazioni Content-type errate per diversi tipi di file:
i file mp4 da /uploads/ hanno content-type: application/mp4 invece di video/mp4
i miei caricamenti provenivano da S3, quindi dipende dal provider di hosting S3.

Alcuni file JavaScript (.js) ad esempio da /brotli_asset/ hanno application/javascript invece di text/javascript.

Utilizzo discourse_docker senza alcuna modifica, ho controllato nginx incluso, contiene il file di configurazione corretto per i mime-type. Sembra che sia il backend di Discourse il colpevole dell’invio di questi mime-type errati.

7

Ciao! Per quanto ne so, il problema con i caricamenti era da parte mia e causato dal provider S3 (l’ho risolto con successo sovrascrivendo l’impostazione nel mio nginx). E il problema con JS da /brotli_asset/ è da qualche parte nell’nginx “interno” di discourse, quindi sembra essere un bug in discourse_docker.
Mi vergogno, ma non sono riuscito a trovare un posto migliore per segnalare un bug di questa parte del forum. Potete indicarmi per favore?

10

Questo è il posto giusto, l’hai trovato correttamente.

Puoi spiegare perchÊ questo è un problema di cui dovremmo preoccuparci? Rompe qualcosa?

11

In poche parole, Discourse invia javascript da diverse posizioni con diversi mime-type. Ad esempio, /theme-javascripts/ff3c633d0d4192c83a194066eaa9d823b5c2d8f6.js viene inviato con text/javascript (corretto) e il suddetto /brotli_asset/… con application/javascript. Ciò può confondere i server proxy tra Discourse e il client, nonché i sistemi di analisi, dove ho notato il problema.

Sembra che tu debba solo configurare correttamente nginx interno nell’immagine Docker di Discourse per gli asset brotli.

12

Puoi nominare il sistema proxy/analitico che si è rotto a causa di questo? Condividi un esempio del problema che si verifica nel mondo reale?

13

Nei miei report di goaccess, la dashboard dei tipi MIME di discourse ha valori divisi per js: uno per text/javascript e un altro per application/javascript.
Il secondo: sia le direttive gzip_types che brotli_types in nginx sono gestite dai tipi MIME. Quindi, per discourse, le persone devono configurare sia il corretto text/javascript che l’errato application/javascript.
Lo stesso vale per qualsiasi proxy che ricomprime contenuti basati sul tipo MIME.

14

Sto riaprendo questo argomento perchĂŠ credo che crei un piccolo problema, o almeno un comportamento indesiderato.

Aprire un file video ospitato su Discourse forza il download del video invece di riprodurlo nel browser.

Fare clic con il pulsante destro del mouse, copiare l’indirizzo del video, incollare il collegamento nella barra degli indirizzi del browser.

La cosa strana è che su un’installazione di sviluppo locale, il video viene riprodotto correttamente nel browser:

L'immagine raffigura una vista satellitare della Terra con una cittĂ  visibile di notte, su uno sfondo celeste nero. (Sottotitolato dall'IA)
L'immagine raffigura una vista satellitare della Terra con una città visibile di notte, su uno sfondo celeste nero. (Sottotitolato dall'IA)2374×1256 135 KB

Quando si carica l’URL del video, gli header sono diversi tra un’installazione normale e un’installazione di sviluppo.

Sull’installazione di produzione normale, il tipo di contenuto del video è impostato su application/mp4, mentre è impostato su video/mp4 su un’installazione di sviluppo.

Crossposting Discourse send PDF inline perché l’autore ha risolto un comportamento indesiderato simile con i PDF.

Sono tutt’orecchi se qualcuno ha una soluzione per impedire il download forzato dei file mp4.

4 Mi Piace
15

Oh, buona scoperta, è strano.

Sembra che MiniMime (una libreria che usiamo e possediamo) possa restituire questi valori

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

Creerò una PR e discuteremo se è un problema modificarli.

5 Mi Piace
16

Solo un rapido aggiornamento -

L’ext_mime_db sopra che utilizziamo segue i tipi multimediali IANA definiti qui - https://www.iana.org/assignments/media-types/media-types.xhtml. Sfortunatamente, ciò significa che mp4 è correttamente application/mp4 :sweat_smile:

Screenshot 2025-01-03 at 12.51.40 AM
Screenshot 2025-01-03 at 12.51.40 AM1976×122 23.6 KB

Anche se, esaminando ulteriormente la nostra implementazione dell’uploader S3, vedo che stiamo aggiungendo l’intestazione Content-Disposition "attachment" per quasi tutti i caricamenti che non sono immagini, ma sembra che fosse inteso solo per gli svg. L’uso di "attachment" comporterebbe il download del contenuto anziché l’apertura in una nuova scheda. Per i video, è un mix di application/video e attachment che causa questo.

Possiamo almeno rimuovere questa intestazione, credo.

2 Mi Piace
17

Non sono sicuro di aver capito appieno, quindi una domanda veloce su questa PR :person_raising_hand:

PerchĂŠ le modifiche riguardano specificamente i file relativi a s3, quando il download forzato si verifica anche quando non si utilizza s3? :thinking:

Risolve comunque il problema in generale?
Risolve anche il download forzato per altri file che potrebbero essere aperti nel browser come i PDF?

18

Quando si carica su S3, dobbiamo specificare header come Content-Disposition e Content-Type del file. Questi sono i valori che verranno restituiti al caricamento del file - PutObject - Amazon Simple Storage Service

Puoi spiegare quando sta succedendo?

La PR rimuoverà l’header Content-Disposition: attachment che forza il download indipendentemente dal browser utilizzato.

Una volta aggiornato il tuo sito, verrà utilizzato invece Content-Type, e il browser deciderà cosa farne. Una cosa da notare, non c’è problema con Content-Type: application/mp4 su Safari e Firefox, ma su Chrome, forza ancora un download (probabilmente a causa di una cattiva storia che Chrome ha con il tipo di file mp4).

2 Mi Piace