Skip to main content

Bug Tracker

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 dmethvin comment:1

cc: → jaubourg

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?

Changed April 23, 2012 04:35PM UTC by rwaldron comment:2

component: unfiledajax
milestone: None1.next
owner: → jaubourg
priority: undecidedlow
status: newassigned

Changed April 23, 2012 05:16PM UTC by jaubourg comment:3

resolution: → patchwelcome
status: assignedclosed

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 gibson042 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 Mithaldu 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 jaubourg 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.hasContent block? It seems like that would resolve this ticket, and anyone explicitly setting cache: false probably expects an effect.

Changed June 18, 2013 11:27PM UTC by david.crowe@cnp-wireless.com 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 anonymous 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 anonymous 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.