Bug Tracker

#7083 closed bug (worksforme)

Opened September 26, 2010 12:07AM UTC

Closed September 26, 2010 04:46AM UTC

Last modified September 26, 2010 10:59AM UTC

ifModified option - response status "notmodified" unreachable

Reported by: jthelen Owned by:
Priority: blocker Milestone: 1.4.3
Component: ajax Version: 1.4.2
Keywords: ifmodified, notmodified, lastmodified, etag Cc:
Blocked by: Blocking:
Description

Test case

$.ajax({url: 'http://example.com/whatever',
  ifModified: true,
  success: function(data, textStatus, xhr) {
  },
  error: function(xhr, textStatus) {
    alert(textStatus);
  }
});

Assume receiving a normal 304 response like this:

HTTP/1.1 304 Not Modified
Date: Sat, 25 Sep 2010 23:13:59 GMT
Server: Apache/2.2.11
Connection: Keep-Alive
Keep-Alive: timeout=5, max=99
ETag: "2800000010766f-1a84-49116a4d99f1d"

Expected result

Alert of "notmodified".

Actual result

Alerts always "error", never "notmodified".

Supposed cause

Looking at the ajax response handling code of jquery 1.4.2, tracked it down to this:

:
: line 5182 (onreadystatechange)

status = isTimeout === "timeout" ?
  "timeout" :
  !jQuery.httpSuccess( xhr ) ?
    "error" :
    s.ifModified && jQuery.httpNotModified(xhr, s.url ) ?
      "notmodified" :
      "success";

:
: line 5320 (httpSuccess)

return
  !xhr.status && location.protocol === "file:" ||
  ( xhr.status >= 200 && xhr.status < 300 ) ||
  xhr.status === 304 || xhr.status === 1223 ||
  xhr.status === 0;

Note that httpSuccess will always return true in our test case because of xhr.status === 304, resulting in status always being set to "error" and never reaching

  s.ifModified && jQuery.httpNotModified(xhr, s.url ) ?
    "notmodified" :
    "success";
Attachments (0)
Change History (2)

Changed September 26, 2010 04:46AM UTC by snover comment:1

resolution: → worksforme
status: new → closed

You are not reading that code properly. Returning true from httpSuccess means that the conditional moves to the right side of the : because of the boolean negation operator. jQuery ajax requests would be completely broken if your supposition were true.

I am not able to reproduce this issue. Testing with both If-Modified-Since and If-None-Match works properly across IE7+ Fx3.6+ Saf5, Chr6, O10.6+. I would recommend you post your full code to the jQuery Forum and ask for support there.

Changed September 26, 2010 10:59AM UTC by jthelen comment:2

Replying to [comment:1 snover]:

You are not reading that code properly...

Argl, mea culpa. You are absolutely right, of course.

I forgot about the right-to-left associativity of the ! operator, when not using explicit parantheses. I'm always thinking in left-to-right parantheses, wrongly interpreting as

(!xhr.status && location.protocol === "file:") ||
(xhr.status >= 200 && xhr.status < 300) ||
(xhr.status === 304) || (xhr.status === 1223) ||
(xhr.status === 0)

instead of

!( xhr.status && location.protocol === "file:" || 
   ( xhr.status >= 200 && xhr.status < 300 ) ||
   xhr.status === 304 || xhr.status === 1223 ||
   xhr.status === 0 )

Meanwhile I found a 503 reponse incoming right before a 304 response is causing my problem. Using periodical (interval) ajax requests to the same URL. Somehow the xmlHttpRequest of the response still contains the former 503 data, instead of the 304. Still investigating, maybe got trapped by the used closure. But that's another story...

Thanks for taking the time and pointing me in the right direction.