#6060 closed bug (fixed)
Aborted AJAX requests are considered as successfull in 1.4
Reported by: | smira | Owned by: | |
---|---|---|---|
Priority: | Milestone: | 1.4.3 | |
Component: | ajax | Version: | 1.4.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
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
Attachments (1)
Change History (11)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
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".
comment:3 Changed 13 years ago by
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);
comment:4 Changed 13 years ago by
Changed 13 years ago by
Attachment: | 0001-Fix-jQuery.ajax-success-function-being-called-when-H.patch added |
---|
Fix jQuery.ajax() success function being called when HTTP connection refused.
comment:6 Changed 13 years ago by
I've just added the patch here too, to save digging around in the closed duplicate tickets.
comment:7 Changed 13 years ago by
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.
comment:8 Changed 13 years ago by
Milestone: | 1.4.2 → 1.4.3 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Version: | 1.4.1 → 1.4.2 |
I can confirm that this fixes bug #5872. Please someone look it through. Can't use 1.4.2 before this is fixed.