437

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:

HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Feb 2013 12:05:53 GMT
Server: Apache/2.2.21 (Unix) DAV/2 PHP/5.3.8
X-Powered-By: PHP/5.3.8
Location: http://example3.com/
Content-Type: text/html

My own tests show that:

  • IE7, IE8, Android 2.3.4 do not cache at all.
  • Firefox 18.0.2, Safari 5.1.7 (on Windows 7), and Opera 12.14 all cache, and clear the cache on browser restart.
  • IE10 and Chrome 25 cache, but do not clear on browser restart, so when will they clear?
Liam
  • 17,556
  • 23
  • 76
  • 110
  • 11
    Please tell chrome we need a way out of this 301 hell hole: https://bugs.chromium.org/p/chromium/issues/detail?id=633023&can=1&q=clear%20301%20redirects&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified – B T Aug 01 '16 at 02:20
  • @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. – McGuireV10 Nov 29 '17 at 13:50
  • 1
    I started a discussion on the IETF mailing list about this, if anyone still following this issue feels like weighing in: https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0363.html – McGuireV10 Dec 01 '17 at 12:06

16 Answers16

337

In the absense of cache control directives that specify otherwise, a 301 redirect defaults to being cached without any 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. It works this way in other browsers including Chrome and the Chromium based Edge, though they don't have an about:cache for inspecting the cache.

In all browsers it is still possible to override this default behavior using caching directives, as described below:

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 headers that specify otherwise. 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.

Though, if you don't want your redirect to be permanent, it may be a better option to use a 302 or 307 redirect. 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 is technically valid. YMMV, and you may find edge cases where it makes sense for a "permanent" redirect to have a time limit. Note that 302 and 307 redirects aren't cached by default by browsers.

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:

  • A simple solution is to issue another redirect back again.

    If the browser is directed back to a same URL a second time during a redirect, it should fetch it from the origin again instead of redirecting again from cache, in an attempt to avoid a redirect loop. Comments on this answer indicate this now works in all major browsers - but there may be some minor browsers where it doesn't.

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

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

