Ember CLIがnginxを悩ませている

[merefield (Robert)]

サポートされていない Docker インストールを試しています。

これは、Ember CLI を独自のコンテナで実行し、別のポートで共有ボリュームを使用し、予想どおり Rails サーバーにプロキシすることを意味します。

残念ながら、すべての .css アセットで、HTTPS 経由で完全に通信し、nginx リバース プロキシを使用すると、curl およびブラウザから「Bad Gateway 502」が発生します。

Ember CLI が transfer-encoding: chunked が Rails サーバーによって既に追加されているにもかかわらず、Content-Length ヘッダーを 追加 しているようです。

（Rails と Ember からの応答は、異なるポートを指定することで確認できます）

これは HTTP 1.1 プロトコル標準 を公式に壊すものではないと信じています（無視されるはずです）。

「Transfer-Encoding ヘッダーフィールドと Content-Length ヘッダーフィールドの両方を持つメッセージを受信した場合、後者は無視しなければならない。」

…しかし、nginx がこれに動揺し、502 を通知してアセットを提供しないため、これは無意味です。

curl でコンテナに直接 localhost 経由で CSS ファイルを閲覧できますが、nginx レベルではうまくいきません。

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

Ember CLI がこれを実行するのを停止する方法や、回避策についてのアイデアはありますか？ 標準のインストールでは問題にならないことに驚いていますか？（通信の連鎖は非常に似ているはずなので）。

Discourse のバージョンは 2.8.9 です。

ドックのヘッダー（簡潔にするために一部省略）：

< 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

プロキシは、予想通りRailsサーバーにプロキシされます。

Ember CLIのプロキシは開発時のみ使用します。標準的なインストールでは、リクエストはユーザー→NGINX→Railsの順に進みます。このパターンに従うことをお勧めします。Ember CLIの設定は本番環境での使用を想定して設計されていません。たとえ動作させたとしても（それは簡単ではありません）、セキュリティやパフォーマンス上の懸念が生じる可能性が高いです。

[merefield (Robert)]

なるほど、このインストールは現在開発/本番ハイブリッドなので、次のようなENV変数があります。

RAILS_ENV: development

実際には、フロントエンドに完全なHTTPSとnginxがありますが。

しかし、「開発」でそれを変更して、物事が機能するようにするかもしれません。

ええ、だからEmber CLIは間違いなく本番稼働の準備ができていないと私は思います、そして私はそれを「真の開発」にのみ使用します。

その重要な情報をありがとう、デイビッド、それは私の時間を大幅に節約してくれました！

[merefield (Robert)]

OK、この話はさらに奇妙になります。

インストールは2つあり、どちらも「開発」設定です。このインストールと、DockerではないUbuntuの設定です。

Dockerではない開発サーバーの /stylesheets/ への呼び出しは、Railsサーバーから「Transfer-Ecoding: chunked」ヘッダーを含まず、「Content-Length」値を含みます。これがどのように異なるのか説明していただけますか？

更新：https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length によって説明されるかもしれません。

[merefield (Robert)]

スタイルシートのレスポンスにContent-Lengthヘッダーを追加する小さなプラグインを書いて、Transfer-Encoding: chunkedレスポンスを防げるかどうか試してみます。

もし、これを達成するもっと簡単な方法を知っている方がいれば、ぜひ教えてください！

（参考までに、これは開発でのみ使用し、本番環境では決して使用しません。）

[merefield (Robert)]

これで最新情報です。

システムを騙すことに成功しました。Content-Length ヘッダーを強制するために StylesheetsController をオーバーライドし、これによりチャンク応答が防止され、Ember CLI の悪い癖を回避し、nginx のオフスペックアレルギーを回避できます。

このソリューションに至った経緯は、HTTPS 経由の別の Ember CLI/nginx セットアップに気づいたことです。そこでは Rails が Stylesheet の応答をチャンクしないように選択していました（誰か理由を知っていますか？）。それが、ヘッダーを強制することを試みるきっかけとなり、なんと、うまくいきました！

これは開発でのみ必要なので、あまり心配していません。