merge

.hgtags

@@ -496,3 +496,4 @@ bcc2770e21c125e0bab59141c51db9145aec068d 3.7.17-release
 9ecab4b0c7d8614767724a3422d3c1dca6bd4e4f 3.7.21-release
 bc61801f614022c920cb5c3df1d7d67a9561ce1f 3.7.22-release
 3be800e1afad9615442159e388d6d137be7b951e 3.7.23-release
+d3d0101e980ec95043e0af9b7903045d3bc447e4 3.7.24-release

indra/llcorehttp/_httpoprequest.cpp

@@ -623,8 +623,23 @@ HttpStatus HttpOpRequest::prepareRequest(HttpService * service)
 		// a handwave but bump the transfer timeout up by the pipelining
 		// depth to give some room.
 		//
+		// BUG-7698, BUG-7688, BUG-7694 (others).  Scylla and Charybdis
+		// situation.  Operating against a CDN having service issues may
+		// lead to requests stalling for an arbitrarily long time with only
+		// the CURLOPT_TIMEOUT value leading to a closed connection.  Sadly
+		// for pipelining, libcurl (7.39.0 and earlier, at minimum) starts
+		// the clock on this value as soon as a request is started down
+		// the wire.  We want a short value to recover and retry from the
+		// CDN.  We need a long value to safely deal with a succession of
+		// piled-up pipelined requests.
+		//
 		// *TODO:  Find a better scheme than timeouts to guarantee liveness.
-		xfer_timeout *= cpolicy.mPipelining;
+		// Progress on the connection is what we really want, not timeouts.
+		// But we don't have access to that and the request progress indicators
+		// (various libcurl callbacks) have the same problem TIMEOUT does.
+		//
+		// xfer_timeout *= cpolicy.mPipelining;
+		xfer_timeout *= 2L;
 	}
 	// *DEBUG:  Enable following override for timeout handling and "[curl:bugs] #1420" tests
 	// xfer_timeout = 1L;

indra/newview/VIEWER_VERSION.txt

-3.7.24
+3.7.25