Spun out from the discussion started on usenet: http://groups.google.com/group/mozilla.dev.performance/browse_thread/thread/66fd7f50c17ea785/ HTTP Pipelining will remain disabled by default for Firefox 3, due to the number of outstanding issues with it. Currently, it can be optionally reenabled via the network.http.pipelining pref; various Firefox "tweak guides" have popularized this pref as a way to supposedly make Firefox faster. Google has 95,900 results for "network.http.pipelining", and as often happens with these kinds of claims, the guides rarely explain the risks of this pref or quantify the claimed benefits. I suspect many users are enabling this pref without understanding the problems it causes, and when they do start noticing strange behavior Firefox is simply blamed as being buggy. The long-term solution is that HTTP Pipelining should be made reliable, with workarounds for buggy servers. But this feature has been sitting around for years without such a solution, so I think at this point it clearly isn't going to be fixed for 1.9 (not to mention we're in a feature freeze). So, I propose disabling support for this pref in 1.9 for non-DEBUG builds... * add #ifdef DEBUG around the prefs checks in nsHttpHandler::PrefsChanged * remove defaults from modules/libpref/src/init/all.js ? Bonus points for doing this as a compile time flag, so projects (*cough*Seamonkey*cough*) can keep it available if they want to.

I don't think it should be disabled. Lots of people use it without problems. I'm actually surprised we're not trying harder to turn it on by default in Firefox 3.

Off by default, won't block.

Nack (or NAK as you like). I don't think that removing pipelining is a good idea for at least the following reasons. 1) Pipelining is explicitely allowed by RFC-2616 which is almost 8.5 years old now and a modern browser like Mozilla is expected to take advantage of it. 2) Pipelining support and development in Mozilla has stalled a bit in the last 2-3 years because current implementation is believed to be correct, so only web servers and specially web proxies should be blamed for all inconveniences. NOTE: there is really no excuse for a web server or a proxy server to not be compatible with pipelined requests and this has been true since 1999 or 2000, so let's put even more pressure on those pesky servers and their dumb administrators. 3) Many users use pipelining successfully on 99.99% of web sites and find it very useful to cut down Internet latencies on rich web pages (pages with many images / objects); I am one of those users. 4) Some users would like to see some smart tricks applied to pipelining logic in order to improve performances even more; I am one of those users. 5) Mozilla users who enable pipelining are not stupid and they can read everywhere the caveats about enabling pipeling, anyway if you want to promote a "campaign" to evangelize web server developers, web masters, system administrators, etc. then you are welcome ! If support for pipelined HTTP requests is removed, then all the work done till now will be thrown away for no good reason and any further improvement will become very hard to test and refine on a wide user base. Just look at bugs: 264354, 329977, etc. (pipelining is a keyword you can use to select bugs in Bugzilla). Don't forget that Opera supports pipelining by default (when using HTTP/1.1 requests) and future MSIE 8 might do the same (after all IIS-6 and later versions have become smart about pipelining).

> because current implementation is believed to be correct Really? Last I checked there were issues that people ran into that Darin couldn't reproduce but that might have been due to issues in our code... Note that I disagree with your conclusion (that we should leave the hidden pref). I just think we should stick to the facts.

(In reply to comment #4) > > because current implementation is believed to be correct > > Really? Last I checked there were issues that people ran into that Darin > couldn't reproduce but that might have been due to issues in our code... Ah ! So you think that that code could be reviewed and improved ! > Note that I disagree with your conclusion (that we should leave the hidden > pref). I just think we should stick to the facts. Please, don't get me wrong, I respect your thoughts, but think about the following sentences too. 1) If a few years ago, Mozilla evangelism would have been focused on this problem too, now there would not be a pipelining problem; I really think that pipelining is a "nano" problem (at least 1000 times smaller than bad HTML code in web pages). 2) You don't want to admit that Mozilla developers cannot improve current implementation, don't you ? 3) The facts are that OLD machines (including old buggy programs) are dieing; that death could be accelerated by some evangelism, after all I wouldn't trust a system administrator who is not able to update a web server or a web proxy at least once a year (to fix security bugs, etc.). If you fear about leaving to the users the power to enable pipelining, you can just spread visible caveats in preferences or point them to the right FAQs or adding a few emphasized lines in README and release notes on mozilla web site, etc.; i.e. (joking) "you dumb users are likely to suffer with pipelining enabled because of the massive usage of old transparent proxies, spy systems, men in the middle, etc.". 4) What about doing what I suggested a few years ago (i.e. to write open source programs to test pipelining capabilities of web servers and transparent proxies) ? 5) What about closing old pipelining bugs that looks like to have been fixed ? I would agree with you only if there would be a plan to rewrite current implementation and there would not be enough time to do it before next major release (i.e. Gecko 1.9 / Firefox 3), but in that case don't complain if users try to raise the value of other parameters, i.e.: network.http.max-persistent-connections-per-server 8

> 2) You don't want to admit that Mozilla developers cannot improve current > implementation, don't you ? Given the state of things (problems that are intermittent and hard to reproduce but that bite people in very nasty ways), that's actually pretty much exactly where we are. Well, that, and the fact that no on who actually knows the code is still active. I meant to say "Not that I disagree with your conclusion", for what it's worth.

