New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hub calls should fail if request's response is 3xx redirect #2506
Comments
ghost
assigned NTaylorMullen
Sep 18, 2013
NTaylorMullen
added a commit
that referenced
this issue
Oct 24, 2013
- When an error occurs, instead of throwing ot the window object we now handle it appropriately. #2506
NTaylorMullen
added a commit
that referenced
this issue
Oct 24, 2013
…rifying parse responses is handled correctly when it throws. - Also added the wrapStart functionality to the JS test utilities #2506
NTaylorMullen
added a commit
that referenced
this issue
Oct 24, 2013
… error handler and stop the connection. #2506
NTaylorMullen
added a commit
that referenced
this issue
Oct 24, 2013
- If transports fail to parse a response while in connecting they will now fall back. - Centralized this logic in the common.js #2506
NTaylorMullen
added a commit
that referenced
this issue
Oct 24, 2013
…hile connecting indeed do fall back. - Also fixed some long polling logic #2506
NTaylorMullen
added a commit
that referenced
this issue
Nov 6, 2013
- When an error occurs, instead of throwing ot the window object we now handle it appropriately. #2506
NTaylorMullen
added a commit
that referenced
this issue
Nov 6, 2013
…rifying parse responses is handled correctly when it throws. - Also added the wrapStart functionality to the JS test utilities #2506
NTaylorMullen
added a commit
that referenced
this issue
Nov 6, 2013
… error handler and stop the connection. #2506
NTaylorMullen
added a commit
that referenced
this issue
Nov 6, 2013
- If transports fail to parse a response while in connecting they will now fall back. - Centralized this logic in the common.js #2506
NTaylorMullen
added a commit
that referenced
this issue
Nov 6, 2013
…hile connecting indeed do fall back. - Also fixed some long polling logic #2506
ghost
assigned gustavo-armenta
Nov 6, 2013
Ran automated tests "Response redirection facts" |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The client library should treat requests with responses with redirect codes (e.g. 302/301) as failed.
This is problematic in situations where browser sessions expire but the client library is still trying to call back -- e.g. via timer
The observed behavior is that the request is made to the server, the server responds 302, the browser then does the redirect and requests the login page, but neither done() or fail() are called.
#2106
The text was updated successfully, but these errors were encountered: