Bug Tracker

Ticket #4918 (closed bug: invalid)

Opened 5 years ago

Last modified 2 years ago

Ajax ifModified has problems

Reported by: schickb Owned by:
Priority: major Milestone: 1.4
Component: ajax Version: 1.3.2
Keywords: Cc:
Blocking: Blocked by:

Description

When ifModified is set, jQuery adds its own If-Modified-Since header (and the first ajax call for each url gets a bogus old 1970 date). Shouldn't the handling of If-Modified-Since be left to the browser which will already be caching URLs and modified dates between sessions (unlike jQuery)? Also browser support Etag validation, and this actually works correctly now since jQuery doesn't mess with the If-None-Match header as it does with the If-Modified-Since header.

It seems like the ifModified option should do nothing more than control whether or not jquery processes the response data and calls success.

Although it is already rather odd that jQuery calls the error handler when ifModified is true and the data is unchanged. Maybe there should be a 3rd "unchanged" callback for ajax requests.

Change History

comment:1 Changed 5 years ago by schickb

Looking into this a bit more, I see that caching it is a rather messy area of ajax. Firefox always return 200 even when the server returns 304. Furthermore, in FireFox if client code (aka jQuery) sets any of the conditional headers like if-modified-since, then FF doesn't use its local cache and ignores any other headers it may have cached like Etag.

Since jQuery can read what it in the local cache, this seems like an impossible thing for jQuery to fix perfectly. One possible workaround it to define a custom header that servers must set when sending a 304 response, and that jQuery will watch for and act accordingly. Either that or just give up on trying to tell the difference... which seems to be what FF (and the xhr rough draft) is encouraging.

comment:2 Changed 5 years ago by schickb

It gets worse... Apache intentially drops any unrecognised headers when the response status code is 304. Apparently this matches the HTTP/1.1 spec. See this bug for a discussion:  https://issues.apache.org/bugzilla/show_bug.cgi?id=18388

This is looking like a no-win situation for jQuery. Tracking request/response headers within jQuery to let clients code know when a response is cached is never going to work 100%. I am now of the opinion that jQuery would be better off dropping support for ifModified entirely (or at least depreciating it).

Overall, I would say that attempting to add a feature that browsers, servers, and their specs currently discourage seems like a "bad idea". Maybe someday there will be an actual XHR2 spec that lets callers see 304 responses.

comment:3 Changed 5 years ago by schickb

I found this in the most recent XHR draft:  http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-send-method:

For 304 Not Modified responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content. The user agent must allow setRequestHeader() to override automatic cache validation by setting request headers (e.g., If-None-Match, If-Modified-Since), in which case 304 Not Modified responses must be passed through. [RFC2616]

So maybe there is hope. Maybe someone should just close this report, and I'll start over clean with all the info I've gathered ;)

comment:4 Changed 5 years ago by schickb

And I see that this was all already addresses in 1.3.3. Very sorry for documenting my path of discovery in a bug report. Please close.

comment:5 Changed 5 years ago by dmethvin

  • Status changed from new to closed
  • Resolution set to invalid
Note: See TracTickets for help on using tickets.