title: ASP.NET MVC and IE caching - manipulating response headers ineffective
body: <h2>Background</h2>
  
  <p>I'm attempting to help a colleague debug an issue that hasn't been an issue for the past 6 months. After the most recent deployment of an ASP.NET MVC 2 application, <code>FileResult</code> responses that force a PDF file at the user for opening or saving are having trouble existing long enough on the client machine for the PDF reader to open them.</p>
  
  <p>Earlier versions of IE (expecially 6) are the only browsers affected. Firefox and Chrome and newer versions of IE (>8) all behave as expected. With that in mind, the next section defines the actions necessary to recreate the issue.</p>
  
  <h2>Behavior</h2>
  
  <ol>
  <li>User clicks a link that points to an action method (a plain hyperlink with an <code>href</code> attribute).</li>
  <li>The action method generates a PDF represented as a byte stream. The method <em>always</em> recreates the PDF.</li>
  <li><p>In the action method, headers are set to instruct browsers how to cache the response. They are:</p>
  
  <pre><code>response.AddHeader("Cache-Control", "public, must-revalidate, post-check=0, pre-check=0");
  response.AddHeader("Pragma", "no-cache");
  response.AddHeader("Expires", "0");
  </code></pre>
  
  <p>For those unfamiliar with exactly what the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1" rel="nofollow noreferrer">headers</a> do:</p>
  
  <p>a. <strong>Cache-Control: public</strong></p>
  
  <blockquote>
    <p>Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non- shared cache.</p>
  </blockquote>
  
  <p>b. <strong>Cache-Control: must-revalidate</strong></p>
  
  <blockquote>
    <p>When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a
    subsequent request without first revalidating it with the origin server</p>
  </blockquote>
  
  <p>c. <strong>Cache-Control: pre-check</strong> (introduced with IE5)</p>
  
  <blockquote>
    <p>Defines an interval in seconds after which an entity must be checked for freshness. The check may happen after the user is shown the resource but ensures that on the next roundtrip the cached copy will be up-to-date.</p>
  </blockquote>
  
  <p>d. <strong>Cache-Control: post-check</strong> (introduced with IE5)</p>
  
  <blockquote>
    <p>Defines an interval in seconds after which an entity must be checked for freshness prior to showing the user the resource.</p>
  </blockquote>
  
  <p>e. <strong>Pragma: no-cache</strong> (to ensure backwards compatibility with HTTP/1.0)</p>
  
  <blockquote>
    <p>When the no-cache directive is present in a request message, an application SHOULD forward the request toward the origin server even if it has a cached copy of what is being requested</p>
  </blockquote>
  
  <p>f. <strong>Expires</strong></p>
  
  <blockquote>
    <p>The Expires entity-header field gives the date/time after which the response is considered stale.</p>
  </blockquote></li>
  <li><p>We return the file from the action</p>
  
  <pre><code>return File(file, "mime/type", fileName);
  </code></pre></li>
  <li><p>The user is presented with an Open/Save dialog box</p></li>
  <li>Clicking "Save" works as expected, but clicking "Open" launches the PDF reader, but the temporary file IE stored has already been deleted by the time the reader tries to open the file, so it complains that the file is missing (and it is).</li>
  </ol>
  
  <p>There are a half dozen other apps here that use the same headers to force Excel, CSV, PDF, Word, and a ton of other content at users and there's never been an issue.</p>
  
  <h2>The Question</h2>
  
  <ul>
  <li><strong>Are the headers correct for what we're trying to do? We want the file to exist temporarily (get cached), but always be replaced by new versions even though the requests may be identical).</strong></li>
  </ul>
  
  <p>The response headers are set in the action method before return a <code>FileResult</code>. I've asked my colleague to try creating a new class that inherits from <code>FileResult</code> and to instead override the <code>ExecuteResult</code> method so that it modifies the headers and then does <code>base.ExecuteResult()</code> instead -- no status on that.</p>
  
  <p>I have a hunch the "Expires" header of "0" is the culprit. According to <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21" rel="nofollow noreferrer">this W3C article</a>, setting it to "0" implies "already expired." I do want it to be expired, I just don't want IE to go removing it off of the filesystem before the application handling it gets a chance to open it.</p>
  
  <p>As always, thanks!</p>
  
  <h2>Edit: The Solution</h2>
  
  <p>Upon further testing (using Fiddler to inspect the headers), we were seeing that the response headers we thought were getting set were not the ones being interpreted by the browser. Having not been familiar with the code myself, I was unaware of an underlying issue: the headers were getting stomped on outside of the action method.</p>
  
  <p>Nonetheless, I'm going to leave this question open. Still outstanding is this: there seems to be some discrepancy between the <code>Expires</code> header having a value of <code>0</code> vs. <code>-1</code>. If anybody can lay claim to differences <em>by design, in regards to IE</em>, I would still like to hear about it. As for a solution though, the above headers do work as intended with the <code>Expires</code> value set to <code>-1</code> in all browsers.</p>
  
  <h3>Update 1</h3>
  
  <p>The post <a href="https://stackoverflow.com/q/49547/74757">How to control web page caching, across all browsers?</a> describes in detail that caching can be prevented in all browsers with the help of setting Expires = 0. I'm still not sold on this <code>0</code> vs <code>-1</code> argument...</p>