Skip to content
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

Closed
halter73 opened this issue Sep 5, 2013 · 1 comment
Closed

Hub calls should fail if request's response is 3xx redirect #2506

halter73 opened this issue Sep 5, 2013 · 1 comment
Assignees
Milestone

Comments

@halter73
Copy link
Member

halter73 commented Sep 5, 2013

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

setInterval(function() { // trivial example
     $.connection.myHub.server.getLatest().done(function(someResp) {
          updateSomething(someResp);
     }).fail(function() { 
          alert('bang'); 
     });
}, 90000); // 90 seconds

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

@ghost 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
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
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 ghost assigned gustavo-armenta Nov 6, 2013
@gustavo-armenta
Copy link
Contributor

Ran automated tests "Response redirection facts"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants