# Ember CLI is upsetting nginx

**URL:** https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585
**Category:** Self-hosting
**Tags:** unsupported-install, docker
**Created:** [October 21, 2022, 11:22am UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585 "2022-10-21T11:22:37Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [October 21, 2022, 11:22am UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585/1 "2022-10-21T11:22:37Z")

</div>

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](https://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.4.4), 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:

```plaintext
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](https://meta.discourse.org/t/142537?silent=true)? (because the chain of communication should be very similar).

The Discourse version is 2.8.9

Header in the dock (minor snips for brevity):

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

```

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [October 21, 2022, 1:37pm UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585/2 "2022-10-21T13:37:01Z")

</div>

> [@merefield](#):
>
> proxying, as expected, to Rails server

We only use Ember CLI proxying in development. In a [standard install](https://meta.discourse.org/t/142537?silent=true), 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.

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [October 21, 2022, 1:40pm UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585/3 "2022-10-21T13:40:30Z")

</div>

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!

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [October 21, 2022, 8:53pm UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585/4 "2022-10-21T20:53:22Z")

</div>

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 [https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length](https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length)

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [October 24, 2022, 11:20am UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585/5 "2022-10-24T11:20:13Z")

</div>

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).

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [October 28, 2022, 10:31am UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585/6 "2022-10-28T10:31:28Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [November 27, 2022, 10:32am UTC](https://meta.discourse.org/t/ember-cli-is-upsetting-nginx/242585/7 "2022-11-27T10:32:19Z")

</div>

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