W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [XHR2] timeout

From: Jarred Nicholls <jarred@webkit.org>
Date: Wed, 21 Dec 2011 14:41:41 -0500
Message-ID: <CANufG2MXcqBt8dknLcYB6pkf+mi=5vwv5FuBuK8aG6sLK7E3Dw@mail.gmail.com>
To: olli@pettay.fi
Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Wed, Dec 21, 2011 at 2:15 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
>
>> On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay <Olli.Pettay@helsinki.fi
>> <mailto:Olli.Pettay@helsinki.**fi <Olli.Pettay@helsinki.fi>>> wrote:
>>
>>    On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
>>
>>        On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren
>>        <annevk@opera.com <mailto:annevk@opera.com>
>>        <mailto:annevk@opera.com <mailto:annevk@opera.com>>> wrote:
>>
>>            On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
>>        <jarred@webkit.org <mailto:jarred@webkit.org>
>>        <mailto:jarred@webkit.org <mailto:jarred@webkit.org>>> wrote:
>>
>>                1. The spec says the timeout should fire after the
>> specified
>>                number of
>>
>>                milliseconds has elapsed since the start of the request.  I
>>                presume this means literally that, with no bearing on
>>        whether or
>>                not data is coming over the wire?
>>
>>
>>            Right.
>>
>>
>>                2. Given we have progress events, we can determine that
>>        data is
>>                coming
>>
>>                over the wire and react accordingly (though in an ugly
>>        fashion,
>>                semantically).  E.g., the author can disable the timeout or
>>                increase the timeout.  Is that use case possible?  In other
>>                words, should setting the timeout value during an active
>>        request
>>                reset the timer?  Or should the
>>                timer always be basing its elapsed time on the start
>>        time of the
>>                request + the specified timeout value (an absolute point
>>        in the
>>                future)?  I
>>                understand the language in the spec is saying the
>>        latter, but
>>                perhaps could use emphasis that the timeout value can be
>>        changed
>>                mid-request.
>>
>>
>>        http://dvcs.w3.org/hg/xhr/rev/**____2ffc908d998f<http://dvcs.w3.org/hg/xhr/rev/____2ffc908d998f>
>>        <http://dvcs.w3.org/hg/xhr/**rev/__2ffc908d998f<http://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f>
>> >
>>
>>
>>        <http://dvcs.w3.org/hg/xhr/__**rev/2ffc908d998f<http://dvcs.w3.org/hg/xhr/__rev/2ffc908d998f>
>>        <http://dvcs.w3.org/hg/xhr/**rev/2ffc908d998f<http://dvcs.w3.org/hg/xhr/rev/2ffc908d998f>
>> >>
>>
>>
>>        Brilliant, no doubts about it now ;)
>>
>>
>>
>>
>>                Furthermore, if the timeout value is set to a value > 0
>>        but less
>>                than the original value, and the elapsed time is past the
>>                (start_time + timeout), do we fire the timeout or do we
>>                effectively disable it?
>>
>>
>>            The specification says "has passed" which seems reasonably
>>        clear to
>>            me. I.e. you fire it.
>>
>>
>>        Cool, agreed.
>>
>>
>>
>>                3. Since network stacks typically operate w/ timeouts
>>        based on data
>>
>>                coming over the wire, what about a different timeout
>>        attribute
>>                that fires a timeout event when data has stalled, e.g.,
>>                dataTimeout?  I think this type of timeout would be more
>>                desirable by authors to have control over for
>>                async requests, since today it's kludgey to try and
>> simulate
>>                that with
>>                timers/progress events + abort().  Whereas with the
>>        overall request
>>                timeout, library authors already simulate that easily with
>>                timers + abort() in the async context.  For sync requests
>> in
>>                worker contexts, I can see a dataTimeout as being heavily
>>                desired over a simple request timeout.
>>
>>
>>            So if you receive no octet for dataTimeout milliseconds you
>>        get the
>>            timeout event and the request terminates? Sounds reasonable.
>>
>>
>>        Correct.  Same timeout exception/event shared with the request
>>        timeout
>>        attribute, and similar setter/getter steps; just having that
>>        separate
>>        criteria for triggering it.
>>
>>
>>
>>    Is there really need for dataTimeout? You could easily use progress
>>    events and .timeout to achieve similar functionality.
>>    This was the reason why I originally asked that .timeout can be set
>>    also when XHR is active.
>>
>>    xhr.onprogress = function() {
>>      this.timeout += 250;
>>    }
>>
>>
>> Then why have timeout at all?  Your workaround for a native dataTimeout
>> is analogous to using a setTimeout + xhr.abort() to simulate the request
>> timeout.
>>
>> I can tell you why I believe we should have dataTimeout in addition to
>> timeout:
>>
>>  1. Clean code, which is better for authors and the web platform.  To
>>
>>    achieve the same results as a native dataTimeout, your snippet would
>>    need to be amended to maintain the time of the start of the request
>>    and calculate the difference between that and the time the progress
>>    event fired + your timeout value:
>>
>>    xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout;
>>
>>    A dataTimeout is a buffered timer that's reset on each octet of data
>>    that's received; a sliding window of elapsed time before timing out.
>>      Every time the above snippet is calculated, it becomes more and
>>    more erroneous; the margin of error increases because of time delays
>>    of JS events being dispatched, etc.
>>  2. Synchronous requests in worker contexts have no way to simulate this
>>
>>    behavior, for request timeouts nor for data timeouts.  Most of the
>>    network stacks in browsers have a default data timeout (e.g. 10
>>    seconds) but allowing the author to override that timeout has value
>>    I'd think.  With that said... synchronous requests? What are those? :)
>>
>>  Ah, sync XHR in workers is a good case.
> So dataTimeout would fire if no data has been received in the
> dataTimeout period? And receiving some data would basically restart the
> timer?


Yeah that's the idea.  Maybe it's valuable for the web platform, maybe it's
not.


>
>
>
>
>>
>>    (timeout is being implemented in Gecko)
>>
>>
>> Awesome!
>>
>>
>>
>>
>>    -Olli
>>
>>
>>
>>
>>
>>
>>
>>
>>            --
>>            Anne van Kesteren
>>        http://annevankesteren.nl/
>>
>>
>>        Thanks,
>>        Jarred
>>
>>
>>
>>
>
Received on Wednesday, 21 December 2011 19:42:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT