Ember CLI is upsetting nginx

[merefield (Robert)]

So I’m pursuing an unsupported docker install.

This means running Ember CLI in its own container with a shared volume on a different port and proxying, as expected, to Rails server.

Unfortunately, for all .css assets, I’m getting “Bad Gateway 502” from curl and from browser when going fully via https and the nginx reverse proxy.

It appears that Ember CLI is adding a Content-Length Header despite having transfer-encoding: chunked already added by the Rails server

(I can check the response from Rails and Ember by addressing different ports)

This doesn’t officially break the HTTP 1.1 protocol standard, I believe (it’s supposed to be ignored) :

“If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter must be ignored.”

… but it does cause nginx to balk and announce a 502 and not serve the asset, so this is moot.

I can browse a css file with curl directly to the container on localhost, but at nginx level, it is NOT happy:

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

Anyone have any ideas of how to stop Ember CLI doing this or a workaround? I’m surprised this is not an issue with the standard install? (because the chain of communication should be very similar).

The Discourse version is 2.8.9

Header in the dock (minor snips for brevity):

< 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, as expected, to Rails server

We only use Ember CLI proxying in development. In a standard install, requests go User → NGINX → Rails. I’d suggest sticking to that pattern - we haven’t designed our Ember CLI configuration for use in production. Even if you manage to get it working (which won’t be easy) there will likely be security and/or performance concerns.

[merefield (Robert)]

Aha, well this install is currently a development/prod hybrid, so it’s got ENV variables like:

RAILS_ENV: development

even though its got full https and nginx on the front.

But I might change that in ‘development’ so we can get things working.

Yeah, so Ember CLI is definitely not ready for prime time imho, and I’ll stick with it only for “true” development

Thanks for that critical info David, that’s saved me a lot of time!

[merefield (Robert)]

OK this story, btw, gets weirder.

I have two installs, both ‘development’ setups, this one and another which is a non-docker Ubuntu setup.

I notice that calls to /stylesheets/ on the non-docker dev server do not include “Transfer-Ecoding: chunked” in the header from the Rails server and instead include a “Content-Length” value… can anyone explain how that could be different?

Update: might be explained by nginx - When does Rails respond with 'transfer-encoding' vs. 'content-length'? - Stack Overflow

[merefield (Robert)]

So I’m going to write a small plugin to add Content-Length header to stylesheet responses, just to see if I can prevent a Transfer-Encoding: chunked response.

If anyone knows a simpler way of achieving that I’m all ears!

(FYI this will just be used in Development and never in Production).

[merefield (Robert)]

So an update on this.

I’ve successfully fooled the system. I’ve forced a Content-Length header by overriding the StylesheetsController which prevents the chunked response, working around Ember CLI’s bad habit and avoiding nginx’s off-spec allergy.

How I got to this solution was by noticing another Ember CLI/nginx setup over https, where Rails was choosing not to chunk the Stylesheet responses (anyone know why this might have been the case?). That lead me to try to force the header and, waddayaknow, it worked!

This is only needed in development, so I’m not too worried.