Proxies can't mess with the traffic, so we should try enabling pipelining on these connections.
Created attachment 301071 [details] [diff] [review] v1 pretty sure this does what we want. 1) add network.http.pipelining.ssl pref 2) default it to on for firefox 3) if it's set, and we're ssl, twiddle the pipelining flag (note - if the pref is set to false, we won't *untwiddle* the pipelining flag - so this can only be used to turn it on for ssl. if there's a use case the other way, could implement that.) we don't want ui for this, right? tested this loading https://mail.google.com, and of all nsHttpChannel transactions, 33 were pipelined and 12 weren't (because of explicit disabling; see http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp&rev=1.326#472)
we should update the docs at http://www.mozilla.org/quality/networking/docs/netprefs.html and possibly elsewhere to reflect this pref.
Comment on attachment 301071 [details] [diff] [review] v1 oh, easier than I thought :)
Why Firefox-only? Why not just turn it on for all Gecko consumers?
would everyone want this? if so, i'm fine with doing it. (i'll just do it on checkin if shaver's opinion is favorable.)
(In reply to comment #6) > would everyone want this? Can be done in a follow-up if they do.
User-agent is badly overloaded, but we have a policy that Gecko rv: means the same capabilities no matter what browser or other UA-like app, and capabilities seems to me to include SSL pipelining. Also, if it's good for Firefox, it's good for Camino, etc. Either argument is enough. /be
Created attachment 301455 [details] [diff] [review] v2 alright, let's just do that.
Comment on attachment 301071 [details] [diff] [review] v1 sr=shaver
Comment on attachment 301455 [details] [diff] [review] v2 sr=shaver on the right patch
Comment on attachment 301455 [details] [diff] [review] v2 yay! requesting approval.
Drivers: this is could help SSL perf in some use cases. It doesn't fix the head-of-line blocking that hobbles HTTP, but maybe it will make a difference for sites with lots of static resources. It is the right way to unwedge pipelining, because it will expose bugs in proxies, but only those under the control of origin servers, behind the SSL termination point. The crucial distinction is that sites won't be victims of proxies they don't control. That said, if nightlies and beta4 expose widespread compat problems, this is easy to turn off.
(In reply to comment #13) > Drivers: this is could help SSL perf in some use cases. It doesn't fix the > head-of-line blocking that hobbles HTTP, but maybe it will make a difference > for sites with lots of static resources. AMO is one such site, I suspect, even via the API. (I'm assuming the netscalers don't botch pipelining, but that might be worth testing ahead of check-in if people are bored.)
Comment on attachment 301455 [details] [diff] [review] v2 a=mconnor on behalf of drivers boom, baby
Comment on attachment 301455 [details] [diff] [review] v2 a=beltzner Shold we also be changing our default sessionstore pref to now cache content on SSL pages?
(In reply to comment #16) > Should we also be changing our default sessionstore pref to now cache content on > SSL pages? Whoops - that's a different bug. Sorry.
This bug mentions SSL, but it really means https, right? This does not cause pipelining to occur for application protocols running over SSL other than http, right?
right, this affects https only.
checked in. if any regressions pop up, please cc me. once we're pretty sure this is going to stick, i'll see about updating docs at: http://www.mozilla.org/quality/networking/docs/netprefs.html (deprecated?) http://developer.mozilla.org/en/docs/Mozilla_Networking_Preferences
this may have caused bug 422978.