Steps to reproduce
IE 11.296.15063.0 (bundled with Win 10 Creators Update) treats
Cache-Control: private response headers differently than other browsers including other IE 11 releases. It caches all responses with the
private directive, refusing to request any URI twice.
As a result, none of our AngularJS apps work, since their REST requests to dynamic endpoints are now being cached. Our customer support team is beginning to receive calls of “F5 doesn’t work” and we have tracked it down to this.
The RFC 2616 spec is ambiguous about what a browser should do when it receives a
A private (non-shared) cache MAY cache the response.
The IE11 Win10CU version appears to be treating that MAY from the RFC as “go ahead, should be fine” and is now caching the default responses from any of our REST endpoints. Once a URI has been requested from this build of IE11, it will never be requested again from the server.
Technically, this build of IE11 is still interpreting the RFC correctly, it just happens to now be different from all major browsers.
Our testing shows that the private directive works fine (browsers won’t cache the response) on:
- IE 11 on Windows 7 (11.0.9600.18665)
- IE 11 on Windows 10 build 1607 Anniversary edition (11.1198.14393.0)
It only breaks on the version of IE 11 that is bundled with Windows 10 Creators Update.
Our .NET backend is using ServiceStack for its REST endpoints, which return
Cache-Control: private for any request by default. While we can and will change our default response headers (a bit expensive to deploy to all our customers servers in a timely manner), I think this change in caching behaviour may affect a number of other apps in subtle ways.
The IE11 team may need to consider reverting the behaviour change.
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “James M.”
Changed Assigned To to “Saty B.”
We are seeing this (or a very similar) issue affecting some large clients too, with IE 11.413.15063.0