Bug 614677 - Connection is reset message appears intermittently
Bug 614950 - Connections stall occasionally after 592284 landed
A couple of follow-on changes to 592284 rolled together to prevent
diff conflicts
1] Set the securitycallback information for unused speculative
connections in the connection manager to be the new cloned connection
rather than the one they originated on. (613977)
2] When adding unused speculative connections to the connection
manager, due so with a short timeout (<= 5 seconds) as some servers
get grumpy if they haven't seen a request in that time. Most will
close the connection, but some will just sit there quietly and RST
things when the connection is used - so if you don't use the
connection quickly don't use it at all. This is probably a L4 load
balancer issue, actually. Mozillazine illustrates the
problem. Connections are made in bursts anyhow, so the reuse optimization is
likely still quite useful. (614677 and 614950)
3] mark every connection in the connection manager persistent
conneciton pool as "reused". This allows the transaction to be
restarted if a RST is recvd upon sending the requests (see #2) - with
the conservative timeout this is now a rare event, but still possible
so recovery is the right thing to do. (614677 and 614950)
4] obtain an nshttpconnection object from the connection manager,
subject to the max connection constraints, at the same time as
starting the backup conneciton. If we defer that until recycling time
the exceeded limits of the SocketService can cause problems for other
connections.
also re-enables the syn retry feature by default.
r+ honzab
Can be turned on by setting preference
network.websocket.override-security-block. Websockets can only be used if
override-security-block and network.websocket.enabled are both set to true.
At a future time, with a more secure websocket protocol, the
override-security-block preference can be removed.
This action is based on the security concern over an HTTP cache
poisoning attack as described in
http://www.adambarth.com/experimental/websocket.pdf
Losing a TCP SYN requires a long painful (typically 3 second) delay
before being retried. This patch creates a second parallel connection
attempt for any nsHttpConnection which has not become writable before
a timeout occurs.
If you assume .5% packet loss, this converts a full 3 second delay
from a 1 in 200 event into a 1 in 40,000 event.
Whichever connection establishes itself first is used. If another one
has been started and it does connect before the one being used is
closed then the extra one is handed to the connection manager for use
by a different transaction - essentially a persistent connection with
0 previous transactions on it. (Another way to think about is
pre-fetching a 3WHS on a high latency connection).
The pref network.http.connection-retry-timeout controls the amount of
time in ms to wait for success on the initial connection before beginning
the second one. Setting it to 0 disables the parallel connection, the
default is 250.
