User Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Build ID: 20111220165912 Steps to reproduce: Display http://www.vg.no/ by writing the URL directly in the URL-bar. Actual results: An image (http://static02.vg.no/gfx/ikon_dinepenger.png) gets replaced with a completely different image (http://static02.vg.no/css/drfront/sprite_sectionHeader590.jpg). The file ikon_dinepenger.png is then cached with its correct HTTP headers, but the content is wrong. This is persistent for all soft refreshes that will use the cached version. A hard refresh that fetches the image from server will replace it and fix the problem. Expected results: http://static02.vg.no/gfx/ikon_dinepenger.png should be displayed with its real content. Not with the content of http://static02.vg.no/css/drfront/sprite_sectionHeader590.jpg.

One of the earliest posts about this problem is http://forums.mozillazine.org/viewtopic.php?f=38&t=284489 which dates from 2004. I have enabled network.http.pipelining and not touched any of the other pipelining settings. We became aware of the issue (http://tech.vg.no/2011/12/14/safari-on-ios-5-randomly-switches-images/) first with iOS 5 which has pipelining enabled by default. Now we've reproduced it with Firefox 9 and we have some unconfirmed reports about it happening with Opera. Several other news pages(like www.db.no, www.ap.no) has also experienced the problem. We have lots of tcpdumps from debugging the problem on iOS 5, but everything looks to be correct in them.

If you see the problem in Safari, Firefox and Opera, why do you think it's a problem for Firefox ? Isn't the problem in the webserver itself ?

Well, yes. But we have experienced it with three different websites, three different CMSes, two different load balancers and three different webservers. Both Apache, Lighttpd and Varnish is all affected by it. We have also tried different load balancing schemes(l7/l4, sticky sessions, etc) for our Big-IP load balancer. We also have lots of tcpdumps of the traffic on the client side when the problem occurs, but everything _looks_ correct.

(In reply to André Roaldseth from comment #3) e traffic on the client side when the > problem occurs, but everything _looks_ correct. can you attach a trace or two to this bug, just for fun :) I'm working on a set of pipelining patches that hopes to be able to detect this kind of server error.. and, at a minimum ,dynamically turn off pipelining just for the site in question so that the damage is very limited. So if this turns out to be a good test case I am very appreciative.

(In reply to Patrick McManus [:mcmanus] from comment #4) > > can you attach a trace or two to this bug, just for fun :) > Not so relevant, but this is some of the dumps from when we were debugging the problem on Safari for iOS 5: http://dl.dropbox.com/u/35259841/tcpdumps.zip I haven't had the time to replicate(requires quite a lot of refreshes) it for Firefox yet. I'll try to find some time this week to replicate it with Firefox while running Wireshark.

h2 is the better way that pipelining.. pipelines are likely to leave the stack.