Nginx and gunicorn are not displaying the whole page (caching issue)

Question

I have a django application, which works fine on django's server. I just configured it to work with nginx and gunicorn. Almost every page works just fine except for one of them. It is a pretty big page, which consists of 4 select(dropdown) menus with 1000 entries in each and all that is sent by a single html file by guinicorn. Gunicorn displays just half of the page. What is also interesting is that without nginx, gunicorn displays the whole thing just fine. Although the generated page is NOT static, nginx, for some reason, breaks the page.

Here is my nginx configuration:

ec2-user@ip-172-31-44-39:~/mira_website> sudo cat /etc/nginx/sites-available/miraFrontEnd
# This is example contains the bare minimum to get nginx going with
# Gunicornservers.

worker_processes 1;


user ec2-user nogroup; # for systems with a "nogroup"
# user nobody nobody; # for systems with "nobody" as a group instead

# Feel free to change all paths to suit your needs here, of course
pid /tmp/nginx.pid;
error_log /tmp/nginx.error.log;

events {
  worker_connections 1024; # increase if you have lots of clients
  accept_mutex off; # "on" if nginx worker_processes > 1
  # use epoll; # enable for Linux 2.6+
  # use kqueue; # enable for FreeBSD, OSX
}

http {
  # nginx will find this file in the config directory set at nginx build time
#  include mime.types;

  # fallback in case we can't determine a type
  default_type application/octet-stream;

  # click tracking!
  access_log /tmp/nginx.access.log combined;

  # you generally want to serve static files with nginx since neither
  # Unicorn nor Rainbows! is optimized for it at the moment
  sendfile on;

  tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
  tcp_nodelay off; # on may be better for some Comet/long-poll stuff

  gzip on;
  gzip_http_version 1.0;
  gzip_proxied any;
  gzip_min_length 500;
  gzip_disable "MSIE [1-6]\.";
  gzip_types text/plain text/html text/xml text/css
             text/comma-separated-values
             text/javascript application/x-javascript
             application/atom+xml;

  upstream app_server {

    # for UNIX domain socket setups:
    server unix:/home/ec2-user/gunicorn.sock fail_timeout=0;

    # for TCP setups, point these to your backend servers
    # server 192.168.0.7:8080 fail_timeout=0;
    # server 192.168.0.8:8080 fail_timeout=0;
    # server 192.168.0.9:8080 fail_timeout=0;
  }

  server {
    # listen 80 default deferred; # for Linux
    # listen 80 default accept_filter=httpready; # for FreeBSD
    listen 8000;

    client_max_body_size 4G;
    server_name _;

    keepalive_timeout 10;


    location /static {
        autoindex on;
        alias /home/ec2-user/mira_website/manageDb/static/;
    }

    location / {
      # checks for static file, if not found proxy to app
      try_files $uri @proxy_to_app;
    }

    location @proxy_to_app {
      # an HTTP header important enough to have its own Wikipedia entry:
      #   http://en.wikipedia.org/wiki/X-Forwarded-For
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      # enable this if and only if you use HTTPS, this helps Rack
      # set the proper protocol for doing redirects:
      # proxy_set_header X-Forwarded-Proto https;

      # pass the Host: header from the client right along so redirects
      # can be set properly within the Rack application
      proxy_set_header Host $http_host;

      # we don't want nginx trying to do something clever with
      # redirects, we set the Host: header above already.
      proxy_redirect off;

      proxy_pass http://app_server;

    }

    # Error pages
    error_page 500 502 503 504 /500.html;
    location = /500.html {
      root /path/to/app/current/public;
    }
  }
}

This server is running on amazon ec2 with Suse linux.

Any ideas?

EDIT: Ok, this is interesting, I cleared browser's cache, history, cookies and everything and it started working. And then, after trying again a few minutes later, it had the same problem. So it seems, when I clear the cache, it starts working but for some time only(weird!).

Answer 1

I have tried a lot of different configurations and got it working, though I am not sure what was really the case. What I think was the case was the directive called proxy_buffering. It is now set to off.

Also, what might solve this problem is setting proxy_buffer_size size. Here is the official documentation about this directive.