title: Chrome and Safari caching 302 redirect
body: <p>Various flavors of this have been asked already, but I've yet to see a real answer for this.</p>
  
  <p>We have a separate image service that our web app uses to get some of its images.  The image service is well tested and is functioning properly.  To make it concrete, our app is served from <code>domain.com</code>.  The <code>src</code> element of <code>img</code> elements is <code>images.domain.com/{imageId}</code>.  The image service retrieves the URL for the image and sends back a <code>HTTP 302</code> redirect for the image.  </p>
  
  <p>The application allows users to change images. So say a user <code>5</code> has image <code>A</code> as a profile image, and decides to change it by uploading image <code>B</code>.  When the user uploads the image, the application cache is properly invalidated and the database is updated.  The application does a standard redirect after <code>POST</code> and one of the elements in the page that the user is redirected to after changing her image is something like: </p>
  
  <pre><code> &lt;img src="example.domain.com/5"&gt;
  </code></pre>
  
  <p><strong>The problem is that Chrome never makes the call to <code>example.domain.com/5</code> to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image <code>A</code> from the browser cache.</strong>  A standalone call to <code>example.domain.com/5</code> correctly returns image <code>B</code>, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's <code>src</code>, which correctly returns image <code>B</code>. Note that I'm not talking about serving either image from the cache after getting a <code>304 Not Modified</code> response, I'm talking about Chrome deciding not to visit the <code>img</code> <code>src</code> at all and just returning image <code>A</code>.  Also, appending some unique query string to the <code>img</code>'s <code>src</code> attribute fixes the problem, but that's a hack that we'd rather not have to do.</p>
  
  <p>It's worth noting that Firefox was doing the same thing initially.  There were no <code>Cache Control</code> headers in the response initially.  We added a <code>Cache Control: no-cache</code> header (and tried <code>no-store</code> as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's <code>src</code>.</p>
  
  <p>It looks like this was a longstanding bug in Chromium (<a href="https://code.google.com/p/chromium/issues/detail?id=103458" rel="nofollow noreferrer">https://code.google.com/p/chromium/issues/detail?id=103458</a>) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.</p>
  
  <p>We've looked at the answers <a href="https://stackoverflow.com/questions/13553420/how-to-force-chrome-not-to-cache-redirects">here</a> and <a href="https://stackoverflow.com/questions/19500094/http-caching-why-is-browser-not-checking-server-at-all-before-presuming-cached">here</a> but they don't actually answer the question.</p>
  
  <p>Per section <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html" rel="nofollow noreferrer">14.9.1 of RFC 2616</a>:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for <code>no-cache</code> headers for <code>302</code> redirects? Anyone experience this before or have any insight?</p>