How long is a 302 redirect saved in browser?

Question

Due to a misconfiguration of our webserver the main domain sent a 302 redirect to a new location. We fixed that issue. When emptying the browser cache everything works fine now.

For the "normal" client who does not empty his cache: How long is the 302 redirect kept in the browser?

I'm looking for specific cache times (if any) for each of the major browsers (Chrome, Firefox, Safari, Opera, Edge, IE 12) under default settings.

Emblazonment

Redirect caching deep dive article by Steve Souders contains a link to a relevant web tests. – Orphaorphan

Answer 1

It shouldn't be cached at all unless there's also a Cache-Control or Expires header returned by the web server. According to RFC 2616, section 10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

Dethrone

Thanks. Looks like my default test browser (Chrome) just fooled me about this: code.google.com/p/chromium/issues/detail?id=103458 (Chrome caches, others not) – Emblazonment

@OleAlbers I was about to edit my answer with a note (before my internet died) that although the RFC says that clients SHOULD continue to use the original URI, that it doesn't mean all browsers will, it's going to need to be taken as a case-by-case basis. – Dethrone

Answer 2

The standard referenced by Jon Lin here uses "SHOULD", which is not as strong as "MUST" in RFC lingo. This is not just a theoretical distiction; Cloudflare, for example, does cache redirects:

If no cache headers are provided (no Cache-Control or Expires) and the url is cacheable (.jpg, .css, .js etc.) then CloudFlare caches both 301 and 302s. We cache 301 for a couple of hours and 302s for a shorter period of time (~20 minutes).

So you should either make sure you can handle it or use explicit headers (e.g. Cache-Control: private, no-cache) to direct browsers and intermediates against caching it.

Trigg

Yup, this was the issue for me - not specifying Cache-Control was causing the cached redirect. Can take a look at this thread for a more comprehensive look at specifying no-cache headers though: #50047 – Elisavetgrad

Answer 3

Using Steve Sounder's Redirect Caching Tests tool (thanks @LeonidVasilev), it seems that the results may not be what are expected. With no expires headers or cookies, the results were as follows:

Chrome 71: Not Cached ✔
Firefox 64: Cached ✕
Safari 12: Cached ✕

So despite what RFC 2616, section 10.3.3 302 Found states, not all browsers follow these guidelines or what might be considered expected behaviour :(

Perrault

Answer 4

Add the

Cache-Control: no-store

header to the response and it won't be cached. As of Jul 20, 2020 all mainstream browsers respect this.

Beware of intermediate caches though (proxy / CDN): If an intermediary has a nonzero minimum TTL, your response will be cached no matter what you do. See for example:

Managing How Long Content Stays in an Edge Cache (Expiration)

last line of the table (Origin adds Cache-Control: no-cache, no-store, and/or private directives to objects). In this case, the only way to prevent caching is to set the TTL to 0 (and add the Cache-Control: no-store header of course).

Delbert

Answer 5

It depends on individual client's browser caching settings: IE has an option to "NEVER" check for new pages, it has the same effect on redirects.
And AFAIR IE's "Automatic" settings (default?) is not much better.

Clive

Answer 6

Firefox

It should not be cached, per bug 812167

Omegaomelet