Images get the wrong content with pipelining enabled




Networking: HTTP
6 years ago
2 years ago


(Reporter: André Roaldseth, Unassigned)


9 Branch
Windows XP

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
Created attachment 587264 [details]
Screenshots of Firebug/Chrome Developer tool with headers of the images.

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 by writing the URL directly in the URL-bar.

Actual results:

An image ( gets replaced with a completely different image (

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: should be displayed with its real content. Not with the content of

Comment 1

6 years ago
One of the earliest posts about this problem is 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 ( 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, 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.


6 years ago
Summary: Images get the wrong content and headers with pipelining enabled → Images get the wrong content with pipelining enabled

Comment 2

6 years ago
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 ?

Comment 3

6 years ago
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.


6 years ago
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
QA Contact: untriaged → networking.http
(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.

Comment 5

6 years ago
(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:

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.
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.