Timeout for bad internet connection

[Maigre]

Hi there !
Thanks for your uploader, it's a really big help :)

The problem:
I try to upload big files over bad internet connection (chunks are usefull !)
but if my connection drop in the middle of the upload,
the ajax POST of the current chunk doesn't recieve answer from the server,
and it continue to wait... (regardless if the connection is back or not)
is it possible to set up a timeout on the ajax waiting,
so if the connection has dropped it start to retry (in case the connection is back)
and finally push an error if it is still impossible to reach the server
so the client can check his connection and then manually retry ?

Thanks !

Best Regards,

Thomas

[rnicholus]

If I were to add a request timeout, I would need to:

• ensure both XHR & iframe/form upload requests, along with all other (DELETE) requests use this timeout
• make this timeout configurable and optional

I think this timeout would be disabled by default. I'll look into this more in 3.5.

[Maigre]

Ok thanks,
i will dig it on my side and send you my ideas if i find interesting things.

Best Regards,

[rnicholus]

@Maigre Can you possibly tell me a little more about your situation? What sort of number are you thinking of using as your timeout value? How would you expect this timeout to work?

I am asking based on the following observations & facts:

• There is a timeout property on the XHR object, but this is apparently NOT supported in any webkit browsers (Chrome & Safari)
• The timeout property on the XHR object, where supported, apparently is reset whenever there is some activity between the client and server, even before the file/request has been completely sent and the server has sent a response.
• There is no native "timeout" property for form-based uploads. We have to resort to form submission for browsers that do not support the File API (IE9 and older).

In order to make this timeout work cross-browser, I'd have to code my own timeout support for webkit browsers. I'd also need to create some sort of a timeout for form-based uploads (in order to make this feature cross-browser), but I'm not sure it is possible to make it behave like the timeout property on the XHR object. This is due to the fact that there is no way for me to determine if the connection between the client and server is still active (or if the server is even receiving the request). I simply have to wait for the onload event on the associated iframe.

Thoughts?

[rnicholus]

Pushing this to 3.6, or until I receive more feedback on this request. If I don't receive any feedback within the next couple release cycles, I'll close this as "will not implement".

[rnicholus]

Moved to 3.7. If I don't get any feedback during work on 3.6, I will probably close this as "will not implement".

[rnicholus]

No response after a month, closing.

[rnicholus]

XHR timeouts are now supported in Chrome/Safari, so perhaps we should look into implementing this.

[rnicholus]

I'm going to look into this as part of 5.11.9, since network errors (particularly pulling the connection mid-upload) causes the upload to hang for a long time. That seems like a bug to me, and if we can make this less of an issue, even in a subset of browsers, that seems like a big win.

[rnicholus]

I think I now remember why I kicked this can down the road for so long. Setting a timeout on an XMLHttpRequest instance does not function as one would expect (or at least as I would expect). The clock starts ticking as soon as the request is sent. If the request does not complete before the timeout expires, the browser cancels the request. I would expect the request to timeout only if there is no HTTP traffic for a length of time equal to the timeout value.

The problem with the standardized behavior of XMLHttpRequest.timeout is that it may be very tricky to determine an appropriate and effective value. When you choose a timeout value, you have to consider that some internet connections are faster than others. For example, if you choose a timeout value of 5 seconds, with a chunk size of 5 MB, the request will always timeout for files being sent from a typical home internet connection with available upstream bandwidth of 4 Mbps, since each 5 MB chunk will take about 10 seconds to complete. But for faster connections, this timeout may be appropriate. A safe value may be ineffective since it probably has to be a fairly large one.

In light of this, I'm strongly considering abandonment of this "feature". Another option: advise integrators to set a reasonably high value, but this honestly seems like it may cause more problems than it solves. I'm open to input, but I'm putting this on hold for now.