Fix: Ajax.Request considers timeout/connection close to be a success. #100

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@michielbuddingh

Hey, it's quite possible to never run into this, but the Ajax.Request object 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 the onSuccess callback will trigger.

The XMLHTTPRequest specification, 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.

onSuccess is no longer triggered on timeout/reset
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.
@rajuGT

This comment has been minimized.

Show comment Hide comment
@rajuGT

rajuGT Jun 4, 2013

yes, i have seen this bug. when session expired, firebug reports 302 temporarily moved but when i check the response status it says 0 and on302 doesnt work but on0 works. I havent seen your patch(code), hope it solves this issue.

rajuGT commented on bdbad95 Jun 4, 2013

yes, i have seen this bug. when session expired, firebug reports 302 temporarily moved but when i check the response status it says 0 and on302 doesnt work but on0 works. I havent seen your patch(code), hope it solves this issue.

This comment has been minimized.

Show comment Hide comment
@michielbuddingh

michielbuddingh Jun 5, 2013

Owner

rajuGT, what you describe is not necessarily a bug. As per the latest version of the XMLHTTPRequest1 spec , the transport request isn't supposed to return an error, provided the redirect location is legal.

It's quite possible that prototype handles redirects incorrectly, but it warrants separate investigation. And this patch won't fix it.

rajuGT, what you describe is not necessarily a bug. As per the latest version of the XMLHTTPRequest1 spec , the transport request isn't supposed to return an error, provided the redirect location is legal.

It's quite possible that prototype handles redirects incorrectly, but it warrants separate investigation. And this patch won't fix it.

This comment has been minimized.

Show comment Hide comment
@rajuGT

rajuGT Jun 6, 2013

@michielbuddingh , Thanks for the information.

@michielbuddingh , Thanks for the information.

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