You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 7, 2019. It is now read-only.
when I use the timeout interceptor in the with the xhr client (XMLHttpRequest) it does not register the timeout property on the request.
So if a request takes very long and the promise returns, it still leaves the XMLHttpRequest open. In this case the browser will not have a timeout at all. In my case this caused IE8 to not send any requests anymore.
IMO the browser should be aware of the intended timeout anyways.
The text was updated successfully, but these errors were encountered:
@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.
@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.
@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.
when I use the timeout interceptor in the with the xhr client (XMLHttpRequest) it does not register the timeout property on the request.
So if a request takes very long and the promise returns, it still leaves the XMLHttpRequest open. In this case the browser will not have a timeout at all. In my case this caused IE8 to not send any requests anymore.
IMO the browser should be aware of the intended timeout anyways.
The text was updated successfully, but these errors were encountered: