on IE8 `cache: false` needs to be obeyed in all ajax requests or maybe even forced

[walde.christian@…]

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:

1. obey cache option on all request types
2. obey cache option on all request types in IE8
3. 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.

[dmethvin]

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?

[jaubourg]

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.

[gibson042]

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.

[Mithaldu]

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

[jaubourg]

$.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 gibson042:

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.

[david.crowe@…]

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.

[anonymous]

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.

[anonymous]

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.