Falsche Mime-Typen (Content-Type-Header) für mp4 und js

[iprok (Ivan)]

Hallo!

Mir ist gerade aufgefallen, dass Discourse für mehrere Dateitypen falsche Content-Type-Header setzt:
mp4-Dateien von /uploads/ haben content-type: application/mp4 statt video/mp4
Meine Uploads kamen von S3, also liegt es am S3-Hosting-Anbieter.

Einige JavaScript-Dateien (.js) z. B. von /brotli_asset/ haben application/javascript statt text/javascript.

Ich verwende discourse_docker ohne Modifikationen. Ich habe das enthaltene Nginx überprüft, es enthält die korrekte Konfigurationsdatei für MIME-Typen. Es scheint, dass das Discourse-Backend für das Senden dieser falschen MIME-Typen verantwortlich ist.

[iprok (Ivan)]

Hallo! Soweit ich das Problem mit Uploads verstanden habe, lag es auf meiner Seite und wurde vom S3-Anbieter verursacht (ich habe es erfolgreich behoben, indem ich die Einstellung in meinem Nginx überschrieben habe). Und das Problem mit JS von /brotli_asset/ liegt irgendwo im „internen“ Nginx von Discourse, also scheint es ein Fehler in discourse_docker zu sein.
Schade für mich, aber ich konnte keinen besseren Ort finden, um einen Fehler zu melden, als diesen Teil des Forums. Können Sie mir bitte weiterhelfen?

[Falco]

@iprok

Schäme mich, aber ich konnte keinen besseren Ort finden, um einen Fehler zu melden, als diesen Teil des Forums. Können Sie mir bitte helfen?

Das ist der richtige Ort, Sie haben ihn richtig gefunden.

@iprok

Einige JavaScript-Dateien (.js), z. B. aus /brotli_asset/, werden mit application/javascript anstelle von text/javascript ausgeliefert.

Können Sie erklären, warum dies ein Problem ist, das uns Sorgen bereiten sollte? Bringt es etwas zum Absturz?

[iprok (Ivan)]

Kurz gesagt, Discourse sendet JavaScript von verschiedenen Orten mit unterschiedlichen MIME-Typen. Z.B. /theme-javascripts/ff3c633d0d4192c83a194066eaa9d823b5c2d8f6.js wird mit text/javascript (korrekt) gesendet und das zuvor erwähnte /brotli_asset/… mit application/javascript. Dies kann Proxy-Server zwischen Discourse und dem Client sowie Analysetools verwirren, wo ich das Problem bemerkt habe.

Es scheint, dass Sie nur den internen Nginx im Discourse-Docker-Image für Brotli-Assets korrekt einrichten müssen.

[Falco]

Können Sie das Proxy-/Analysesystem nennen, das dadurch kaputtgegangen ist? Teilen Sie ein Beispiel für das Problem in freier Wildbahn?

[iprok (Ivan)]

In meinen GoAccess-Berichten wird das Mime-Types-Dashboard von Discourse in JS in zwei Werte aufgeteilt: einen für text/javascript und einen für application/javascript.
Der zweite Wert: Sowohl die Direktiven gzip_types als auch brotli_types in Nginx werden von Mime-Types betrieben. Daher müssen Discourse-Benutzer sowohl das korrekte text/javascript als auch das inkorrekte application/javascript einrichten.
Dasselbe gilt für jeden Proxy, der Inhalte neu komprimiert und dabei auf Mime-Types basiert.

[Canapin (Coin-coin le Canapin)]

@iprok

mp4-Dateien von /uploads/ haben den Content-Type: application/mp4 anstelle von video/mp4

Ich pushe dieses Thema, da ich glaube, dass es ein kleines Problem oder zumindest ein unerwünschtes Verhalten verursacht.

Das Öffnen einer Videodatei, die auf Discourse gehostet wird, erzwingt den Download des Videos, anstatt es im Browser abzuspielen.

Rechtsklick, Videolink kopieren, den Link in die Adressleiste des Browsers einfügen.

Seltsamerweise spielt es unter einer lokalen Entwicklungsumgebung das Video ordnungsgemäß im Browser ab:

Beim Laden der Video-URL sind die Header zwischen einer regulären Installation und einer Entwicklungsinstallation unterschiedlich.

Bei der regulären Produktionsinstallation ist der Video-Content-Type auf application/mp4 gesetzt, während er bei einer Entwicklungsinstallation auf video/mp4 gesetzt ist.

Crossposting Discourse send PDF inline, da der Autor ein ähnliches unerwünschtes Verhalten bei PDFs behoben hat.

Ich bin ganz Ohr, wenn jemand eine Lösung hat, um zu verhindern, dass mp4s zwangsweise heruntergeladen werden.

[nat (Natalie T)]

@Canapin

Beim Laden der Video-URL sind die Header zwischen einer regulären Installation und einer Entwicklungsinstallation unterschiedlich.

Bei der regulären Produktionsinstallation ist der Video-Inhaltstyp auf application/mp4 gesetzt, während er bei einer Entwicklungsinstallation auf video/mp4 gesetzt ist.

Oh, gute Entdeckung – das ist seltsam.

Es sieht so aus, als ob MiniMime (eine Bibliothek, die wir verwenden und besitzen) diese Werte zurückgeben könnte

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

lib/db/ext_mime.db

Ich werde einen PR erstellen und wir werden besprechen, ob es ein Problem ist, diese zu ändern.

[nat (Natalie T)]

Nur ein kurzes Update –

Die oben genannte ext_mime_db, die wir verwenden, folgt den IANA Media Types, die hier definiert sind – https://www.iana.org/assignments/media-types/media-types.xhtml. Leider bedeutet dies, dass mp4 korrekt application/mp4 ist

---

Bei der weiteren Untersuchung unserer S3-Uploader-Implementierung stelle ich jedoch fest, dass wir für fast jeden Upload, der keine Bilddatei ist, den Content-Disposition-Header \"attachment\" hinzufügen, obwohl er anscheinend nur für SVGs gedacht war. Die Verwendung von \"attachment\" würde dazu führen, dass der Inhalt heruntergeladen und nicht in einem neuen Tab geöffnet wird. Bei Videos ist es eine Mischung aus application/video und attachment, die dies verursacht.

Wir können diesen Header zumindest entfernen, denke ich.

FIX: Allow attachments to be opened in a new tab instead of downloading them

[Canapin (Coin-coin le Canapin)]

Ich bin mir nicht sicher, ob ich das vollständig verstehe, daher eine kurze Frage zu diesem PR

Warum zielen die Änderungen speziell auf s3-bezogene Dateien ab, wenn der erzwungene Download auch dann erfolgt, wenn S3 nicht verwendet wird?

Wird das Problem dadurch generell behoben?
Wird dadurch auch der erzwungene Download für andere Dateien behoben, die im Browser geöffnet werden können, wie z. B. PDFs?

[nat (Natalie T)]

Beim Hochladen auf S3 müssen wir Header wie Content-Disposition und Content-Type der Datei angeben. Dies sind die Werte, die beim Laden der Datei zurückgegeben werden - PutObject - Amazon Simple Storage Service

@Canapin

wann tritt der erzwungene Download auf, auch wenn S3 nicht verwendet wird?

Können Sie erklären, wann dies geschieht?

@Canapin

Wird dies auch den erzwungenen Download für andere Dateien beheben, die im Browser geöffnet werden könnten, wie z. B. PDFs?

Der PR entfernt den Header Content-Disposition: attachment, der den Download unabhängig vom verwendeten Browser erzwingt.

Nachdem Sie Ihre Website aktualisiert haben, wird stattdessen der Content-Type verwendet, und der Browser entscheidet, was damit geschehen soll. Eine Sache ist zu beachten: Es gibt kein Problem mit Content-Type: application/mp4 auf Safari und Firefox, aber auf Chrome erzwingt es immer noch einen Download (wahrscheinlich aufgrund einer schlechten Historie, die Chrome mit dem mp4-Dateityp hat).