Fix: Ajax.Request considers timeout/connection close to be a success. #100
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Browsers will return a 0 status when the connection is broken off or times out ... but this is also used to indicate success. Checking for an empty header string seems to be a portable workaround.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey, it's quite possible to never run into this, but the
Ajax.Requestobject doesn't seem to handle the case when a connection times out. An exception is thrown when the request is made synchronously, but even then theonSuccesscallback will trigger.The
XMLHTTPRequestspecification, at least in its older incarnation, doesn't really account for connection errors; testing for an empty header string is a plausible workaround that seems to work on all browsers.Note that the included unit test is rather clunky, as it actually waits for a timeout on a synchronous request. The failure can also be triggered by making the webserver close the connection (without sending any response), but I've been unable to cajole Webrick into doing that.