- From: Alberto Torres <notifications@github.com>
- Date: Mon, 14 Dec 2015 06:50:17 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
Received on Monday, 14 December 2015 14:50:50 UTC
@annevk I did exactly that increasing the timeout after an error. But imagine a file that takes more than a minute to be downloaded in a slow connection, with a minute of timeout. It ends taking twice as much time and bandwith! (even more when the timeout was half a minute). More than **abort**, we need **progress**. Having both we can detect stuck connections and restart them. Having just abort we can easily emulate the XHR timeout feature (to avoid downloading the same data several times). In other words: We need first a way to measure download progress. Then a way to abort the connection. Not necessarily exposed to JS, but just usable by the **timeout** and **deadline** implementations. Maybe we should split the issue in two? Timeout for stuck connections (not just slow ones) and deadline (if it's not downloaded in X time, I don't need it; a.k.a. XHR timeout). --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/20#issuecomment-164456033
Received on Monday, 14 December 2015 14:50:50 UTC