IE11. XMLHttpRequest ignores Cache-Control headers. - by Mаx Shillby

Status : 


ID 836581 Comments
Status Active Workarounds
Type Bug Repros 6
Opened 3/19/2014 1:41:41 AM
Access Restriction Public


see this demo.

Set the no-cache radio button in the demo.
Then click left Send button once with empty Temporary Internet Files (or INetCache) first, and note response.
Then click left Send button again and see the headers contain less info, indicating the response was from cache.
The no-cache header had no effect.

You can verify the no-cache header was sent, using F12 dev tools, Network view.

also in passing, cached responses are giving different headers than uncached ones.
Sign in to post a comment.
Posted by thumbdоwn on 7/16/2014 at 1:06 AM
By the way, Eric. I was wondering who cast that petty anti-vote in David's thread, only minutes after I posted the bug confirmation there.

That confirmation, which took significant research, and included a live online demo.

Yes. I definitely noticed that PETTY ANTI-VOTE arrive only MINUTES afterward.

YOU CAST IT, Eric. I just checked your msdn profile. That figures.

Who else would stoop to casting ANTI-votes.

Where is your integrity?
Posted by thumbdоwn on 7/15/2014 at 10:30 PM
I just noticed a 3rd "abusive" from you Eric.

You flagged my post "abusive" in this thread where IECustomizer has been trolling the msdn/TechNet forums sidetracking (trying to dismiss diffuse deny) justified competent reports about the notorious KB2962872 bug.
Posted by thumbdоwn on 7/15/2014 at 3:30 PM
Look Eric.

Do you have any idea why the demo you mentioned is missing here? Why that same demo you also linked in your self-Proposed-Answer msdn post was taken off-line? Why don't you think about it.

Then review this following thread link which lists two recent events where you flagged my msdn posts "abusive". That first occasion, you brushed my diligent effort aside in order to take a personal offtopic boast. Then followed it with that "abusive". The second occasion, you sided with IECustomizer trolling me with psychopathic epithets, which has escalated beyond bad guy and Jew to now regularly calling me a dick.

So, you'll understand why I say, Eric, we are not on speaking terms. Buzz off.
Posted by EricLaw [ex-MSFT] on 7/15/2014 at 7:38 AM
Here's a test page for this problem:

Internet Explorer does not upgrade "Cache-Control: no-cache" headers on XHR to the proper INTERNET_FLAG_RESYNCHRONIZE constant, meaning that clients cannot force a conditional validation.

Interestingly, WinINET does bypass the client cache if a HTTP/1.0 "Pragma: no-cache" header directive is placed on the request.
Posted by thumbdоwn on 6/12/2014 at 1:04 PM
Much as you say, Eric.

Here are 3 Fiddler sessions. In each, the cache begins cleared. A plaintext file hello.txt is requested via XHR. Then hello.txt is re-requested to see if it is cached or not.


Case 1. IIS is configured to respond with Cache-Control: no-cache header, and Etags generation is disabled. Result: Upon re-read, IE re-validates, gets a 304, then supplies hello.txt from cache.


Case 2. IIS is configured to respond with Cache-Control: no-cache, no-store. Result: IE gets hello.txt from the server on re-read, never using the cache.


Case 3. IIS is configured normally (not no-cache), but the XHR is composed with an Author Cache-Control: no-cache, no-store header. Result: IE entirely ignores the Author header. The re-read comes directly from cache, without any observable network access.


Max probably submitted this earnestly as a bug report, Eric. ("claim" sounds so adversarial don't you agree?)
Posted by EricLaw [ex-MSFT] on 6/10/2014 at 2:02 PM
Unfortunately, the demo here is missing.

Is the claim that IE's XHR is ignoring the Cache-Control *request* header? Or that it's ignoring a Cache-Control *response* header? The former seems likely, the latter very unlikely.
Posted by Microsoft on 3/20/2014 at 6:07 AM
Thank you for your feedback!

We will be investigating this issue further.

Best Regards,
The Internet Explorer Team