application.css and application.js net::ERR_CONTENT_LENGTH_MISMATCH

Question

I just upgraded my nginx from 1.4.2 (/usr/local) to 1.4.7 (yum) on AWS EC2. I now have a pair of errors occuring on the client side:

GET https://subdomain.mysite.com/assets/application.css net::ERR_CONTENT_LENGTH_MISMATCH 
GET https://subdomain.mysite.com/assets/application.js net::ERR_CONTENT_LENGTH_MISMATCH 

I am at a loss for this and google has not been much help. Any ideas on where to start? All help appreciated. Could the switch from a manual install to a yum install be the issue?

Answer 1

I can confirm answer 1 addresses the underlying problem (I'm a new SE user so I can't upvote it yet). Here is more detail for search engines:

From /var/log/nginx/error.log

2014/04/30 08:07:48 [crit] 35135#0: *116437 open() "/var/lib/nginx/proxy/7/09/0000001097" failed (13: Permission denied) while reading upstream

In my case this happened because I recently changed the user under which nginx runs (the default nginx config uses www-data in /etc/nginx/nginx.conf).

My solution was to chown -R correct_user:root /var/lib/nginx/proxy. I imagine I could also have rm -rf'd the existing /var/lib/nginx/proxy subdirectories with the expectation that nginx would recreate them using the correct_user as owner.

eric-francis thanks for figuring this out! This easily saved me a day of hunting.

Answer 2

tail -f /usr/local/var/log/nginx/error.log

You may see something like:

"/usr/local/var/run/nginx/proxy_temp/9/04/0000000049" failed (13: Permission denied) while reading upstream

Heres how I fixed:

sudo nginx -s stop
sudo rm -rf /usr/local/var/run/nginx/*

Answer 3

Ok, so this can be fixed in a couple of ways. The thing to do is check your log file.

Mine was located at /usr/share/nginx/log/error-appname.log

Tail the log and you will find that user defined in your config file (mine is at /etc/nginx/nginx.conf) most likely does not have permissions to something. I use user nobody.

For one app I had to give u+rx (nginx needs executable) to my application user's home folder all the way to my application's public assets directory.

On another server, nobody was not able to write to nginx's /var/lib/nginx/tmp/proxy folder. So I had to chown nobody /var/lib/nginx down to the /proxy folder nobody was trying to write to.