Ember CLI sta turbando nginx

Supporto Installazione
,
1

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**
2

Utilizziamo il proxying di Ember CLI solo in fase di sviluppo. In un’installazione standard, le richieste vanno dall’utente a NGINX a Rails. Ti suggerisco di attenerti a questo schema: non abbiamo progettato la nostra configurazione di Ember CLI per l’uso in produzione. Anche se riuscissi a farlo funzionare (cosa non facile), ci sarebbero probabilmente problemi di sicurezza e/o prestazioni.

3

Aha, beh, questa installazione è attualmente un ibrido sviluppo/produzione, quindi ha variabili d’ambiente come:

RAILS_ENV: development

anche se ha https completo e nginx sul front-end.

Ma potrei cambiarlo in “development” in modo da poter far funzionare le cose.

Sì, quindi Ember CLI non è assolutamente pronto per il “prime time” secondo me, e mi limiterò ad usarlo solo per lo sviluppo “vero”.

Grazie per queste informazioni cruciali David, mi hai fatto risparmiare un sacco di tempo!

4

OK questa storia, tra l’altro, diventa ancora più strana.

Ho due installazioni, entrambe configurazioni di ‘sviluppo’, questa e un’altra che è una configurazione Ubuntu non-docker.

Noto che le chiamate a /stylesheets/ sul server di sviluppo non-docker non includono “Transfer-Ecoding: chunked” nell’header dal server Rails e invece includono un valore “Content-Length”… qualcuno può spiegare come ciò possa essere diverso?

Aggiornamento: potrebbe essere spiegato da https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length

5

Scriverò un piccolo plugin per aggiungere l’header Content-Length alle risposte dei fogli di stile, giusto per vedere se riesco a prevenire una risposta Transfer-Encoding: chunked.

Se qualcuno conosce un modo più semplice per raggiungere questo obiettivo, sono tutt’orecchi!

(Per tua informazione, questo verrà utilizzato solo in fase di sviluppo e mai in produzione).

6

Ecco un aggiornamento su questo.

Ho ingannato con successo il sistema. Ho forzato un header Content-Length sovrascrivendo StylesheetsController, il che impedisce la risposta in chunk, aggirando la cattiva abitudine di Ember CLI ed evitando l’allergia non conforme di nginx.

Il modo in cui sono arrivato a questa soluzione è stato notando un’altra configurazione Ember CLI/nginx su https, dove Rails sceglieva di non inviare in chunk le risposte degli Stylesheet (qualcuno sa perché potrebbe essere stato così?). Questo mi ha portato a provare a forzare l’header e, indovina un po’, ha funzionato!

Questo è necessario solo in sviluppo, quindi non sono troppo preoccupato.