Skip to content
This repository has been archived by the owner on Jun 7, 2019. It is now read-only.

timeout interceptor does not set the timeout value on the XMLHttpRequest #64

Closed
DaniHaag opened this issue Mar 31, 2014 · 3 comments
Closed

Comments

@DaniHaag
Copy link

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.

@scothis
Copy link
Member

scothis commented Mar 31, 2014

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

@DaniHaag
Copy link
Author

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

@scothis
Copy link
Member

scothis commented Jun 29, 2014

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

@scothis scothis closed this as completed Jun 29, 2014
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants