Tipos MIME incorrectos (cabecera content-type) para mp4 y js

Hola!

Me acabo de dar cuenta de que Discourse está enviando encabezados Content-type incorrectos a varios tipos de archivo:
los archivos mp4 de /uploads/ tienen el content-type: application/mp4 en lugar de video/mp4
mis subidas provinieron de S3, así que depende del proveedor de alojamiento de S3.

Algunos archivos javascript (.js) por ejemplo de /brotli_asset/ tienen application/javascript en lugar de text/javascript.

Uso discourse_docker sin modificaciones, he revisado el nginx incluido, contiene el archivo de configuración de mime-types correcto. Parece que el backend de Discourse es el culpable de enviar estos mime-types incorrectos.

¡Hola! Hasta donde he entendido, el problema con las cargas estaba de mi lado y fue causado por el proveedor S3 (lo resolví con éxito anulando la configuración en mi nginx). Y el problema con el JS de /brotli_asset/ está en algún lugar del nginx “interno” de Discourse, por lo que parece ser un error en discourse_docker.
Lamentablemente, no pude encontrar un lugar mejor para reportar el error que esta parte del foro. ¿Podrías indicarme, por favor?

Este es el lugar correcto, lo encontraste bien.

¿Puedes explicar por qué este es un problema que debería importarnos? ¿Rompe algo?

En pocas palabras, Discourse envía JavaScript desde diferentes ubicaciones con diferentes tipos MIME. Por ejemplo, /theme-javascripts/ff3c633d0d4192c83a194066eaa9d823b5c2d8f6.js va con text/javascript (correcto) y el mencionado anteriormente /brotli_asset/... con application/javascript. Esto puede confundir a los servidores proxy entre Discourse y el cliente, así como a los sistemas analíticos, donde he notado el problema.

Parece que solo necesitas configurar correctamente el Nginx interno en la imagen Docker de Discourse para los activos brotli.

¿Puede nombrar el sistema proxy / analítico que se rompió debido a esto? ¿Compartir un ejemplo del problema que ocurre en la naturaleza?

En el panel de tipos MIME de mis informes de goaccess, discourse divide los valores para js: uno para text/javascript y otro para application/javascript.

El segundo: tanto las directivas gzip_types como brotli_types en nginx son operadas por tipos MIME. Por lo tanto, para discourse, la gente tiene que configurar tanto el text/javascript correcto como el incorrecto application/javascript.
Lo mismo ocurre con cualquier proxy que re comprima contenido basado en tipos MIME.

Subo este tema porque creo que crea un pequeño problema, o al menos un comportamiento no deseado.

Abrir un archivo de video alojado en Discourse fuerza la descarga del video en lugar de reproducirlo en el navegador.

Clic derecho, copiar dirección del video, pegar el enlace en la barra de direcciones del navegador.

Lo raro es que en una instalación de desarrollo local, reproduce el video correctamente en el navegador:

Al cargar la URL del video, las cabeceras son diferentes entre una instalación normal y una de desarrollo.

En la instalación de producción normal, el tipo de contenido del video se establece en application/mp4, mientras que en una instalación de desarrollo se establece en video/mp4.

Cruce de publicaciones Discourse send PDF inline porque el autor corrigió un comportamiento no deseado similar con los PDF.

Estoy abierto a escuchar si alguien tiene una solución para evitar que los mp4 se descarguen forzosamente.

4 Me gusta

Ah, buen hallazgo, esto es extraño.

Parece que MiniMime (una biblioteca que usamos y poseemos) podría estar devolviendo estos valores

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

Crearé una PR y discutiremos si es un problema cambiar estos valores.

5 Me gusta

Solo una rápida actualización:

La ext_mime_db anterior que usamos sigue los Tipos de Medios IANA definidos aquí: https://www.iana.org/assignments/media-types/media-types.xhtml. Desafortunadamente, esto significa que mp4 es correctamente application/mp4 :sweat_smile:


Aunque, al investigar más a fondo nuestra implementación del cargador S3, veo que estamos agregando la cabecera Content-Disposition "attachment" para casi todas las cargas que no son imágenes, pero parece que solo estaba destinada a agregarse para los SVG. Usar "attachment" haría que el contenido se descargara en lugar de abrirse en una nueva pestaña. Para los videos, es una mezcla de application/video y attachment lo que está causando esto.

Al menos podemos eliminar esta cabecera, creo.

2 Me gusta

No estoy seguro de entender completamente, así que una pregunta rápida sobre esta PR :person_raising_hand:

¿Por qué las modificaciones se dirigen específicamente a archivos relacionados con s3, cuando la descarga forzada ocurre incluso cuando no se usa s3? :thinking:

¿Solucionará el problema en general de todos modos?
¿También solucionará la descarga forzada para otros archivos que podrían abrirse en el navegador, como los PDF?

Al subir a S3, tenemos que especificar encabezados como Content-Disposition y Content-Type del archivo. Estos son los valores que se devolverán al cargar el archivo - PutObject - Amazon Simple Storage Service

¿Puedes explicar cuándo está sucediendo esto?

El PR eliminará el encabezado Content-Disposition: attachment que fuerza la descarga independientemente del navegador que utilices.

Una vez que hayas actualizado tu sitio, se utilizará Content-Type en su lugar, y el navegador decidirá qué hacer con él. Una cosa a tener en cuenta es que no hay problema con Content-Type: application/mp4 en Safari y Firefox, pero en Chrome, todavía fuerza una descarga (probablemente debido a un mal historial que Chrome tiene con el tipo de archivo mp4).

2 Me gusta