What does this error message mean and how do I resolve it? That is from console of Google Chrome v33.0, on Windows 7.
Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH http://and.img.url/here.png
I’m trying to change the images’
src attribute using jQuery. For example like this (simplified):
There are about 30 images on the page. And the above error is happening for random images every time when I reload the page. But sometimes it is working well for all the images, without any error.
When this error happens, the particular image is displaying like this:
However, when I open the link next to the error message on a new tab, the image is loading, which says me logically that the images is valid and it exists.
This error is definite mismatch between the data that is advertised in the HTTP Headers and the data transferred over the wire.
It could come from the following:
Server: If a server has a bug with certain modules that changes the content but don’t update the content-length in the header or just doesn’t work properly. It was the case for the Node HTTP Proxy at some point (see here)
Proxy: Any proxy between you and your server could be modifying the request and not update the content-length header.
As far as I know, I haven’t see those problem in IIS but mostly with custom written code.
Let me know if that helps.
Docker + NGINX
In my situation, the problem was nginx docker container disk space. I had 10GB of logs and when I reduce this amount it works.
Step by step (for rookies/newbies)
Enter in your container:
docker exec -it <container_id> bash
Go to your logs, for example:
[optional] Show file size:
ls -lhfor individual file size or
du -hfor folder size.
Empty file(s) with
For advanced developers/sysadmins
Empty your nginx log with
> file_name or similar.
Hope it helps
It could be even caused by your ad blocker.
Try to disable it or adding an exception for the domain from which the images come from.
This can be caused by a full disk (Ubuntu/Nginx).
- this error occured in Chrome with Nginx serving a static file: “…/static/js/vendor.c4ed7962fb4a63ad3c3b.js net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)”
- root disk was full; after cleaning tmp files the error disappeared.
- to prevent: make sure your disk remains clean ( a script such as this could help:https://crunchify.com/how-to-automatically-delete-tmp-folders-in-linux-automatic-disk-log-cleanup-bash-script/ )
In my case I was miscalculating the Content-Length that I advertised in the header. I was serving Range-Requests for files and I mistakenly published the filesize in Content-Length.
I fixed the problem by setting Content-Length to the actual range that I was sending back to the browser.
So in case I am answering to a normal request I set the Content-Length to the filesize. In case I am answering to a range-request I set the Content-Length to the actualy length of the requested range.
In my case I was modifying the request to append a header (using Fiddler) to an
https request, but I did not configure it to decrypt https traffic. You can export a manually-created certificate from Fiddler, so you can trust/import the certificate by your browsers. See above link for details, some steps include:
- Click Tools > Fiddler Options.
- Click the HTTPS tab. Ensure the Decrypt HTTPS traffic checkbox is checked.
- Click the Export Fiddler Root Certificate to Desktop button.
In my case it was a proxy issue (requests proxied from nginx to a varnish cache) that caused the issue. I needed to add the following to my proxy definition
proxy_set_header Connection keep-alive;
I found the answer here: https://stackoverflow.com/a/55341260/1062129
If this is related to docker, try stopping the erroneous container and starting a new container using
docker run command from the same image.
If anyone struggle with that problem using docker + nginx, it could be permissions.
Nginx logs shown error:
2019/12/16 08:54:58 [crit] 6#6: *23 open() "/var/tmp/nginx/fastcgi/4/00/0000000004" failed (13: Permission denied) while reading upstream, client: 172.24.0.2, server: test.loc, request: "GET /login HTTP/1.1", upstream: "fastcgi://172.28.0.2:9001", host: "test.loc"
Run inside nginx container(path might vary):
chown -R www-data:www-data /var/tmp/nginx/
This is what worked for me.
proxy_buffer_size 1M; proxy_buffers 4 1M; proxy_busy_buffers_size
I increased the size of the above parameters in nginix proxy.conf file.
Here, nginix is working as a proxy for my microservice-based applications.