[Bug 22228] New: Clarification of timeout attribute late overrides


            Bug ID: 22228
           Summary: Clarification of timeout attribute late overrides
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XHR
          Assignee: annevk@annevk.nl
          Reporter: dominik.rottsches@intel.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

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.

You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 31 May 2013 11:40:46 UTC