Ember CLI вызывает проблемы с nginx

Поддержка Самостоятельное хостинг
,
1

Итак, я пытаюсь выполнить неподдерживаемую установку Docker.

Это означает запуск Ember CLI в собственном контейнере с общим томом на другом порту и проксированием, как ожидается, на сервер Rails.

К сожалению, для всех .css-ресурсов я получаю ошибку «Bad Gateway 502» как от curl, так и из браузера при полном доступе через HTTPS и обратный прокси nginx.

Похоже, что Ember CLI добавляет заголовок Content-Length, несмотря на то, что сервер Rails уже добавил transfer-encoding: chunked.

(Я могу проверить ответ от Rails и Ember, обратившись к разным портам).

Официально это, как я понимаю, не нарушает стандарт протокола HTTP 1.1 (он должен игнорироваться):

«Если сообщение получено одновременно с заголовком Transfer-Encoding и заголовком Content-Length, последний должен игнорироваться.»

… но это заставляет nginx отказываться работать, выдавать ошибку 502 и не отдавать ресурс, так что это не имеет значения.

Я могу открыть CSS-файл с помощью curl напрямую к контейнеру на localhost, но на уровне 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**
2

Мы используем проксирование Ember CLI только в режиме разработки. При стандартной установке запросы идут по схеме: Пользователь → NGINX → Rails. Мы рекомендуем придерживаться этой схемы — наша конфигурация Ember CLI не предназначена для использования в продакшене. Даже если вам удастся заставить это работать (что будет нелегко), скорее всего возникнут проблемы с безопасностью и/или производительностью.

3

Ага, ну, эта установка в данный момент представляет собой гибрид разработки и продакшена, поэтому у неё есть переменные окружения, такие как:

RAILS_ENV: development

хотя у неё есть полный HTTPS и nginx на входе.

Но я, возможно, изменю это в режиме ‘development’, чтобы мы могли заставить всё работать.

Да, так что Ember CLI, на мой взгляд, определённо ещё не готов к использованию в продакшене, и я буду использовать его только для «настоящей» разработки.

Спасибо за эту критически важную информацию, Дэвид, это сэкономило мне много времени!

4

Кстати, эта история становится всё страннее.

У меня две установки, обе в режиме «разработки»: эта и ещё одна — не на Docker, а на Ubuntu.

Я заметил, что запросы к /stylesheets/ на нерасширенном сервере разработки не содержат заголовок «Transfer-Encoding: chunked» от сервера Rails, а вместо этого имеют значение «Content-Length»… кто-нибудь может объяснить, почему это может отличаться?

Обновление: возможно, это объясняется здесь: https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length

5

Итак, я планирую написать небольшой плагин, чтобы добавлять заголовок Content-Length к ответам со стилями, просто чтобы проверить, получится ли предотвратить ответ с Transfer-Encoding: chunked.

Если кто-то знает более простой способ добиться этого, я весь во внимании!

(К вашему сведению, это будет использоваться только в режиме разработки и никогда в продакшене).

6

Вот обновление по этому вопросу.

Мне удалось обмануть систему. Я принудительно добавил заголовок Content-Length, переопределив контроллер StylesheetsController, что предотвращает чанкированный ответ, обходит плохую привычку Ember CLI и избегает проблем nginx с нестандартным поведением.

К этому решению я пришел, заметив другую конфигурацию Ember CLI/nginx через https, где Rails не использовал чанкирование ответов для стилей (кто-нибудь знает, почему это могло быть?). Это подтолкнуло меня к попытке принудительно добавить заголовок, и, о чудо, это сработало!

Это требуется только в режиме разработки, так что я не слишком беспокоюсь.