This project is archived and is in readonly mode.

#645 ✓resolved
Kai Gülzau

Request timeout handling

Reported by Kai Gülzau | April 22nd, 2009 @ 09:33 AM | in 1.3.0 rc2 (closed)

It's very easy to use some request extension like mootimeout (http://code.google.com/p/mootime... to handle request timeouts.

BUT i think timeout handling is such an essential thing that it should be included in mootools core.

just my 2ct :)

Regards,

Kai Gülzau

Comments and changes to this ticket

  • Crystark

    Crystark February 4th, 2010 @ 07:51 AM

    I totally agree. How could such an essential feature be forgotten when the first Request class was released ? Is there any difficulties accompanying it ?

    Anyway, timeouts and retries should be a base option of the Request class to me... i think a lot of people would agree.

  • Fábio M. Costa

    Fábio M. Costa February 6th, 2010 @ 05:11 PM

    Hmmm agreed here.
    Lets just explain better, so ppl can understand what you guys are wanting (and you guys can confirm that this is what you want too, cause im not 100% sure).

    So, what's being requested is a timeout option for the Request object that will call an event (onTimeout) if the request takes more than the defined timeout (milliseconds) to return with the response.

    Correct?

    I agree this should go into core.

  • Kai Gülzau

    Kai Gülzau February 8th, 2010 @ 08:07 AM

    1+ :)

    I opt for setting the status code 408
    (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.9). before fireing onFailure/onTimeout.

    This way legacy onFailure code possibly doesn't have to be changed.

  • fakedarren

    fakedarren February 8th, 2010 @ 12:42 PM

    • State changed from “new” to “open”
    • Assigned user set to “fakedarren”
    • Milestone changed from 2.0 to 1.3.0 rc2
  • fakedarren

    fakedarren February 9th, 2010 @ 08:58 PM

    • Assigned user changed from “fakedarren” to “Christoph Pojer”

    Christoph, what do you think about this? The other frameworks have similar functionality.

  • Christoph Pojer

    Christoph Pojer February 10th, 2010 @ 02:47 PM

    • Milestone changed from 1.3.0 rc2 to 2.0
  • Crystark

    Crystark April 21st, 2010 @ 08:32 AM

    Might i add, Request.JSONP handles timeout. I don't really understand why Request wasn't updated so that timeouts would work in JSONP and all other Request extensions.
    Some usefull options that could be added to Request

    timeout: int (second or ms)
    autoRetries:int (number of retries that will be sent automatically on eahc timeout)
    onTimeout: function (function called on timeout)
    onRetry: function (function called on retry)

    And a function that would allow to retry manually. (autoRetries would just call the function)
    retry: function

    thanks anyway :)

  • Christoph Pojer

    Christoph Pojer August 4th, 2010 @ 11:38 PM

    • Assigned user changed from “Christoph Pojer” to “Fábio M. Costa”
    • Milestone order changed from “0” to “0”
  • Christoph Pojer

    Christoph Pojer September 4th, 2010 @ 11:26 AM

    • Milestone changed from 2.0 to 1.3.0 rc2
    • Assigned user changed from “Fábio M. Costa” to “w00fz”
    • Milestone order changed from “700” to “0”
  • w00fz

    w00fz September 4th, 2010 @ 04:46 PM

    • State changed from “open” to “resolved”

    Implemented in 1.3. This is going to be disabled by default and you really shouldn't use it with big files, unless you know it shouldn't be exceeding a certain timeout.

    Cheers.

  • Kai Gülzau

    Kai Gülzau September 6th, 2010 @ 11:55 AM

    • Milestone order changed from “18” to “0”

    If i got it right the request is not aborted automatically upon timeout.
    Request.JSONP for example does a cancel() and fires 'failure'.

    I personally would like something like this:

      timeout: function () {
        this.abort(); // cancel() without fire 'cancel'
        this.status = 408;
        this.failure();
        this.triggerEvent('timeout');
      }
    

    This way old error handlers possibly would also work for timeouts (due to status >= 400).

    Another point is to allow setting the timeout per send()
    for long living / recycled Request objects.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

Pages