Aborted AJAX requests are considered as successfull in 1.4

[smira]

It looks like in changeset [6432] (ticket #4764) while fixing 304 error response for Opera handling of aborted XMLHTTPRequests has been broken.

The suspicious change is change to httpSuccess handler for $.ajax, treating status of zero as successful. For XMLHTTPRequests status of zero means aborted requests.

This is the patch that "fixes" this issue:

Index: public/javascripts/jquery-1.4.js
===================================================================
--- public/javascripts/jquery-1.4.js	(revision 22310)
+++ public/javascripts/jquery-1.4.js	(working copy)
@@ -%ld,%ld +%ld,%ld @@
 			return !xhr.status && location.protocol === "file:" ||
 				// Opera returns 0 when status is 304
 				( xhr.status >= 200 && xhr.status < 300 ) ||
-				xhr.status === 304 || xhr.status === 1223 || xhr.status === 0;
+				xhr.status === 304 || xhr.status === 1223;
 		} catch(e) {}
 
 		return false;

Maybe there's a better way to fix that including mentioned Opera bug

[arj]

I can confirm that this fixes bug #5872. Please someone look it through. Can't use 1.4.2 before this is fixed.

[cardmeister]

I've recently run into this. Here is some more information which may help. This information is based on an ajax request with for JSON.

I first discovered this when a script in IE7 fired the success handler on abort of the ajax request. This behavior does not exist in Firefox nor Chrome.

After tracing, I found the code noted above and I saw that 0 was being treated as success. I looked further to see why the success handler we NOT being fired in FF.

I found that in httpData(), data is an empty string in FF whereas it is undefined in IE. As a result, the following condition is entered on a FF execution and the response is considered a failure due to a parse error.

httpData: function( xhr, type, s ) {
		var ct = xhr.getResponseHeader("content-type") || "",
			xml = type === "xml" || !type && ct.indexOf("xml") >= 0,
			data = xml ? xhr.responseXML : xhr.responseText;

...


// The filter can actually parse the response
		if ( typeof data === "string" ) {
			// Get the JavaScript object, if JSON is used.
			if ( type === "json" || !type && ct.indexOf("json") >= 0 ) {
				data = jQuery.parseJSON( data );

...

In the case where data is undefined (IE), all parse conditions are skipped in httpData(), thus data is returned as undefined and is continued to be treated as "success".

[cardmeister]

This code can be used to produce this condition:

function goTest()
  {
    var xhr = $.ajax({
      url: 'test.php',
      dataType:'json',
      data: {term:'b'},
      success: function (data, textStatus)
      {
        alert(data + '|' + textStatus);
      }
    });

    xhr.abort();

  }
  $(document).ready(goTest);

[nic_bellamy]

I've just uploaded a "works for me" patch to ticket #5968 that uses browser sniffing to only apply the 304 workaround when using Opera, so it doesn't break all the other browsers handling of refused connections.

See #5968 for the patch.

[dmethvin]

See also closed dups #5968 and #5872.

[nic_bellamy]

Fix jQuery.ajax() success function being called when HTTP connection refused.

[nic_bellamy]

I've just added the patch here too, to save digging around in the closed duplicate tickets.

[dlee]

I'm surprised by the behavior cardmeister is seeing. I'm getting the exact opposite results. An ajax call to a server that's down results in the error callback in IE7/8, but results in the success callback in Firefox/Chrome.

[john]

Fixed  http://github.com/jquery/jquery/commit/ba9e0fc177841bd74cc5ea4e52f09cd87d747bf5

[addyosmani]

#6127 is a duplicate of this ticket.

[anonymous]

Using jquery 1.6.4, same problem!