Así que estoy realizando una instalación no compatible de Docker.
Esto significa ejecutar Ember CLI en su propio contenedor con un volumen compartido en un puerto diferente y proxy, como se esperaba, al servidor Rails.
Desafortunadamente, para todos los activos .css, obtengo “Bad Gateway 502” de curl y del navegador cuando paso completamente a través de https y el proxy inverso nginx.
Parece que Ember CLI está agregando una cabecera Content-Length a pesar de que el servidor Rails ya agregó transfer-encoding: chunked.
(Puedo verificar la respuesta de Rails y Ember accediendo a diferentes puertos)
Esto no rompe oficialmente el estándar del protocolo HTTP 1.1, creo (se supone que debe ser ignorado):
- “Si se recibe un mensaje con un campo de cabecera Transfer-Encoding y un campo de cabecera Content-Length, este último debe ser ignorado”.
… pero hace que nginx se tambalee y anuncie un 502 y no sirva el activo, por lo que esto es irrelevante.
Puedo navegar por un archivo css con curl directamente al contenedor en localhost, pero a nivel de nginx, NO está contento:
upstream sent "Content-Length" and "Transfer-Encoding" headers at the same time while reading response header from upstream
¿Alguien tiene alguna idea de cómo detener a Ember CLI haciendo esto o alguna solución alternativa? Me sorprende que esto no sea un problema con la instalación estándar (porque la cadena de comunicación debería ser muy similar).
La versión de Discourse es 2.8.9
Cabecera en el dock (cortes menores para brevedad):
< content-transfer-encoding: binary
< content-type: text/css; charset=utf-8
< referrer-policy: strict-origin-when-cross-origin
< set-cookie: __profilin=p%3Dt; path=/forum; HttpOnly; SameSite=Lax
< **transfer-encoding: chunked**
< Vary: Accept, Accept-Encoding
< x-content-type-options: nosniff
< x-discourse-route: stylesheets/show
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-xss-protection: 0
< content-encoding: null
< **Content-Length: 3055**