Ember CLI verärgert nginx

[merefield (Robert)]

Ich verfolge eine nicht unterstützte Docker-Installation.

Das bedeutet, dass Ember CLI in einem eigenen Container mit einem gemeinsam genutzten Volume über einen anderen Port ausgeführt und wie erwartet an den Rails-Server weitergeleitet wird.

Leider erhalte ich für alle .css-Assets “Bad Gateway 502” von curl und vom Browser, wenn ich vollständig über HTTPS und den Nginx-Reverse-Proxy gehe.

Es scheint, dass Ember CLI einen Content-Length-Header hinzufügt, obwohl bereits transfer-encoding: chunked vom Rails-Server hinzugefügt wurde.

(Ich kann die Antwort von Rails und Ember überprüfen, indem ich verschiedene Ports anspreche)

Dies verstößt meines Erachtens nicht gegen den HTTP 1.1-Protokollstandard (er soll ignoriert werden):

“Wenn eine Nachricht mit sowohl einem Transfer-Encoding-Headerfeld als auch einem Content-Length-Headerfeld empfangen wird, muss letzteres ignoriert werden.”

… aber es veranlasst Nginx dazu, zu zögern und eine 502 anzukündigen und das Asset nicht zu servieren, daher ist dies unerheblich.

Ich kann eine CSS-Datei mit curl direkt an den Container auf localhost durchsuchen, aber auf Nginx-Ebene ist es NICHT glücklich:

upstream sent "Content-Length" and "Transfer-Encoding" headers at the same time while reading response header from upstream

Hat jemand Ideen, wie man Ember CLI davon abhalten kann, dies zu tun, oder eine Problemumgehung? Ich bin überrascht, dass dies bei der Standardinstallation kein Problem ist? (da die Kommunikationskette sehr ähnlich sein sollte).

Die Discourse-Version ist 2.8.9

Header im Dock (kleine Schnitte zur Kürze):

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

[david (David Taylor)]

@merefield

Proxying, wie erwartet, zum Rails-Server

Wir verwenden Ember CLI-Proxying nur in der Entwicklung. Bei einer Standardinstallation gehen Anfragen an User → NGINX → Rails. Ich würde vorschlagen, sich an dieses Muster zu halten – wir haben unsere Ember CLI-Konfiguration nicht für den Einsatz in der Produktion ausgelegt. Selbst wenn es Ihnen gelingt, es zum Laufen zu bringen (was nicht einfach sein wird), wird es wahrscheinlich Sicherheits- und/oder Leistungsprobleme geben.

[merefield (Robert)]

Aha, nun, diese Installation ist derzeit eine Hybridversion für Entwicklung/Produktion, daher hat sie Umgebungsvariablen wie:

RAILS_ENV: development

obwohl sie vollständiges HTTPS und Nginx vorne hat.

Aber ich werde das vielleicht in der ‘Entwicklung’ ändern, damit wir die Dinge zum Laufen bringen können.

Ja, also ist Ember CLI meiner Meinung nach definitiv noch nicht bereit für den großen Auftritt, und ich werde es nur für die “echte” Entwicklung verwenden.

Danke für diese wichtigen Informationen, David, das hat mir viel Zeit gespart!

[merefield (Robert)]

OK, diese Geschichte wird übrigens noch seltsamer.

Ich habe zwei Installationen, beides „Development“-Setups, dieses hier und ein weiteres, ein Nicht-Docker-Ubuntu-Setup.

Ich stelle fest, dass Aufrufe an /stylesheets/ auf dem Nicht-Docker-Dev-Server „Transfer-Encoding: chunked“ nicht im Header des Rails-Servers enthalten und stattdessen einen „Content-Length“-Wert enthalten… kann mir jemand erklären, wie das unterschiedlich sein könnte?

Update: Könnte durch https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length erklärt werden.

[merefield (Robert)]

Ich werde ein kleines Plugin schreiben, um den Content-Length-Header zu Stylesheet-Antworten hinzuzufügen, nur um zu sehen, ob ich eine Transfer-Encoding: chunked-Antwort verhindern kann.

Wenn jemand einen einfacheren Weg kennt, das zu erreichen, bin ich ganz Ohr!

(Zu Ihrer Information: Dies wird nur in der Entwicklung und niemals in der Produktion verwendet).

[merefield (Robert)]

Ein Update dazu:

Ich habe das System erfolgreich ausgetrickst. Ich habe einen Content-Length-Header erzwungen, indem ich den StylesheetsController überschrieben habe, was die gestückelte Antwort verhindert, den schlechten Angewohnheiten von Ember CLI ausweicht und die Off-Spec-Allergie von nginx umgeht.

Wie ich zu dieser Lösung kam, war, als ich ein weiteres Ember CLI/nginx-Setup über HTTPS bemerkte, bei dem Rails sich dafür entschied, die Stylesheet-Antworten nicht zu stückeln (weiß jemand, warum das der Fall gewesen sein könnte?). Das brachte mich dazu, zu versuchen, den Header zu erzwingen, und siehe da, es hat funktioniert!

Dies ist nur im Entwicklungsmodus erforderlich, daher mache ich mir keine allzu großen Sorgen.