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?
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.
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.
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.
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.
No estoy seguro de entender completamente, así que una pregunta rápida sobre esta PR
¿Por qué las modificaciones se dirigen específicamente a archivos relacionados con s3, cuando la descarga forzada ocurre incluso cuando no se usa s3?
¿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).