Nginx et gunicorn ne affichent pas la page entière (problème de caching)

J'ai une application django, qui fonctionne bien sur le server de django. Je l'ai configuré pour travailler avec nginx et gunicorn. Presque toutes les pages fonctionnent bien, sauf pour l'une d'entre elles. C'est une très grosse page, composée de 4 menus sélectionnés (drop down menu) avec 1000 inputs dans chacun et tout ce qui est envoyé par un seul file html par guinicorn. Gunicorn affiche seulement la moitié de la page. Ce qui est également intéressant, c'est que sans nginx, gunicorn affiche tout cela très bien. Bien que la page générée ne soit PAS statique, nginx, pour une raison quelconque, casse la page.

Voici ma configuration nginx:

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 { # listn 80 default deferred; # for Linux # listn 80 default accept_filter=httpready; # for FreeBSD listn 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; } } } 

Ce server fonctionne sur amazon ec2 avec Suse linux.

Des idées?

EDIT: Ok, c'est intéressant, j'ai effacé le cache du browser, l'histoire, les cookies et tout et ça a commencé à fonctionner. Et puis, après avoir tenté quelques minutes plus tard, cela avait le même problème. Donc, il semble que lorsque j'arrête le cache, il commence à fonctionner, mais pendant un certain time (bizarre!).

J'ai essayé beaucoup de configurations différentes et j'ai travaillé, mais je ne suis pas sûr de ce qui était vraiment le cas. Ce qui me proxy_buffering être le cas, c'est la directive appelée proxy_buffering . Il est maintenant off .

En outre, ce qui pourrait résoudre ce problème, c'est définir la proxy_buffer_size size . Voici la documentation officielle sur cette directive.