Users have complained a few times about seeing a bizarre set of pink or green stripes on our webpage. At first I thought there were a rash of video card outages, but then someone sent me a screenshot from their browser (IE8). I later saw the same thing, but with slightly different colors on Chrome. Users have experienced this on their iPads and iPhones (iOS Safari). Because I've optimized the site to cache images, the bad image stays around until you clear your cache, so once you do, it resolves itself. My assumption is that the transmission of the image is being cut off mid-stream and then staying that way, but I can't for the life of me figure out why. Here's what I've checked:

Header length is being sent, and transmission looks okay (wget sample below):

wget http://www.superiorlivestock.com/templates/sla2/images/wallbg2.jpg
--2012-04-05 08:46:00--  http://www.superiorlivestock.com/templates/sla2/images/wallbg2.jpg
Resolving www.superiorlivestock.com (www.superiorlivestock.com)... [ip redacted]
Connecting to www.superiorlivestock.com (www.superiorlivestock.com)|[ip redacted]|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 45926 (45K) [image/jpeg]
Saving to: `wallbg2.jpg'

Images are not being served gzipped (apache conf below):

SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

The site is www.superiorlivestock.com, and here's a sample of the bad page load: Screenshot

Is there something obvious I'm missing? Am I saving my images in the wrong format somehow?

2 Answers 2


It seems you're not the only one having such problems, look here and here, there are some suggestions on fixes in these threads - have you ruled these out already?

Are you in a multi web server environment? Could one of the servers in the pool have a corrupted copy of the image?

Interestingly it's not limited to the background image, and the corruption affects the downloaded image which suggests there might indeed be a problem with the file rather than the server - how are you saving the images?

enter image description here

  • This is all being served up from one VMware VM which runs Debian 6 (Squeeze). We are saving the images for web using the settings specified in this screenshot : superiorlivestock.com/settings.png Is that the problem, should they be saved as progressive?
    – NateDSaint
    Commented Apr 5, 2012 at 15:15
  • @NateDSaint those settings look ok, what is the resolution set to, how do you upload the files to the server? Commented Apr 5, 2012 at 15:18
  • Resolution is whatever it needs to be for that image, we save for web so we don't have final pixels per inch, we just save to whatever the pixel amount is. (in my example above, 465x700). We get files to the server in a variety of ways, including FTP and dropping files into a samba share. The bizarre thing is that the images don't always load this way, if you refresh, it tends to fix itself, and we are only using one data store.
    – NateDSaint
    Commented Apr 5, 2012 at 15:29
  • @NateDSaint Yes, I see what you mean, it is very odd indeed - did any of the ideas in those other threads help? Commented Apr 5, 2012 at 15:36
  • 1
    @NateDSaint I've flagged it for migration, it's just a case of waiting for the admins to catch up. Commented Apr 5, 2012 at 16:06

The first thing I noticed when I looked at your page in Firebug is that some of your images (specifically this one, which toomanyairmiles already posted a screenshot of, and this other one) are simply huge — the first one is 4.2 megabytes!

When I first loaded the page, the huge image was corrupted, more or less like in toomanyairmiles's screenshot. When I reloaded the image, it downloaded correctly. However, curiously, in both cases the image file I got was 4,362,346 bytes long; it's just that, in the broken version, after 3,903,489 bytes the correct image data stopped and was replaced by something else (which, alas, looked just like random bytes — or compressed JPEG image data — in a hex editor).

Anyway, I suspect that resaving those few huge images at a more reasonable size should at least make the problem occur much less frequently, even if it won't actually fix the underlying cause of the data corruption. As a bonus, your website will also load faster.

  • Son of a... we have a system in place for the users to create thumbnails of the images, which they consistently forget to use.
    – NateDSaint
    Commented Apr 6, 2012 at 14:14
  • Ah, users. :) You might want to consider if there's any way of making the thumbnail generation happen automatically, then. Commented Apr 6, 2012 at 14:46
  • The best part is that the person who is supplying the images sometimes give them to us with an embedded ICC profile that's corrupted. So ultimately, there are problems all over the process stream. Thanks for the heads up, I made the classic mistake of assuming a user problem was "fixed" and moved on.
    – NateDSaint
    Commented Apr 6, 2012 at 15:25
  • I've gone back through and audited all those images, entire homepage loads in about 636kb now, 58k after initial image caching.
    – NateDSaint
    Commented Apr 6, 2012 at 15:50
  • I haven't gotten any complaints since we changed that so that may have been the problem. Thanks for your help!
    – NateDSaint
    Commented Apr 13, 2012 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.