IE still treats Cache-Control no-cache as no-store - by Shane Hickson

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


ID 753827 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 7/15/2012 8:37:44 PM
Access Restriction Public

Description

IE 9 and 10RP treats Cache-Control no-cache as no-store. I would expect IE to act the same way other browsers do. Other browsers try to revalidate the request by sending a check using ETAG or modificationdate. IE does not revalidate even if those informations were part of the previous response. IE always performs a new request without revalidation-headers. Due to that IE does get less/no 304 status codes on various sites which results in IE producing more traffic and IE beeing much slower than other browsers.

This bug was already present in previous version of IE (See Bug-ID 415623). Hopefully you get it right this time.

no-cache = "must not use cache without successful revalidation"

If you use the cache with a successful revalidation that's just fine.

A quote:

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 
Sign in to post a comment.
Posted by EricLaw [ex-MSFT] on 12/27/2013 at 9:07 AM
This issue was fixed in IE10. http://blogs.msdn.com/b/ieinternals/archive/2012/03/01/ie10-beta-consumer-preview-minor-changes-changelist.aspx
Posted by Microsoft on 7/30/2012 at 10:34 AM
Thank you for your feedback.

We are currently unable to reproduce this issue as described.

We value your feedback. If you have the additional information requested, please reactivate the bug or submit a new bug with more details on how to reproduce the issue. You can also read the guidelines at https://connect.microsoft.com/IE/content/content.aspx?ContentID=16254 regarding filing a good bug report.

Best regards,

The Internet Explorer Team
Posted by Microsoft on 7/16/2012 at 7:21 AM
Thank you for your feedback.
We appreciate your time and effort.
In order to expedite the investigation of this issue, please attach a sample page or url that reproduces this issue.

Best regards,

The Internet Explorer Team