Bug Tracker

Ticket #7083 (closed bug: worksforme)

Opened 4 years ago

Last modified 4 years ago

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:
Blocking: Blocked by:

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";

Change History

comment:1 follow-up: ↓ 2 Changed 4 years ago by snover

  • Status changed from new to closed
  • Resolution set to worksforme

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.

comment:2 in reply to: ↑ 1 Changed 4 years ago by jthelen

Replying to 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.

Note: See TracTickets for help on using tickets.