Please, this isn't advocacy bug. How Mozilla got into this state or what can be done to fix it in the future is out of scope for this bug.

You're the one who wants this change. You can't make arguments against the change go away by saying they're "out of scope".

Jesse: Huh? My point is that kvetching about what could have been done years ago or how pipelining might somehow be fixed in the future is pointless here. The current state of the pipelining code seems extremely unlikely to change before the release of Firefox 3, so the issue at hand is if disabling the pref for FF3 (for the reasons in comment #0) helps more than it hurts.

I'm confused... you're proposing that we replace the current hidden pref with a different hidden pref because people might be using it? I've been running with pipelining enabled since 1.5 and noticed only occasional problems... why would you force me (or other users who have tweaked their Firefox on purpose) to set a different pref?

(In reply to comment #9) > Jesse: Huh? My point is that kvetching about what could have been done years > ago or how pipelining might somehow be fixed in the future is pointless here. > The current state of the pipelining code seems extremely unlikely to change > before the release of Firefox 3, so the issue at hand is if disabling the pref > for FF3 (for the reasons in comment #0) helps more than it hurts. I understand the logic, but what about reducing the max internal limit for pipelined requests from 8 to 2 ? I know for sure that setting "network.http.pipelining.maxrequests" to the upper limit of 8 can cause more troubles than usual, so, maybe, limiting it can be useful (also for 56K modem connections). NOTE: I use a value of 5 (maxrequests), it looks like to work well. Anyway, if you _really_ think that pipelining has to be disabled in FF 3 (because it will help narrowing problems related with FF 3 bugs) and that it will be reenabled in FF 3.1 or 3.5, then do it. NOTE: I use Seamonkey too, so I can live for a while without *cough*Firefox-3*cough* ;-)

So, I caught part of a #firefox IRC conversation today about this. I'm pasting this (edited) here just as an example of why I originally filed this bug: <Phil> when i type for example into a google image search, not all the images display, only some display, i have to reload the page in order to view more <Phil> internet explorer works fine <Phil> but firefox doesn't <Phil> it only loads SOME images, and then more, then more each time you reload the page <Phil> can anyone help me? <Phil> i mean, i think it's a bug <Phil> even if i re-install firefox <Phil> it still doesn't work <Phil> when i go on any site <Phil> in displays SOME of the images, but not all of them. i save to keep reloading the page in order to display ALL the image [...Phil is asked to try with a new profile...] <Phil> FUCK YES <Phil> IT WORKS <Phil> AFTER ABOUT A YEAR <Phil> I FINALLY GOT IT WORKING I had him check the pipelining pref in his old profile, and it was enabled. Upon disabling it: <Phil> holy shit <Phil> you've done it m8 <Phil> !!! <Phil> i love you dolske The user also said that some specific sites with the problem were Google Images, Altavista, and GoDaddy. His ISP is Orange UK, in case that matters (transparent proxying, maybe?). He said he "may have" applied one of those speed tweaks "ages ago". I wish we had some idea why pipelining seems to cause some users great pains, while others say it works fine.

(In reply to comment #12) > So, I caught part of a #firefox IRC conversation today about this. I'm pasting > this (edited) here just as an example of why I originally filed this bug: > > > I had him check the pipelining pref in his old profile, and it was enabled. > Upon disabling it: > ... > The user also said that some specific sites with the problem were Google > Images, Altavista, and GoDaddy. His ISP is Orange UK, in case that matters > (transparent proxying, maybe?). He said he "may have" applied one of those > speed tweaks "ages ago". > > I wish we had some idea why pipelining seems to cause some users great pains, > while others say it works fine. > 1) Did you bother to ask him what version of Firefox he was using ? 2) It's not the first negative report about pipelining that comes from UK, so yes I really think that there there are a lot of broken transparent proxies (british conservatorism ?). This is another fact in favour of my proposal to develop open source programs to specifically test HTTP pipelining capabilities of servers, software load balancers and proxies (transparent or not); maybe the most successful tests could be included in future versions of Firefox too.

This bug is rather old, I doubt that what has been requested here is ever going to happen. I have been using pipelining enabled since about 2008 and yet I'm still waiting for the first server where the page won't load correctly with pipelining enabled, but it will once disabled. I strongly vote for cloning this bug as WONTFIX.