April 2013 - tor-commits - lists.torproject.org

[torbrowser/master] Merge branch 'maint-2.4'
by mikeperry＠torproject.org 11 Apr '13

11 Apr '13

commit 12e20a4b7fd1ddff616d8dfd892d5d9341c78c38 Merge: 6269eee 509711f Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Apr 11 12:53:28 2013 -0700 Merge branch 'maint-2.4' ...ize-HTTP-request-order-and-pipeline-depth.patch | 59 +++++++++++-------- 1 files changed, 34 insertions(+), 25 deletions(-)

1 0

[torbrowser/maint-2.4] Minor tweaks to the pipeline patch.
by mikeperry＠torproject.org 11 Apr '13

11 Apr '13

commit 509711f6478cc906e019143ca3c7f544e00f78c2 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Apr 11 12:45:58 2013 -0700 Minor tweaks to the pipeline patch. We were being too generous by not counting pending requests towards the depth limit. This caused fairly fixed batching sizes. --- ...ize-HTTP-request-order-and-pipeline-depth.patch | 59 +++++++++++-------- 1 files changed, 34 insertions(+), 25 deletions(-) diff --git a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch index cb29e76..f7dab44 100644 --- a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch +++ b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch @@ -1,4 +1,4 @@ -From 7b340f34e429a4cb3407f838b4d414a671668419 Mon Sep 17 00:00:00 2001 +From 468117ab9f414332429406e588ad81fa7b3c72fa Mon Sep 17 00:00:00 2001 From: Mike Perry <mikeperry-git(a)torproject.org> Date: Tue, 4 Dec 2012 17:38:51 -0800 Subject: [PATCH 17/28] Randomize HTTP request order and pipeline depth. @@ -10,8 +10,8 @@ See: https://blog.torproject.org/blog/experimental-defense-website-traffic-finge… This patch is different from the approach described in that post, as well as -the the 10.x ESR patch, as the pipelining code has changed significantly -between the time of writing of that post and Firefox 17. +the 10.x ESR patch, as the pipelining code has changed significantly between +the time of writing of that post and Firefox 17. The main control nob for this patch is now the about:config pref "network.http.pipelining.max-optimistic-requests". The value of that pref @@ -26,8 +26,8 @@ extremely sensitive to browser performance. In fact, a debug build alone is enough to significantly impair request availability to the pipeline (due slower document parsing and rendering). For this reason, we provide two separate debug log defines. For most evaluation circumstances, you want to -define only WTF_TEST in an optimized build to only log request order and -combination behavior. +define only WTF_TEST in an optimized build to only log request order, +combination behavior, and cases where the pipeline is forcibly disabled. This patch may also have some minor impact on SPDY request order, but the SPDY implementation has not been altered directly. It has several stream queues @@ -36,15 +36,15 @@ request representation that will allow more requests to be packed inside Tor cells. If you have interest in evaluating SPDY in a study of Website Traffic Fingerprinting, please contact me. --- - netwerk/protocol/http/nsHttpConnectionMgr.cpp | 288 +++++++++++++++++-------- + netwerk/protocol/http/nsHttpConnectionMgr.cpp | 297 +++++++++++++++++-------- netwerk/protocol/http/nsHttpConnectionMgr.h | 15 +- netwerk/protocol/http/nsHttpHandler.h | 2 + netwerk/protocol/http/nsHttpPipeline.cpp | 62 +++++- netwerk/protocol/http/nsHttpPipeline.h | 3 + - 5 files changed, 272 insertions(+), 98 deletions(-) + 5 files changed, 281 insertions(+), 98 deletions(-) diff --git a/netwerk/protocol/http/nsHttpConnectionMgr.cpp b/netwerk/protocol/http/nsHttpConnectionMgr.cpp -index 133c301..872d505 100644 +index 133c301..81ea113 100644 --- a/netwerk/protocol/http/nsHttpConnectionMgr.cpp +++ b/netwerk/protocol/http/nsHttpConnectionMgr.cpp @@ -20,6 +20,8 @@ @@ -139,7 +139,7 @@ index 133c301..872d505 100644 nsHttpTransaction *trans, nsHttpTransaction::Classifier classification, uint16_t depthLimit) -@@ -1300,40 +1328,92 @@ nsHttpConnectionMgr::AddToShortestPipeline(nsConnectionEntry *ent, +@@ -1300,40 +1328,100 @@ nsHttpConnectionMgr::AddToShortestPipeline(nsConnectionEntry *ent, if (maxdepth < 2) return false; @@ -199,8 +199,16 @@ index 133c301..872d505 100644 - if (maxdepth <= connLength) + totalDepth += pipelineDepth; + -+ // Only count in-flight requests towards maxdepth. -+ if (maxdepth <= (pipelineDepth - requestLen)) ++ // If we're within striking distance of our pipeline ++ // packaging goal, give a little slack on the depth ++ // limit to allow us to try to get there. Don't give ++ // too much slack, though, or we'll tend to have ++ // request packages of the same size when we have ++ // many content elements appear. ++ if (maxdepth <= ++ (pipelineDepth - ++ PR_MIN(mMaxOptimisticPipelinedRequests, ++ requestLen + allClasses))) continue; - if (!bestConn || (connLength < bestConnLength)) { @@ -246,7 +254,7 @@ index 133c301..872d505 100644 activeTrans = bestConn->Transaction(); nsresult rv = activeTrans->AddTransaction(trans); -@@ -1343,6 +1423,14 @@ nsHttpConnectionMgr::AddToShortestPipeline(nsConnectionEntry *ent, +@@ -1343,6 +1431,14 @@ nsHttpConnectionMgr::AddToShortestPipeline(nsConnectionEntry *ent, LOG((" scheduling trans %p on pipeline at position %d\n", trans, trans->PipelinePosition())); @@ -261,7 +269,7 @@ index 133c301..872d505 100644 if ((ent->PipelineState() == PS_YELLOW) && (trans->PipelinePosition() > 1)) ent->SetYellowConnection(bestConn); return true; -@@ -1403,26 +1491,12 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, +@@ -1403,26 +1499,12 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, nsHttpTransaction::Classifier classification = trans->Classification(); uint8_t caps = trans->Caps(); @@ -290,7 +298,7 @@ index 133c301..872d505 100644 // step 0 // look for existing spdy connection - that's always best because it is // essentially pipelining without head of line blocking -@@ -1436,20 +1510,27 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, +@@ -1436,20 +1518,27 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, } } @@ -330,7 +338,7 @@ index 133c301..872d505 100644 nsRefPtr<nsHttpConnection> conn; while (!conn && (ent->mIdleConns.Length() > 0)) { conn = ent->mIdleConns[0]; -@@ -1483,21 +1564,8 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, +@@ -1483,21 +1572,8 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, } } @@ -354,7 +362,7 @@ index 133c301..872d505 100644 nsresult rv = MakeNewConnection(ent, trans); if (NS_SUCCEEDED(rv)) { // this function returns NOT_AVAILABLE for asynchronous connects -@@ -1510,17 +1578,16 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, +@@ -1510,17 +1586,16 @@ nsHttpConnectionMgr::TryDispatchTransaction(nsConnectionEntry *ent, return rv; } } @@ -377,11 +385,11 @@ index 133c301..872d505 100644 - } - - // step 6 -+ // step 6: Queue it ++ // step 5: Queue it return NS_ERROR_NOT_AVAILABLE; /* queue it */ } -@@ -1590,10 +1657,20 @@ nsHttpConnectionMgr::DispatchAbstractTransaction(nsConnectionEntry *ent, +@@ -1590,10 +1665,20 @@ nsHttpConnectionMgr::DispatchAbstractTransaction(nsConnectionEntry *ent, if (!NS_SUCCEEDED(rv)) return rv; transaction = pipeline; @@ -402,7 +410,7 @@ index 133c301..872d505 100644 } nsRefPtr<nsConnectionHandle> handle = new nsConnectionHandle(conn); -@@ -1692,27 +1769,15 @@ nsHttpConnectionMgr::ProcessNewTransaction(nsHttpTransaction *trans) +@@ -1692,27 +1777,15 @@ nsHttpConnectionMgr::ProcessNewTransaction(nsHttpTransaction *trans) "Sticky Connection Not In Active List"); trans->SetConnection(nullptr); rv = DispatchTransaction(ent, trans, conn); @@ -433,7 +441,7 @@ index 133c301..872d505 100644 } -@@ -2311,13 +2376,37 @@ nsHttpConnectionMgr::OnMsgSpeculativeConnect(int32_t, void *param) +@@ -2311,13 +2384,37 @@ nsHttpConnectionMgr::OnMsgSpeculativeConnect(int32_t, void *param) if (preferredEntry) ent = preferredEntry; @@ -472,21 +480,22 @@ index 133c301..872d505 100644 nsHttpConnectionMgr::nsConnectionHandle::IsPersistent() { return mConn->IsPersistent(); -@@ -2852,9 +2941,12 @@ nsConnectionEntry::nsConnectionEntry(nsHttpConnectionInfo *ci) +@@ -2852,9 +2949,13 @@ nsConnectionEntry::nsConnectionEntry(nsHttpConnectionInfo *ci) { NS_ADDREF(mConnInfo); if (gHttpHandler->GetPipelineAggressive()) { - mGreenDepth = kPipelineUnlimited; -+ // Randomize the pipeline depth (3..32) ++ // Randomize the pipeline depth (3..12) + mGreenDepth = gHttpHandler->GetMaxOptimisticPipelinedRequests() -+ + rand() % gHttpHandler->GetMaxPipelinedRequests(); ++ + rand() % (gHttpHandler->GetMaxPipelinedRequests() ++ - gHttpHandler->GetMaxOptimisticPipelinedRequests()); mPipelineState = PS_GREEN; } + mInitialGreenDepth = mGreenDepth; memset(mPipeliningClassPenalty, 0, sizeof(int16_t) * nsAHttpTransaction::CLASS_MAX); } -@@ -2892,8 +2984,9 @@ nsConnectionEntry::OnPipelineFeedbackInfo( +@@ -2892,8 +2993,9 @@ nsConnectionEntry::OnPipelineFeedbackInfo( LOG(("Transaction completed at pipeline depth of %d. Host = %s\n", depth, mConnInfo->Host())); @@ -498,7 +507,7 @@ index 133c301..872d505 100644 } nsAHttpTransaction::Classifier classification; -@@ -2921,6 +3014,11 @@ nsConnectionEntry::OnPipelineFeedbackInfo( +@@ -2921,6 +3023,11 @@ nsConnectionEntry::OnPipelineFeedbackInfo( mPipelineState, mConnInfo->Host())); mPipelineState = PS_RED; mPipeliningPenalty = 0;

