4

I have a Rails/Postgres app hosted on AWS Elastic Beanstalk. One form posting data to my app also allows users to select multiple photos, in which the photos are directly uploaded to Amazon S3 using Carrierwave in the same request. While it works in development, it throws a '413 Request Entity Is Too Large' error in production.

I've tried configuring my app with some of the suggestions on related Stack Overflow posts to increase the max body size of the request, but nothing seems to be working. Not sure if I should be using the container commands at all either. No idea what that's doing.

.ebextensions/01_files.config

container_commands:
  01_reload_nginx:
    command: "service nginx reload"

files:
  "/etc/nginx/conf.d/proxy.conf" :
    mode: "000755"
    owner: root
    group: root
    content: |
        http {
          client_max_body_size 20M;
        }
Jeremiah
  • 189
  • 2
  • 12
wangg131
  • 51
  • 4

2 Answers2

0

I faced this same problem using my own docker-based configuration and the change that cleared it up for me was to add

client_max_body_size 20M;

at every level in the nginx.conf file for my container's nginx.

However, my nginx.conf was quite a bit more elaborate than yours. I don't understand how yours can work with only an http clause.

Here is what my nginx.conf looks like:

upstream myapp {
  server unix:///var/run/myapp.sock;
}

  client_max_body_size 20M;

        server {
          listen 80;
          server_name mayapp.com;

          # path for static files
          root /usr/src/app/public;

          location / {
              try_files $uri @proxy;
              client_max_body_size 20M;
          }

          location @proxy {
              proxy_pass  http://myapp;
              proxy_set_header Host      $host;
              proxy_set_header X-Real-IP $remote_addr;
              client_max_body_size 20M;
          }

          client_max_body_size 20M;
        }
Steve Madere
  • 509
  • 3
  • 9
0

Neither of the very commonly stated solutions worked for me - adding the proxy.conf file with.

client_max_body_size 20M;

or the same proxy.conf file with.

http {
      client_max_body_size 20M;
    }

The first didn't actually remove the 413 response codes/work & the second when nginx was restarted returned an error about it being a bad directive.

"http" directive is not allowed here in /etc/nginx/conf.d/proxy.conf:1

I don't like my solution but it did get rid of the 413s... in /etc/nginx/conf.d there is a symlinked file called webapp.conf - I overwrote that with an ebextension file. The file seems to be pretty static but this will break any changes that come out of elastic beanstalk patches to the file. Plan ahead!

My modified file looks like below (notice the last line) copy your own just in case they are different.

.ebextensions/01_files.config
files:
  "/etc/nginx/conf.d/webapp.conf" :
    mode: "000755"
    owner: root
    group: root
    content: |
   upstream my_app {
      server unix:///var/run/puma/my_app.sock;
    }

    server {
      listen 80;
      server_name _ localhost; # need to listen to localhost for worker tier

      location / {
        proxy_pass http://my_app; # match the name of upstream directive which is defined above
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      }

      location /assets {
        alias /var/app/current/public/assets;
        gzip_static on;
        gzip on;
        expires max;
        add_header Cache-Control public;
      }

      location /public {
        alias /var/app/current/public;
        gzip_static on;
        gzip on;
        expires max;
        add_header Cache-Control public;
      }

     client_max_body_size 100M;
    }
Jeremiah
  • 189
  • 2
  • 12
  • After typing this out I really didn't like the solution so I went back and looked at it. a standard proxy.conf with just 'client_max_body_size 20M;' will work - if you reload nginx after the file is written - otherwise nginx is started before that config is read in - add a container command that runs *after* the proxy.conf write operation and all is well. – Jeremiah May 27 '16 at 00:08