Default Cache-Control header is broken for IE 11 Win 10 Creators Update

The default Cache-Control response header from ServiceStack is Cache-Control: private,. This has been a reasonable default for many years, as private instructs any proxies not to cache the response.

But the RFC 2616 spec is ambiguous about what a browser should do. A private (non-shared) cache MAY cache the response.

The recently-released Windows 10 Creators Update deployed a new build of IE 11 (11.296.15063.0) which treats private differently from all other major browsers (including other IE 11 builds,!). It is treating that MAY from the RFC as “go ahead, should be fine” and is now caching the default responses from any ServiceStack endpoint. 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:

  • Edge
  • Chrome
  • Firefox
  • 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 deviant unicorn version of IE 11 that is bundled with Windows 10 Creators Update.

Clearly this is a bug in Win10CE, not ServiceStack, but I suspect it might begin to affect a number of SS customers as this IE 11 build becomes more widely deployed.

Perhaps a different default value might be appropriate? Maybe Cache-Control: private, no-store would be a more conservative default header value, since it basically says “Never cache me, I am a dynamic endpoint”.

Not convinced the defaults should change to cater for a recent build of IE11, I’d expect the non-conformance behavior to be a bug that they should rectify in a future update.

Do you know if there’s an open issue/bug report the IE11 team have responded to, to provide reasoning for this change?

It’s a gross behaviour change, for sure. Our support team only started receiving sporadic reports of “F5 doesn’t work” and we tracked it down to this madness, so I wanted to get it on the SS community’s radar.

For now, we’ve dropped support for IE11 on Win10CE, but other consumer apps might not have that luxury,

We haven’t looked into the IE11 team buglist. If you already know of a link to start from, I can take it from there (or just Google it myself.) “Microsoft IE 11 bugs” is rather noisy search space. Perhaps I should “Bing” it instead? :slight_smile:


That was a very painful experience to try reporting a bug at the IE/Edge team issue tracker

Their issue reporting app is broken.

Spent 15 minutes trying to sign in, 10 minutes formatting a report in Markdown, and the when I hit “Submit” I get a response page of Something is happening, try again later please, thank you for your patience.

Yeah IMO IE/Edge is going sliding into irrelevance and IMO deservingly so. I’m still annoyed they’re the last browser not to support SSE. Best thing they can do is to either adopt Blink/Webkit or just stop development of IE altogether and get everyone to use Chrome. If it wasn’t for their aggressive tactics forcing IE/Edge as the default in Windows it would have irrelevance market share - can’t imagine anyone preferring to use IE/Edge on their own.

Unfortunately, we have enough government customers who insist on using IE in locked-down deployments.

What would be the recommended way to change the default response to include Cache-Control: private, max-age=0?

Should just be:

this.GetPlugin<HttpCacheFeature>().CacheControlForOptimizedResults = "private, max-age=0";
1 Like

BTW, looks like my IE report made it through, even though the final message from the submission form indicated an error.

1 Like