Side navigation
#11611 closed bug (patchwelcome)
Opened April 20, 2012 12:56PM UTC
Closed April 23, 2012 05:16PM UTC
Last modified July 03, 2013 09:57PM UTC
on IE8 `cache: false` needs to be obeyed in all ajax requests or maybe even forced
| Reported by: | walde.christian@googlemail.com | Owned by: | jaubourg |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | ajax | Version: | 1.7.1 |
| Keywords: | Cc: | jaubourg | |
| Blocked by: | Blocking: |
Description
The problem is at this position:
https://github.com/jquery/jquery/blob/master/src/ajax.js#L664
This line skips the logic triggered by cache: false if the request type is anything but HEAD or GET. I assume this is done for optimization, because most browsers won't cache on other types of requests.
However IE8 does not play by those rules.
I was in this situation:
host.tld/foo was first loaded as a normal GET request via the browser address bar. Modifications to the server session were then done via other ajax requests. Finally a POST request without any parameters was done to host.tld/foo, which would normally start processing of the data in the server session.
IE8 however did not even hit the server and instead delivered the cache of the GET request to host.tld/foo to jquery's ajax function, which expected a JSON reply and simply threw a "Syntax Error" when faced with HTML.
Normally this would be fixed easily with cache: false, but since that option is ignored on requests other than HEAD or GET i had to modify the url manually, which resolved the situation. As such, the logic should be modified to either of these options:
a. obey cache option on all request types
b. obey cache option on all request types in IE8
c. **force** cache option on all request types in IE8
Personally i would prefer c., since it would transparently work around this IE bug for other users, but i do not know how feasible it is.
Note: This is with a real IE8 on WinXP, not IE9 in compatibility mode.
Attachments (0)
Change History (9)
Changed April 20, 2012 09:44PM UTC by comment:1
| cc: | → jaubourg |
|---|
Changed April 23, 2012 04:35PM UTC by comment:2
| component: | unfiled → ajax |
|---|---|
| milestone: | None → 1.next |
| owner: | → jaubourg |
| priority: | undecided → low |
| status: | new → assigned |
Changed April 23, 2012 05:16PM UTC by comment:3
| resolution: | → patchwelcome |
|---|---|
| status: | assigned → closed |
If we change current behaviour code will break in the wild. I think the best solution is for the poster to use the workaround he's actually using. This is quite the edge case if you ask me.If we cater for IE8 here, then we screw all the others. Unless there is a way to feature-test this (which is highly unlikely), I don't see it as fixable in a generic fashion.
Changed April 23, 2012 05:31PM UTC by comment:4
Would anything break if we moved the anti-cache logic out of the !s.hasContent block? It seems like that would resolve this ticket, and anyone explicitly setting cache: false probably expects an effect.
Changed April 23, 2012 05:39PM UTC by comment:5
Replying to [comment:3 jaubourg]:
If we change current behaviour code will break in the wild.
I challenge this assumption. I can not think of any possible way that making POST ajax requests observe the cache setting (instead of silently ignoring it) would break anything at all.
Can you provide any example of how any breakage would result from this?
Changed April 23, 2012 05:41PM UTC by comment:6
$.post( "myUrl" ) => myUrl?anticacheparam=anticachevalue
I call that breaking to say the least when cache:false does set anti-cache headers (wich IS an effect). This IS a IE8 bug and trying to fix it without feature-testing is a call for disaster. And we cannot feature-test this kind of things... you're welcome to try though, but don't blame me if you end up as cynical as I am after a single year of ajax maintenance ;P
Challenge all you want: it has been proven time and time again that changing the most insignificant part of jQuery's behaviour breaks a massive amount of code and this is NOT insignificant.
Replying to [comment:4 gibson042]:
Would anything break if we moved the anti-cache logic out of the!s.hasContentblock? It seems like that would resolve this ticket, and anyone explicitly settingcache: falseprobably expects an effect.
Changed June 18, 2013 11:27PM UTC by comment:7
I just got caught by this "feature". I finally thought, "it's almost like IE is caching my queries, and when I issue the same query multiple times it returns the previous result" ... which would be okay if it wasn't for the fact that I'm talking to a dynamic database! And when I added a random number to the end of my query string, my application started working again.
Changed July 03, 2013 09:49PM UTC by comment:8
What feature needs to be tested in order to observe cache setting? I can't see it.
What kind of optimization is taking out cache control header anyway?
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
It looks to me that now neither post or get use cache control header:
https://github.com/jquery/jquery/blob/master/src/ajax.js#L687
We are supposed to use anti-cache url instead ?
I can't see that either since that was what the cache control header is for.
Changed July 03, 2013 09:57PM UTC by comment:9
In any case putting junk at the end of url does not work when url contains inline script src that gets 304 not - modified. This is a major bug.
I don't think it was there as an optimization, it's more likely we didn't anticipate someone would GET and POST to the same URL that way. It seems like the POST needs the cache buster, which would be option a in your list I think.
@jaubourg, what do you think?