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 10:25:33 -0500
Message-ID: <CANufG2OzwkbVtaUwvdDLmSY1=3preyxu5U4=OWN_nmYumzQ7Rg@mail.gmail.com>
To: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
Are any user agents other than IE8+ currently implementing or have
implemented XHR2 timeout?

https://bugs.webkit.org/show_bug.cgi?id=74802

I have a couple of things I wanted to question, which may or may not result
in clarification in the spec.


   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?
   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.
    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?
   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.

Thanks,
Jarred
Received on Wednesday, 21 December 2011 15:26:24 GMT

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