Estou a tentar uma instalação Docker não suportada.
Isto significa executar o Ember CLI no seu próprio contentor com um volume partilhado numa porta diferente e fazer proxy, como esperado, para o servidor Rails.
Infelizmente, para todos os ativos .css, estou a receber “Bad Gateway 502” do curl e do navegador quando passo totalmente por https e pelo proxy reverso nginx.
Parece que o Ember CLI está a adicionar um cabeçalho Content-Length, apesar de já ter transfer-encoding: chunked adicionado pelo servidor Rails.
(Posso verificar a resposta do Rails e do Ember acedendo a portas diferentes)
Isto não quebra oficialmente o padrão do protocolo HTTP 1.1, creio eu (deve ser ignorado):
- “Se uma mensagem for recebida com um campo de cabeçalho Transfer-Encoding e um campo de cabeçalho Content-Length, este último deve ser ignorado.”
… mas faz com que o nginx hesite e anuncie um 502 e não sirva o ativo, pelo que isto é irrelevante.
Posso navegar num ficheiro css com curl diretamente para o contentor em localhost, mas ao nível do nginx, ele NÃO está feliz:
upstream sent "Content-Length" and "Transfer-Encoding" headers at the same time while reading response header from upstream
Alguém tem alguma ideia de como impedir o Ember CLI de fazer isto ou uma solução alternativa? Surpreende-me que isto não seja um problema com a instalação padrão? (porque a cadeia de comunicação deve ser muito semelhante).
A versão do Discourse é 2.8.9
Cabeçalho no contentor (pequenos cortes para brevidade):
< 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**