1 0

[tor/master] socks5 will ask for username/password if we offer it
by arma＠torproject.org 11 Apr '13

11 Apr '13

commit d028c005da8e61f705aff751b5236adf983b310a Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Apr 11 02:53:26 2013 -0400 socks5 will ask for username/password if we offer it Commit a264c4fe made the socks5 server prefer auth 2 if it's offered, but it didn't update the unit test to expect it. --- src/test/test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/test/test.c b/src/test/test.c index 0b55f7b..42aab4c 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -362,7 +362,7 @@ test_socks_5_unsupported_commands(void *ptr) test_eq(5, socks->socks_version); test_eq(2, socks->replylen); test_eq(5, socks->reply[0]); - test_eq(0, socks->reply[1]); + test_eq(2, socks->reply[1]); ADD_DATA(buf, "\x05\x03\x00\x01\x02\x02\x02\x01\x01\x01"); test_eq(fetch_from_buf_socks(buf, socks, get_options()->TestSocks, get_options()->SafeSocks), -1);

1 0

[tor/master] Merge branch 'maint-0.2.4'
by arma＠torproject.org 11 Apr '13

11 Apr '13

commit f2e7271dcad8a8a79fddd253e602c64297e691ad Merge: 7ed1af3 d028c00 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Apr 11 10:40:06 2013 -0400 Merge branch 'maint-0.2.4'

