timeout interceptor does not set the timeout value on the XMLHttpRequest about rest HOT 3 CLOSED

@DaniHaag I'm curious, what caused you to notice this behavior? It was intentional to not explicitly set the timeout attribute on the XHR object. One of the fun aspects of rest.js is that we try to decouple the client engines from interceptors in order to keep the interceptors portable across different engines; not all engines are cancelable. For timeout in particular, the physical timeout is managed within the interceptor, which then invokes request.cancel(), https://github.com/cujojs/rest/blob/master/interceptor/timeout.js#L41-L43, the cancel method will attempt to abort the XHR, https://github.com/cujojs/rest/blob/master/client/xhr.js#L97-L101, instead of having it hang open.

There may be a bug in the cancel/abort behavior if it wasn't working in your situation.

from rest.

@scothis: The issue is only reproducable on on remote system behind an IHS (Apache) proxy. The requests there have a very high latency and for some reasons the connection is dropped for some of the requests. IE8 was the only browser not cancelling the requests in this case. After the first dropped request I did not see any more requests on a packet sniffier, that I locally installed. Unfortunately I can not mock the behavior.

from rest.

@DaniHaag I'm going to close this issue. I really don't want to complicate the client.

In this case, I'd recommend creating a custom interceptor that sets request.mixins.timeout to the value of request.timeout. The request.mixins are mixed onto the XHR object, thus setting the timeout.

This is fine if you know you are in an XHR environment, I just can't do it globally since the behavior would break with other clients. Please continue to comment here if you run into issues.

from rest.