Side navigation
#6060 closed bug (fixed)
Opened February 09, 2010 11:10AM UTC
Closed September 21, 2010 07:22PM UTC
Last modified March 13, 2012 11:58PM UTC
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 (10)
Changed March 09, 2010 12:46PM UTC by comment:1
Changed April 10, 2010 02:27AM UTC by comment:2
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".
Changed April 10, 2010 02:38AM UTC by comment:3
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);
Changed June 09, 2010 01:13AM UTC by comment:4
Changed June 23, 2010 09:17PM UTC by comment:6
I've just added the patch here too, to save digging around in the closed duplicate tickets.
Changed September 21, 2010 05:37PM UTC by comment:7
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.
Changed September 21, 2010 07:22PM UTC by comment:8
| milestone: | 1.4.2 → 1.4.3 |
|---|---|
| resolution: | → fixed |
| status: | new → closed |
| version: | 1.4.1 → 1.4.2 |
Changed February 03, 2012 01:31AM UTC by comment:10
Using jquery 1.6.4, same problem!
I can confirm that this fixes bug #5872. Please someone look it through. Can't use 1.4.2 before this is fixed.