1 0

[tor/maint-0.2.4] socks5 will ask for username/password if we offer it
by arma＠torproject.org 11 Apr '13

11 Apr '13

commit d028c005da8e61f705aff751b5236adf983b310a Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Apr 11 02:53:26 2013 -0400 socks5 will ask for username/password if we offer it Commit a264c4fe made the socks5 server prefer auth 2 if it's offered, but it didn't update the unit test to expect it. --- src/test/test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/test/test.c b/src/test/test.c index 0b55f7b..42aab4c 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -362,7 +362,7 @@ test_socks_5_unsupported_commands(void *ptr) test_eq(5, socks->socks_version); test_eq(2, socks->replylen); test_eq(5, socks->reply[0]); - test_eq(0, socks->reply[1]); + test_eq(2, socks->reply[1]); ADD_DATA(buf, "\x05\x03\x00\x01\x02\x02\x02\x01\x01\x01"); test_eq(fetch_from_buf_socks(buf, socks, get_options()->TestSocks, get_options()->SafeSocks), -1);

1 0

[torbrowser/master] Update http pipelining prefs.
by mikeperry＠torproject.org 11 Apr '13

11 Apr '13

commit a71e62e5deaaa7297c528618cce12602f05d9019 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Apr 11 02:17:58 2013 -0700 Update http pipelining prefs. We need much lower timeout values than normal. --- build-scripts/config/pound_tor.js | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/build-scripts/config/pound_tor.js b/build-scripts/config/pound_tor.js index 1cbf0fd..8a82e4c 100644 --- a/build-scripts/config/pound_tor.js +++ b/build-scripts/config/pound_tor.js @@ -70,6 +70,8 @@ pref("browser.zoom.siteSpecific", false); pref("network.cookie.cookieBehavior", 1); pref("security.enable_tls_session_tickets", false); pref("network.http.spdy.enabled", false); // Stores state and may have keepalive issues (both fixable) +pref("network.http.spdy.enabled.v2", false); // Seems redundant, but just in case +pref("network.http.spdy.enabled.v3", false); // Seems redundant, but just in case // Proxy and proxy security pref("network.proxy.socks", "127.0.0.1"); @@ -99,6 +101,8 @@ pref("security.ssl.enable_false_start", true); pref("network.http.keep-alive.timeout", 20); pref("network.http.connection-retry-timeout", 0); pref("network.http.max-persistent-connections-per-proxy", 256); +pref("network.http.pipelining.reschedule-timeout", 15000); +pref("network.http.pipelining.read-timeout", 60000); // Hacked pref: Now means "Attempt to pipeline at least this many requests together" pref("network.http.pipelining.max-optimistic-requests", 3);

