22228 2013-05-31 11:40:45 +0000 Clarification of timeout attribute late overrides 2014-10-15 17:14:21 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC All RESOLVED FIXED P2 normal --- 1 dominik.rottsches annevk bugs caitpotter88 glenn mike Ms2ger public-webapps w3c public-webapps-bugzilla oldest_to_newest 88508 0 dominik.rottsches 2013-05-31 11:40:45 +0000 Section 4.6.3. - "the timeout attribute" non-normatively explains "Can be set to a time in milliseconds. When set to a non-zero value will cause fetching to terminate after the given time has passed." Later sections "4.6.7 Infrastructure for the send() method" normatively specify: "If timeout is not 0 and since the request started the amount of milliseconds specified by timeout has passed" This implicitly does not rule out the situation where a timeout is set for an XHR first, then send() is called on it, and then the timeout attribute is updated to a new value, either shorter, or longer. A shorter value leading to an earlier timeout, a longer value giving the request more time to complete. Let's call this situation a "late timeout override". I would like to see clarification on whether the spec authors expect the UA to support such late overrides or whether a late timeout attribute override should have no effect. My experience from trying to implement this on Blink shows that it would lead to layering violations in the loading code. After the request is sent out, Blink currently has no means of updating loader parameters to update the timeout and hence updating the timeout timer to for example fire and abort the request earlier. While it's feasible to refactor Blink to allow this, I would like to raise the question whether the late timeout override behavior is desirable and intended. Similar semantics are achieved with aborting the request, reconfiguring a new timeout value, sending it out again. 88510 1 bugs 2013-05-31 11:54:31 +0000 The late timeout override is intended. It is useful if some data has been loaded and one wants to try to finish the load. FYI, in Gecko all the XHR timeout handling happens outside/above the network library. 88515 2 glenn 2013-05-31 13:24:18 +0000 See the note at http://xhr.spec.whatwg.org/#dom-xmlhttprequest-timeout: "This implies that the timeout attribute can be set while fetching is in progress. If that occurs it will still be measured relative to the start of fetching." 93116 3 annevk 2013-09-06 15:54:24 +0000 Seems clear enough, especially with the note. 107858 4 Ms2ger 2014-06-16 13:46:39 +0000 This confused #servo too. 113218 5 annevk 2014-10-15 17:14:21 +0000 https://github.com/whatwg/xhr/commit/2677cc2e0fe79d290437c3ea9ff370a5d795294b Sorry for taking so long in fixing this regression.