thomasrutter
  • 104,920
  • 24
  • 137
  • 160
  • Excellent answer. In my opinion, though, since the HTTP standard specifically includes mention of changing the cache time on 301 redirects, these "impermanent" permanent redirects are well within the spirit of the standard. – Kevin Christopher Henry Feb 16 '14 at 00:29
  • 19
    Also, do you have any references that show that browsers handle circular permanent redirects by re-fetching the original URL? – Kevin Christopher Henry Feb 16 '14 at 00:32
  • 10
    301 redirect back don`t work, browser still cache old 301 redirect and i see infinite loop – Yuriy Kolodovskyy May 05 '14 at 22:37
  • 1
    Yuriy which browser? How did you test? – thomasrutter May 06 '14 at 03:14
  • 1
    it was chrome and firefox – Yuriy Kolodovskyy May 06 '14 at 07:29
  • 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 Kolodovskyy May 06 '14 at 07:49
  • @thomasrutter - In your "simplest and best solution", does it matter what domain and/or path issues the 301 redirect? Say I have legacysite.com that 301 redirects to newsite.com, and now I want to "break" that 301 redirect. Does the new 301 redirect have to come from the exact target of the original 301 redirect? Or can it come through a special workaround flow involving legacysite.com? Or perhaps it has to be issued by newsite.com but the path doesn't matter? – Sean Jul 02 '15 at 17:02
  • 2
    Sometimes domain providers have service that (301) redirects domain to another www address - if it was a Facebook page (or any other not-you-controlled-page) - you can only pray they've set some expiration to that redirect... otherwise you are F..........................................................................................................................rozen in time :) – jave.web Apr 13 '16 at 19:38
  • It's worth noting that your redirect-back-again strategy only applies when you want ALL the traffic to the original 301 target to be sent back to the original page. It is highly possible that this isn't the case when the original target combined two separate traffic streams. – Arth Jun 24 '16 at 11:28
  • 8
    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 Poirier Mar 14 '17 at 14:00
  • 16
    I can confirm that redirect back works perfectly fine. Browsers seeing redirect loop invalidate the cache entries. Tested on IE11, Firefox 52, Safari 10, Chrome 57. – Munhitsu Apr 04 '17 at 16:14
  • The redirect back solution does not work for Brave Browser: V 0.25.2; Windows 10; The result is a 'too many redirects' error – yunzen Nov 20 '18 at 12:54
  • Really want to upvote, but also like the fact that the answer to a question about 301 redirects has 301 upvotes... – Dark Hippo Jul 29 '20 at 13:34
  • Looks like someone else *Found* this answer now. It's on 302. – thomasrutter Jul 31 '20 at 04:10
284

From Chrome 71

To clear a permanent redirect, go to chrome://settings/clearBrowserData and from there only clearing "cached images and files" cleared the redirect.

Chrome 48-70

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.

Hugo
  • 22,841
  • 6
  • 67
  • 86
McGuireV10
  • 8,161
  • 4
  • 42
  • 57
  • 14
    As of Chrome version 54, this is unfortunately not working for me. – pwagner Dec 16 '16 at 11:21
  • I should add that I have an entry in my /etc/hosts pointing the domain to 127.0.0.1 - this is most likely relevant. – pwagner Dec 16 '16 at 11:23
  • Works in Version 60.0.3112.101 (Official Build) (64-bit) – MattBoothDev Aug 24 '17 at 15:15
  • This should be the accepted answer. I was having trouble with this and this was the only thing that worked in Version 61.0.3163.91. – Preston Crawford Sep 20 '17 at 23:24
  • @PrestonCrawford I tried tagging the OP in case he'd accept as the answer, but for whatever reason it didn't work... – McGuireV10 Nov 19 '17 at 12:24
  • Well, it works, but the thing is: this clears the _whole_ HTTP Cache! Not really the best solution, if I only want to clear it for this one page, or domain. – Dennis98 Nov 29 '17 at 13:00
  • 7
    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. – McGuireV10 Nov 29 '17 at 13:47
  • 1
    Works in Chrome version 68.0.3440.106 (Official Build) – Thum Choon Tat Aug 29 '18 at 05:30
  • 12
    chrome://net-internals has been gutted in Chrome 71. The drop-down / Tools section is gone. There is a DNS > Host resolver cache > Clear host cache button, but this doesn't work to remove cached 301s. – t-jam Dec 11 '18 at 01:35
  • 53
    In Chrome 71, chrome://settings/clearBrowserData and from there only clearing "cached images and files" cleared the redirect. – Bemmu Jan 13 '19 at 16:26
  • 1
    Version 71.0.3578.98 (Official Build) (64-bit) for Linux still has this page, and it works. Thank you! – Petr Flaks Jan 15 '19 at 13:12
  • 1
    Thank you @Bemmu! Clearing cached images & files worked! – cr0ybot Jan 16 '19 at 15:32
  • @Yuck, technically speaking, this is _not_ the best answer to the OP question. It answers how to clear the cache, not "how long do browsers cache 301s" – Steve Withington Apr 16 '20 at 22:18
  • 1
    @SteveWithington which is exactly what I noted almost 3 years ago. – McGuireV10 Apr 17 '20 at 10:48
205

An answer that helps those who desperately want to get rid of the redirect cache:

Chrome caches the 301 redirect infinitely (in the local disk cache). To clear this cache:

  • open your DevTools (press F12)
  • on the Network tab check the "Disable cache" checkbox
  • keep DevTools open and reload the page (press F5)

When everything is okay, you can uncheck "Disable cache" and everything will continue to work as expected.

michaelmcandrew
  • 170
  • 2
  • 14
Olaf
  • 9,471
  • 8
  • 34
  • 54
  • 17
    This works and even after re-enabling caching the redirect is gone. THX! – crackmigg Sep 20 '16 at 07:07
  • 2
    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? – pwagner Dec 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. – Dennis98 Nov 29 '17 at 13:02
  • 4
    This solution works on Chrome as of Nov 16, 2019 version 78.0.3904.97. The other solutions are no longer available. After you get it working you can close the developer tools and it will continue to work properly. – Peter Wooster Nov 16 '19 at 14:40
  • Accepted answer. – Aysennoussi Mar 24 '20 at 04:03
  • Thank goodness I found this before having to clear my browser data. Once I got it working, I could close the dev tools and continue normally. – Keno Clayton Feb 14 '21 at 08:02
  • Thank you, the only answer that worked for me. – Biegacz Mar 29 '21 at 10:42
72

There is a very simple way to remove browser cache for http redirects e.g. 301, 307 etc.

You can open network panel in developer console in chrome. Select the network call. Right click on it and then click on Clear Browser Cache to remove the cached redirection.

network call context menu

Rajesh Paul
  • 6,002
  • 6
  • 33
  • 50
51

Make the user submit a post form on that url and the cached redirect is gone :)

<body onload="document.forms[0].submit()">
<form action="https://forum.pirati.cz/unreadposts.html" method="post">
    <input type="submit" value="fix" />
</form>
</body>
Krtek Net
  • 654
  • 5
  • 2
  • 2
    I agree this is the best method I have found to unscrew it. – esjay Apr 13 '18 at 04:49
  • 1
    unlike other answers, this method is suitable for solving other people's problem without opening the developer console! thank you – Alexey Rytikov Mar 12 '19 at 10:01
  • 4
    fetch('URL', {method: 'POST'}) oughta do the trick in the same way. Thanks! This saved me some headache! – calvin Mar 31 '19 at 19:23
  • I can't believe that this is the only way that worked for me (I tried all the other methods first - even the console fetch() failed due to a cross-site security policy). – user36388 Jun 18 '19 at 13:15
24

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.

Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Alex J
  • 507
  • 3
  • 8
  • 15
    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 ? – rob Feb 08 '13 at 09:53
  • If anyone is still interested, [this link](http://support.mozilla.org/en-US/questions/848678) instructions can toggle the cache for 301. – Francisco Presencia Jul 16 '13 at 21:47
  • The link is for FF and it didn't work for me. Installed web developer extension 1.2.5 and using FF 23.0.1 – an phu Sep 12 '13 at 18:58
  • 1
    the question was not answered. The question was, how long will the redirection be cached for if no expiration date was specified – Dennis Flagg May 07 '14 at 17:22
21

Confirmed!! make the user submit a post request to the affected url and the cached redirect is forgotten.

A quick win would be to enter this in the browser console if you can:

fetch('example.com/affected/link', {method: 'post'}).then(() => {})

Useful if you know the affected browser (especially during development).

Alternatively, if you have access to the previous 301 redirect page, then you can add this script to the page and anytime it is visited, the cached 301 will be forgotten.

Emeke Ajeh
  • 616
  • 6
  • 13
15

I will post answer that helped me:

go to url:

chrome://settings/clearBrowserData

it should invoke popup and then..

  • select only: cached images and files.
  • select time box : from beginning
John Tribe
  • 907
  • 9
  • 20
8

as answer of @thomasrutter

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 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.

In fact, this means:

  1. a.com 301 to b.com

  2. delete a.com 's 301

  3. add b.com 301 to a.com

Then it works.

phil han
  • 109
  • 1
  • 3
  • 2
    But then you still have b.com's 301 lying around : ( - a dirty fix – B T Aug 01 '16 at 02:24
  • 1
    Can you clear a redirect by issuing another 301 from a _different_ page? e.g. (`a.com` 301 -> b.com) (delete `a.com`'s 301) (add `a.com/abcdefg` 301 -> `a.com`) and force the client to view `a.com/abcdefg` somehow? – nemec Aug 05 '16 at 19:42
  • Thanks it works! Tested on IE11, Firefox 52, Safari 10, Chrome 57 – Munhitsu Apr 04 '17 at 16:13
  • I had a situation where wanted to use both a.com and b.com. So b.com 301 a.com was not an option. Our solution was to move to HTTPS - we had no redirects on HTTPS – rosell.dk May 01 '17 at 11:45
  • Why 301 if you can do 302 from b? – Tõnu Samuel Oct 23 '20 at 07:39
7

For testing purposes (to avoid cached redirects), people can open NEW PRIVATE WINDOW: click CTRL+SHIFT+N [if you use Mozilla, use P]

T.Todua
  • 44,747
  • 17
  • 195
  • 185
  • 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. – alfonx Apr 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. – Zdenek May 18 '15 at 19:02
  • 6
    This doesn't work if you already have a cached 301. Private will indeed use the redirect that is cached. – jeffmcneill Oct 16 '16 at 06:11
6

I have simple solution that worked on all major browser (latest version), includes IE, Chrome and FF

  1. Ctrl + Shift + Del
  2. -
    1. Chrome: Select "Browsing History" and "Cache..."
    2. IE: I leave default option "Temporary Internet files and website files", "Cookies and website data", "History"
    3. FF: "Browsing and Download history", "Cache"
  3. Click "Delete"
  4. Close and reopen your browser. It should work
EECOLOR
  • 11,034
  • 3
  • 38
  • 72
Dung Le
  • 91
  • 1
  • 2
5

On the latest Google Chrome Version 79, you can use the chrome://net-internals and select on DNS from the left panel, then tap the Clear host cache button

Screenshot of chrome opening the net-internals page

Mohammad Ersan
  • 11,926
  • 8
  • 48
  • 72
3

As the other answers show. Caching may be indefinetly in browser. This is extremely dangerous. So don't do it. At least add cache headers. In htaccess I always do it this way with no caching at all:

<IfModule mod_rewrite.c>
  RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$ [NC]
  # The E=nocache:1 sets the environment variable nocache to the value of one
  RewriteRule ^/?(.*) https://www.example.org/$1 [L,R=301,E=nocache:1]
</IfModule>


<IfModule mod_headers.c>
  ## Set the response header if the "nocache" environment variable is set
  ## in the RewriteRule above.
  Header always set Cache-Control "no-store, no-cache, must-revalidate" env=nocache

  ## Set Expires too ...
  Header always set Expires "Thu, 01 Jan 1970 00:00:00 GMT" env=nocache
</IfModule>

Edit:

If you didn't had no caching of 301 redirects in the past, you must redirect back to the source from the target. Example:

If you had this

RewriteRule /my-source /my-target [L,R=301]

You need to put this

# RewriteRule /my-source /my-target [L,R=301]
RewriteRule /my-target /my-source [L,R=301]
yunzen
  • 30,001
  • 10
  • 64
  • 93
2

To solve the issue for a localhost address I changed the port number the site ran under. This worked on Chrome version 73.0.3683.86.

combatc2
  • 957
  • 7
  • 9
1

Test your redirects using incognito/InPrivate mode so when you close the browser it will flush that cache and reopening the window will not contain the cache.

yougotiger
  • 439
  • 3
  • 18
0

try this one in your .htaccess File:

  <IfModule mod_expires.c>
  ExpiresActive On
  Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
  Header Set Cache-Control "max-age=0, no-store"
  Header Set Cache-Control "no-store"
  Header set Pragma "no-cache"
  </IfModule>
Ensai Tankado
  • 61
  • 1
  • 4
  • This would tell browser that visit your site to not cache anything, and it is useful to know how to do this. The problem is that if you have mistakenly issued 301 redirects away from your domain, perhaps due to a typo, those browsers have cached those redirects, and they will not make requests to your site again, and therefore will not get these new headers that you have suggested. – Liam May 06 '21 at 17:56