1 0

[torbrowser/master] Update pipeline patch description.
by mikeperry＠torproject.org 11 Apr '13

11 Apr '13

commit a241fb26e00f804f954d510dd52c1e8ca67c99b1 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Apr 11 02:34:31 2013 -0700 Update pipeline patch description. --- ...ize-HTTP-request-order-and-pipeline-depth.patch | 33 +++++++++++++++----- 1 files changed, 25 insertions(+), 8 deletions(-) diff --git a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch index a5d2957..cb29e76 100644 --- a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch +++ b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch @@ -1,23 +1,40 @@ -From a88adc5c3000c3e2a18b1065da77dd83d2b3ae7b Mon Sep 17 00:00:00 2001 +From 7b340f34e429a4cb3407f838b4d414a671668419 Mon Sep 17 00:00:00 2001 From: Mike Perry <mikeperry-git(a)torproject.org> Date: Tue, 4 Dec 2012 17:38:51 -0800 Subject: [PATCH 17/28] Randomize HTTP request order and pipeline depth. -This is an experimental defense against +This is an experimental defense against Website Traffic Fingerprinting: http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf See: https://blog.torproject.org/blog/experimental-defense-website-traffic-finge… -This defense has been improved since that blog post to additionally randomize -the order and concurrency of non-pipelined HTTP requests. +This patch is different from the approach described in that post, as well as +the the 10.x ESR patch, as the pipelining code has changed significantly +between the time of writing of that post and Firefox 17. -This patch is also different from the 10.x ESR patch, as the pipelining -code has changed significantly. +The main control nob for this patch is now the about:config pref +"network.http.pipelining.max-optimistic-requests". The value of that pref +represents the minimum number of pipelined requests we will attempt to batch +together. -This patch may have some minor impact on SPDY request order, but the SPDY +The total outstanding pipeline size is randomized between that value and +"network.http.pipelining.maxrequests" on a per-host basis. + +Care must be taken when evaluating this defense, as pipeline behavior is +extremely sensitive to browser performance. In fact, a debug build alone is +enough to significantly impair request availability to the pipeline (due +slower document parsing and rendering). For this reason, we provide two +separate debug log defines. For most evaluation circumstances, you want to +define only WTF_TEST in an optimized build to only log request order and +combination behavior. + +This patch may also have some minor impact on SPDY request order, but the SPDY implementation has not been altered directly. It has several stream queues -that may also benefit from reordering. +that may also benefit from reordering and batching, as well as a more compact +request representation that will allow more requests to be packed inside Tor +cells. If you have interest in evaluating SPDY in a study of Website Traffic +Fingerprinting, please contact me. --- netwerk/protocol/http/nsHttpConnectionMgr.cpp | 288 +++++++++++++++++-------- netwerk/protocol/http/nsHttpConnectionMgr.h | 15 +-

1 0

[torbrowser/master] Merge branch 'maint-2.4'
by mikeperry＠torproject.org 11 Apr '13

11 Apr '13

commit 6269eee11a5b6208a2fa51d9d11651fc4c1d4064 Merge: 75ca11a a241fb2 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Apr 11 02:35:25 2013 -0700 Merge branch 'maint-2.4' build-scripts/config/pound_tor.js | 4 ++ ...ize-HTTP-request-order-and-pipeline-depth.patch | 33 +++++++++++++++----- 2 files changed, 29 insertions(+), 8 deletions(-)

