Side navigation
#4918 closed bug (invalid)
Opened July 18, 2009 07:24AM UTC
Closed July 21, 2009 02:12AM UTC
Last modified March 15, 2012 03:53PM UTC
Ajax ifModified has problems
| Reported by: | schickb | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 1.4 |
| Component: | ajax | Version: | 1.3.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
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.
Attachments (0)
Change History (5)
Changed July 18, 2009 08:13AM UTC by comment:1
Changed July 19, 2009 05:46AM UTC by comment:2
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.
Changed July 19, 2009 06:27AM UTC by comment:3
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 ;)
Changed July 19, 2009 05:48PM UTC by comment:4
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.
Changed July 21, 2009 02:12AM UTC by comment:5
| resolution: | → invalid |
|---|---|
| status: | new → closed |
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.