This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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."
Seems clear enough, especially with the note.
This confused #servo too.
https://github.com/whatwg/xhr/commit/2677cc2e0fe79d290437c3ea9ff370a5d795294b Sorry for taking so long in fixing this regression.