Ember CLI يزعج nginx

تثبيت
,
1

إذًا، أنا أقوم بتثبيت Docker غير مدعوم.

هذا يعني تشغيل Ember CLI في حاويته الخاصة مع وحدة تخزين مشتركة على منفذ مختلف وتوجيه، كما هو متوقع، إلى خادم Rails.

للأسف، لجميع أصول .css، أحصل على “بوابة سيئة 502” من curl ومن المتصفح عند المرور بالكامل عبر https ووكيل Nginx العكسي.

يبدو أن Ember CLI يقوم بإضافة رأس Content-Length على الرغم من وجود transfer-encoding: chunked مضاف بالفعل بواسطة خادم Rails.

(يمكنني التحقق من الاستجابة من Rails و Ember عن طريق معالجة منافذ مختلفة)

هذا لا يكسر رسميًا معيار بروتوكول HTTP 1.1، أعتقد (من المفترض تجاهله):

  • “إذا تم استلام رسالة تحتوي على كل من حقل رأس Transfer-Encoding وحقل رأس Content-Length، فيجب تجاهل الأخير.” *

… ولكنه يتسبب في تعثر Nginx والإعلان عن 502 وعدم تقديم الأصل، لذا فهذا غير مهم.

يمكنني تصفح ملف css باستخدام curl مباشرة إلى الحاوية على localhost، ولكن على مستوى nginx، فإنه غير سعيد:

أرسل الخادم الوكيل الرأسي "Content-Length" و "Transfer-Encoding" في نفس الوقت أثناء قراءة رأس الاستجابة من الخادم الوكيل

هل لدى أي شخص أي أفكار حول كيفية إيقاف 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**
إعجاب واحد (1)
2

نحن نستخدم فقط وكالة Ember CLI في التطوير. في التثبيت القياسي، تذهب الطلبات من المستخدم → NGINX → Rails. أقترح الالتزام بهذا النمط - لم نصمم تكوين Ember CLI الخاص بنا للاستخدام في الإنتاج. حتى لو تمكنت من جعله يعمل (وهو أمر لن يكون سهلاً) فمن المحتمل أن تكون هناك مخاوف أمنية و/أو تتعلق بالأداء.

6 إعجابات
3

آها، حسنًا، هذا التثبيت حاليًا هو مزيج بين التطوير والإنتاج، لذا يحتوي على متغيرات البيئة مثل:

RAILS_ENV: development

على الرغم من أنه يحتوي على https كامل و nginx في الواجهة.

لكنني قد أغير ذلك في “التطوير” حتى نتمكن من جعل الأمور تعمل.

نعم، لذا فإن Ember CLI بالتأكيد ليست جاهزة للاستخدام على نطاق واسع في رأيي، وسألتزم بها فقط للتطوير “الحقيقي”.

شكرًا لك على هذه المعلومات الهامة يا ديفيد، لقد وفرت علي الكثير من الوقت!

3 إعجابات
4

حسنًا، هذه القصة، بالمناسبة، تصبح أغرب.

لدي تثبيتان، كلاهما إعدادات “تطوير”، هذا الإعداد وإعداد آخر غير Docker على Ubuntu.

ألاحظ أن الاستدعاءات إلى /stylesheets/ على خادم التطوير غير Docker لا تتضمن “Transfer-Ecoding: chunked” في الرأس من خادم Rails وبدلاً من ذلك تتضمن قيمة “Content-Length”… هل يمكن لأي شخص شرح كيف يمكن أن يكون ذلك مختلفًا؟

تحديث: قد يتم تفسير ذلك بواسطة https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length

إعجاب واحد (1)
5

سأقوم بكتابة إضافة صغيرة لإضافة ترويسة Content-Length إلى استجابات أوراق الأنماط، فقط لأرى ما إذا كان بإمكاني منع استجابة Transfer-Encoding: chunked.

إذا كان أي شخص يعرف طريقة أبسط لتحقيق ذلك، فأنا مستعد للاستماع!

(للعلم، سيتم استخدام هذا فقط في بيئة التطوير وليس في بيئة الإنتاج أبدًا).

إعجاب واحد (1)
6

إليك تحديث حول هذا الأمر.

لقد خدعت النظام بنجاح. أجبرت على ترويسة Content-Length عن طريق تجاوز StylesheetsController، مما يمنع الاستجابة المجزأة، ويتجاوز عادة Ember CLI السيئة، ويتجنب حساسية nginx غير المطابقة للمواصفات.

كيف توصلت إلى هذا الحل كان بملاحظة إعداد آخر لـ Ember CLI/nginx عبر https، حيث اختارت Rails عدم تجزئة استجابات الأنماط (هل يعرف أحد لماذا قد يكون هذا هو الحال؟). أدى ذلك بي إلى محاولة فرض الترويسة، ويا للعجب، لقد نجح الأمر!

هذا مطلوب فقط في بيئة التطوير، لذلك لست قلقًا للغاية.

إعجابَين (2)
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.