Question

[Solved] Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH

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):

$('.image-prld').attr('src', someDynamicValue);

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:

enter image description here

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.

Solution #1:

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:

  1. 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)

  2. 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.

Respondent: user3332579

Solution #2:

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)

  1. Enter in your container: docker exec -it <container_id> bash

  2. Go to your logs, for example: cd /var/log/nginx.

  3. [optional] Show file size: ls -lh for individual file size or du -h for folder size.

  4. Empty file(s) with > file_name.

  5. It works!.

For advanced developers/sysadmins

Empty your nginx log with > file_name or similar.

Hope it helps

Respondent: Maxime Rouiller

Solution #3:

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.

Respondent: mrroot5

Solution #4:

This can be caused by a full disk (Ubuntu/Nginx).

My situation:

Respondent: Joe Valeriana

Solution #5:

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.

Respondent: vdB

Solution #6:

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:

  1. Click Tools > Fiddler Options.
  2. Click the HTTPS tab. Ensure the Decrypt HTTPS traffic checkbox is checked.
  3. Click the Export Fiddler Root Certificate to Desktop button.
Respondent: Tobias Gassmann

Solution #7:

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

Respondent: The Red Pea

Solution #8:

If this is related to docker, try stopping the erroneous container and starting a new container using docker run command from the same image.

Respondent: George

Solution #9:

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/
Respondent: Lanil Marasinghe

Solution #10:

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.

Respondent: Biegacz

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Most Popular

To Top
India and Pakistan’s steroid-soaked rhetoric over Kashmir will come back to haunt them both clenbuterol australia bossier man pleads guilty for leadership role in anabolic steriod distribution conspiracy