Sto perseguendo un’installazione Docker non supportata.
Ciò significa eseguire Ember CLI nel proprio container con un volume condiviso su una porta diversa e inoltrare, come previsto, al server Rails.
Sfortunatamente, per tutti gli asset .css, ricevo “Bad Gateway 502” da curl e dal browser quando passo completamente tramite https e il reverse proxy nginx.
Sembra che Ember CLI stia aggiungendo un’intestazione Content-Length nonostante abbia già transfer-encoding: chunked aggiunta dal server Rails.
(Posso controllare la risposta da Rails ed Ember indirizzando porte diverse)
Questo non viola ufficialmente lo standard del protocollo HTTP 1.1, credo (dovrebbe essere ignorato):
- “Se viene ricevuto un messaggio con entrambi i campi di intestazione Transfer-Encoding e Content-Length, quest’ultimo deve essere ignorato.”
… ma fa sì che nginx si blocchi e annunci un 502 e non serva l’asset, quindi questo è irrilevante.
Posso sfogliare un file css con curl direttamente al container su localhost, ma a livello di nginx, NON è felice:
upstream sent "Content-Length" and "Transfer-Encoding" headers at the same time while reading response header from upstream
Qualcuno ha idee su come impedire a Ember CLI di fare questo o una soluzione? Sono sorpreso che questo non sia un problema con l’installazione standard? (perché la catena di comunicazione dovrebbe essere molto simile).
La versione di Discourse è 2.8.9
Intestazione nel dock (piccoli tagli per brevità):
< 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**