I am debugging a problem with a HTTP 301 Permanent Redirect. After a quick test, it seems that Safari clears its cache of 301s when it is restarted, but Firefox does not.

When do IE, Chrome, Firefox and Safari clear their cache of 301s?

UPDATE: For example, if I want to redirect example1.com to example2.com, but I accidentally set it to redirect to example3.com, that is a problem. I can correct the mistake, but anyone who has visited example1.com in the meantime will have cached the incorrect redirect to example3.com, and so they will not be able to reach either example1.com or example2.com until their cache is cleared. Upon investigation, I find that there were no Cache-Control and Expires headers set. The headers for the incorrect 301 response would have been like this:

@BT since the problem affects all browsers, really only the IETF could fix this, probably by defining some mandatory timeout on cached 301s that have no TTL, so that browsers would eventually re-verify their cached assumptions.
– McGuireV10Nov 29 '17 at 13:50

11 Answers
11

At least two browsers - Chrome and Firefox - will cache a 301 redirect with no expiry date.

That is, it will remain cached for as long as the browser's cache can accommodate it. It will be removed from the cache if you manually clear the cache, or if the cache entries are purged to make room for new ones.

You can verify this at least in Firefox by going to about:cache and finding it under disk cache.

I don't know about the behaviour of other browsers, such as IE10/IE11. However, given that other browsers do cache it indefinitely, you will have to accommodate for this anyway.

In all browsers, including Chrome/Firefox it is still possible to override this default behavior using headers, as described below:

Note: this answer was written in 2014 and browser behavior may change over time.

If you don't want the redirect to be cached

This indefinite caching is only the default caching by these browsers in the absence of Cache-Control headers. The logic is that you are specifying a "permanent" redirect and not giving them any other caching instructions, so they'll treat it as if you wanted it indefinitely cached.

The browsers still honor the Cache-Control and Expires headers like with any other response, if they are specified.

You can add headers such as Cache-Control: max-age=3600 or Expires: Thu, 01 Dec 2014 16:00:00 GMT to your 301 redirects. You could even add Cache-Control: no-cache so it won't be cached permanently by the browser or Cache-Control: no-store so it can't even be stored in temporary storage by the browser.

A better alternative in my opinion, however, is to use a 302 or 307 redirect. These don't imply to browsers or caches that they are "permanent" redirects and thus shouldn't be cached in the absense of Cache-Control headers.

To me, it seems like issuing a 301 redirect but marking it as non-cacheable is going against the spirit of what a 301 redirect is for, even though it may be technically valid. YMMV, and you may find edge cases where it makes sense for a "permanent" redirect to have a time limit.

If you previously issued a 301 redirect but want to un-do that

If people still have the cached 301 redirect in their browser they will continue to be taken to the target page regardless of whether the source page still has the redirect in place. Your options for fixing this include:

The simplest and best solution is to issue another 301 redirect back again.

The browser will realise it is being directed back to what it previously thought was a de-commissioned URL, and this should cause it re-fetch that URL again to confirm that the old redirect isn't still there.

Edit: some comments throw doubt upon this, see below.

If you don't have control over the site where the previous redirect target went to, then you are outta luck. Try and beg the site owner to redirect back to you.

Also prevention is better than cure - avoid a 301 redirect if you are not sure you want to permanently de-commission the old URL.

Also, do you have any references that show that browsers handle circular permanent redirects by re-fetching the original URL?
– Kevin Christopher HenryFeb 16 '14 at 0:32

5

301 redirect back don`t work, browser still cache old 301 redirect and i see infinite loop
– Yuriy KolodovskyyMay 5 '14 at 22:37

5

how I did test: some time ago I did make 301 redirect for http://www.SOMEHOST.com to https://www.SOMEHOST.com. But now http://www.SOMEHOST.com must be primary host for site. So, redirect from https to http removed. As you show I did make redirect 301 from https://www.SOMEHOST.com to http://www.SOMEHOST.com, but see loop. Browser did not re-fetching...
– Yuriy KolodovskyyMay 6 '14 at 7:49

6

I confirm that redirecting back (with a PHP redirection in my case) works perfectly on Google Chrome as long as (obviously) you removed the initial 301 redirect.
– Vincent PoirierMar 14 '17 at 14:00

To clear a permanent redirect, go to chrome://net-internals. On the right of the top red status bar, click on the down arrow ▼ to open the drop-down menu, and under the "Tools" group, choose "Clear cache".

As of version 48, this was the only thing that worked for me to clear a cached 301.

Update: Unfortunately, as of version 71 (Dec 2018) Google has removed the net-internals feature.

As of Chrome version 54, this is unfortunately not working for me.
– pwagnerDec 16 '16 at 11:21

4

On second thought, I didn't really answer the real question, "How long do browsers cache a 301," and my answer wouldn't help anybody who redirected a public-facing site where you probably need some way to permanently undo a 301 without knowing how many browsers in the wild have cached the redirect -- other answers partially address that scenario. My answer is really only useful to developers or intranet scenarios where you can communicate with all impacted users.
– McGuireV10Nov 29 '17 at 13:47

This works and even after re-enabling caching the redirect is gone. THX!
– miggSep 20 '16 at 7:07

1

It looks like this is not working for domains pointed to 127.0.0.1 via the local hosts file. Is there any other option for this case?
– pwagnerDec 16 '16 at 11:27

Doesn't work if the redirect, unintendedly, points to another port, like from localhost:8000 to localhost (port 80). I also cleared the whole site/application data from both localhost and localhost:8000, but neither did this help.
– Dennis98Nov 29 '17 at 13:02

301 is a cacheable response per HTTP RFC and browsers will cache it depending on the HTTP caching headers you have on the response. Use FireBug or Charles to examine response headers to know the exact duration the response will be cached for.

If you would like to control the caching duration, you can use the the HTTP response headers Cache-Control and Expires to do the same. Alternatively, if you don't want to cache the 301 response at all, use the following headers.

Although technically correct, your answer does not answer the users question and hence does not answer the question I came here for. When do existing, un-cache header-ed 301s already in the browser expire for the main browsers ?
– robFeb 8 '13 at 9:53

This has been downrated, probably because the primary promise of the "private window" is not to WRITE to caches, but can still READ/REUSE them. BUT for me on Firefox 37.0.1 (Linux) this worked and was very quick and useful. The private window is reflecting the current/uncached settings of the web-server, whereas the normal browser tabs use a cached 301 redirect.
– alfonxApr 14 '15 at 21:29

alfonx: The private window may not reuse the cache simply because the server owner could use the elements in a cookie fashion revealing that user's previous identity. Although I must concede that cache reusing is probably safe against a porn-hating wife.
– ZdenekMay 18 '15 at 19:02

4

This doesn't work if you already have a cached 301. Private will indeed use the redirect that is cached.
– jeffmcneillOct 16 '16 at 6:11

If people still have the cached 301 redirect in their browser they will continue to be taken to the target page regardless of whether the source page still has the redirect in place. Your options for fixing this include:

The simplest and best solution is to issue another 301 redirect back again.

The browser will realise it is being directed back to what it previously thought was a decommissioned URL, and this should cause it re-fetch that URL again to confirm that the old redirect isn't still there.

If you don't have control over the site where the previous redirect target went to, then you are outta luck. Try and beg the site owner to redirect back to you.