'Express and nginx net::ERR_CONTENT_LENGTH_MISMATCH
I'm developing an Express-driven site, that is going through an nginx proxy. Sometimes when loading a page in the browser, I get this:
GET http://myapp.local/css/bootstrap.css net::ERR_CONTENT_LENGTH_MISMATCH
If I refresh the page, it usually goes away. But if refresh over and over and over, it will come up again.
What is the problem here? What can I do to narrow down the issue here? Here is my nginx
conf for this server:
server {
listen 80;
server_name www.myapp.local;
rewrite ^(.*) http://myapp.local$1 permanent;
}
server {
listen 80;
server_name myapp.local;
access_log /vagrant/nginx/logs/myapp.local/access.log;
error_log /vagrant/nginx/logs/myapp.local/error.log;
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
This is definitely something to do with the nginx proxy. Because if I access the site using just the IP address and Node port: http://10.10.10.10:8080
then I never ever get the error. But if I access it using the proxied vhost: http://myapp.local
then I will eventually get the error (maybe 1 out of 10 chance I see it).
Solution 1:[1]
The net::ERR_CONTENT_LENGTH_MISMATCH
is a caching issue. You're telling Nginx to bypass the cache if certain conditions are met (in your case $http_upgrade
).
You should've specified the caching location for nginx in a configuration file somewhere. A quick fix will be to delete the contents of this folder, restart nginx, and then try accessing the site again. Another quick fix at the expense of caching is to remove the line proxy_cache_bypass $http_upgrade;
If you provide more details on your caching setup, perhaps this answer could be improved.
Solution 2:[2]
This is a problem with proxy buffering. When buffering is enabled, nginx receives a response from the proxied server as soon as possible, saving it into the buffers set by the proxy_buffer_size
and proxy_buffers
directives. If the whole response does not fit into memory, a part of it can be saved to a temporary file on the disk. Writing to temporary files is controlled by the proxy_max_temp_file_size
and proxy_temp_file_write_size
directives.
When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. The maximum size of the data that nginx can receive from the server at a time is set by the proxy_buffer_size
directive.
So you may simply disable the proxy buffering to fix this issue:
proxy_buffering off;
Also note that nginx is simply trying to write to a temporary file on the disk and if the disk is full you will get the same error. So before disabling proxy_buffering
check your disk usage.
Solution 3:[3]
When I tried the aforementioned solution it didn't fix the issue. I also changed the permission to write on the location but it didn't work. Then I realized I did something wrong in there. In the location to store the file, I had something like
"/storage" + fileName + ".csv"
. I was testing on the Windows environment and it was working great. But later when we moved the application to the Linux environment it stopped working. So later I had to change it to
"./storage" + fileName + ".csv"
and it started working normally.
Solution 4:[4]
In case that anybody else is having this issue and the proxy_buffering solution does not work for them. I would first of all want to recommend that in the API call you add "X-Accel-Buffering: no" instead of changing the proxy_buffering:
Buffering can also be enabled or disabled by passing “yes” or “no” in the “X-Accel-Buffering” response header field.
Finally, the issue can also be related to permissions. If you have changed your Nginx user recently, it is possible that the new user does not have access to the proxy_temp folder that Nginx writes to. You might have this folder under "/usr/local/var/run/nginx". You have to change the permissions of this folder to match the user and group that Nginx has.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Keenan Lawrence |
Solution 2 | |
Solution 3 | Sandip Subedi |
Solution 4 | Fabian Svensson |