1 0

[torbrowser/maint-2.4] Update pipeline patch description.
by mikeperry＠torproject.org 11 Apr '13

11 Apr '13

commit a241fb26e00f804f954d510dd52c1e8ca67c99b1 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Apr 11 02:34:31 2013 -0700 Update pipeline patch description. --- ...ize-HTTP-request-order-and-pipeline-depth.patch | 33 +++++++++++++++----- 1 files changed, 25 insertions(+), 8 deletions(-) diff --git a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch index a5d2957..cb29e76 100644 --- a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch +++ b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch @@ -1,23 +1,40 @@ -From a88adc5c3000c3e2a18b1065da77dd83d2b3ae7b Mon Sep 17 00:00:00 2001 +From 7b340f34e429a4cb3407f838b4d414a671668419 Mon Sep 17 00:00:00 2001 From: Mike Perry <mikeperry-git(a)torproject.org> Date: Tue, 4 Dec 2012 17:38:51 -0800 Subject: [PATCH 17/28] Randomize HTTP request order and pipeline depth. -This is an experimental defense against +This is an experimental defense against Website Traffic Fingerprinting: http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf See: https://blog.torproject.org/blog/experimental-defense-website-traffic-finge… -This defense has been improved since that blog post to additionally randomize -the order and concurrency of non-pipelined HTTP requests. +This patch is different from the approach described in that post, as well as +the the 10.x ESR patch, as the pipelining code has changed significantly +between the time of writing of that post and Firefox 17. -This patch is also different from the 10.x ESR patch, as the pipelining -code has changed significantly. +The main control nob for this patch is now the about:config pref +"network.http.pipelining.max-optimistic-requests". The value of that pref +represents the minimum number of pipelined requests we will attempt to batch +together. -This patch may have some minor impact on SPDY request order, but the SPDY +The total outstanding pipeline size is randomized between that value and +"network.http.pipelining.maxrequests" on a per-host basis. + +Care must be taken when evaluating this defense, as pipeline behavior is +extremely sensitive to browser performance. In fact, a debug build alone is +enough to significantly impair request availability to the pipeline (due +slower document parsing and rendering). For this reason, we provide two +separate debug log defines. For most evaluation circumstances, you want to +define only WTF_TEST in an optimized build to only log request order and +combination behavior. + +This patch may also have some minor impact on SPDY request order, but the SPDY implementation has not been altered directly. It has several stream queues -that may also benefit from reordering. +that may also benefit from reordering and batching, as well as a more compact +request representation that will allow more requests to be packed inside Tor +cells. If you have interest in evaluating SPDY in a study of Website Traffic +Fingerprinting, please contact me. --- netwerk/protocol/http/nsHttpConnectionMgr.cpp | 288 +++++++++++++++++-------- netwerk/protocol/http/nsHttpConnectionMgr.h | 15 +-

1 0

[torbrowser/maint-2.4] Update http pipelining prefs.
by mikeperry＠torproject.org 11 Apr '13

11 Apr '13

commit a71e62e5deaaa7297c528618cce12602f05d9019 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Apr 11 02:17:58 2013 -0700 Update http pipelining prefs. We need much lower timeout values than normal. --- build-scripts/config/pound_tor.js | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/build-scripts/config/pound_tor.js b/build-scripts/config/pound_tor.js index 1cbf0fd..8a82e4c 100644 --- a/build-scripts/config/pound_tor.js +++ b/build-scripts/config/pound_tor.js @@ -70,6 +70,8 @@ pref("browser.zoom.siteSpecific", false); pref("network.cookie.cookieBehavior", 1); pref("security.enable_tls_session_tickets", false); pref("network.http.spdy.enabled", false); // Stores state and may have keepalive issues (both fixable) +pref("network.http.spdy.enabled.v2", false); // Seems redundant, but just in case +pref("network.http.spdy.enabled.v3", false); // Seems redundant, but just in case // Proxy and proxy security pref("network.proxy.socks", "127.0.0.1"); @@ -99,6 +101,8 @@ pref("security.ssl.enable_false_start", true); pref("network.http.keep-alive.timeout", 20); pref("network.http.connection-retry-timeout", 0); pref("network.http.max-persistent-connections-per-proxy", 256); +pref("network.http.pipelining.reschedule-timeout", 15000); +pref("network.http.pipelining.read-timeout", 60000); // Hacked pref: Now means "Attempt to pipeline at least this many requests together" pref("network.http.pipelining.max-optimistic-requests", 3);

1 0