Changed behavior in redirects

Hi all,

We’re working on making a breaking change in how our redirects feature works regarding file shadowing. We want to explain to you why we’re making this change and how it can affect your sites on Netlify.

Forced rules and shadowing

To understand these changes, there are two concepts that you need to know first.

First, Netlify redirects have the concept of forced rules. These rules can be expressed in two ways: in a _redirects file with an exclamation point after the status code, for example 301!, or in your Netlify configuration file with the key and value force=true. These forced rules will always take effect.

Netlify redirects also support the concept of file shadowing. With this feature, we check if a file exists for a given path before applying a redirect rule. If a file exists, we will serve that file rather than applying the rule, unless the rule is forced, because forced rules always take effect.

The bug

Unfortunately, over the years, we encoded some conditions in our code base that made rules without explicit force configuration to act as forced rules. For example, a proxy rule like /* /index.html 200 will be forced under certain conditions, but we never intended for this to happen. These conditions have very unexpected side effects, and we want to remove these side effects all together.

The fix

So this is the change that we’re making: starting on April 7th, only rules with explicit force configurations set by you will be forced rules. If you have a redirect rule that’s not explicitly marked as forced, and you also have a file under the same path, we will serve the file.

We want you give you a heads up before this change takes effect. Besides this announcement, we’re going to send email notifications to the owners of sites that we know might be affected by this change.

What you can do

If you receive an email that your site might be affected by the change, check your redirect rules. The email will list rules that are not configured to be forced, but are redirecting past existing content due to the current bug The email lists rules that could be affected by this bug. We decided to be more proactive the first time we sent this notification to ensure that you don’t miss any of them. If you want to keep redirecting past that content, add the ! (if it’s in a _redirects file) or force=true (if it’s in a netlify.toml file) to the rule to make it a forced rule.

Any rules you don’t change will start following the expected shadowing behavior on April 7th.

We’re here to help!

If you have specific questions about changes as they impact your site(s), or want to test the changes in advance, please post a response and we’ll be happy to work with you further.


Excellent information, thanks. I’m using forced rules to gracefully transition from a site on Netlify to the original WordPress version, so this is very helpful.

I’ve got a single-page application (SPA) built with create-react-app and, after modifying my redirect configuration to cater to your latest bug fix, I am now getting these errors while trying to load my website:

Uncaught SyntaxError: Unexpected token '<'
Manifest: Line: 1, column: 1, Syntax error.

This is my new netlify.toml file:

# For showing the preview image on social media
  force = true
  from = "/preview.png"
  to = "/preview.png"
  status = 200

# The following redirect is intended for use with most SPA's that handles routing internally
  force = true
  from = "/*"
  to = "/index.html"
  status = 200

What should I do? I don’t want my links to get broken after April 7th, so I’d keep the “force = true” thing.

1 Like

Ok great. I have a list of redirects and I’ll get them updated :nerd_face:


I updated the original announcement with a change. We want to be more proactive about this change and the emails that we’re sending include all rules that could be affected by this bug, so you have the opportunity to check them all.

That looks right at first glance. Are you sure that the error comes from the redirect changes? can you post here some log lines before and after the error?

I’m pretty sure this was caused by the redirect change. I did only one commit with literally just the netlify.toml changed. I took a screen capture with everything that gets printed in the browser console.

The email lists rules that could be affected by this bug

The email I got for lists lots of rules that don’t look like they should conflict at all, based on my understanding of this issue. For example, here are the first few:

  • /html-jsx.html ... 301 ...
  • /tips/controlled-input-null-value.html ... /docs/forms.html#controlled-input-null-value ...
  • /concurrent ... /docs/concurrent-mode-intro.html ...
  • /hooks ... /docs/hooks-intro.html ...
  • /tutorial ... /tutorial/tutorial.html ...
  • /your-story ... 301 ...

Am I maybe missing something?

Ahhh, now I see what’s going on. You don’t actually need to change your redirects if all your assets are managed by your SPA.

We’re notifying you because if you add any other asset to your site that’s no managed by the SPA, those assets will be served, and we won’t do the redirect to the SPA.


Heya @bvaughn and sorry for the confusion! Our detector points out potential problems which may not be actual problems. In your case, it should be pretty easy to tell:

If you don’t now or ever intend to have files at the paths like /html-jsx.html and /tips/controlled-input-null-value.html, then there will be no problems and no changes needed. However if there are or might later be files there and you want us to redirect anyway, you should use a ! on your redirect status (which if not explicitly listed, is assumed to be 301 - but you should specify explicitly for best result - and also that is the only way to use a ! ).

If you want us to redirect only if there is no file, you should not use a !, as you are doing now, and the local file will as of April 7th be served in preference, if present.

Ah, I see. In that sense, isn’t every redirect a potential (future) problem?

I think I understood the “potential problem” to mean…Netlify’s detector found a redirect that matched a current file (rather than a future file).

Anyway, I guess my question is answered. Thanks~

@bvaughn - Potentially, yes. Most aren’t, but we can’t easily scan millions of sites to see current setup, or predict future usage, so we’re acting out of an abundance of caution.

Hi Team,
Do we need to force all 200 status redirects with this type of setup?

from = "/path/*"
to = ""
status = 200

Hi, @luisug, and welcome to the Netlify community site. :smiley:

The rule above will redirect everything if there is no content under “/path/” for this site.

However, if there is a file found as “/path/page-1.html” without “force=true” the rule above will not redirect for this url:

That is because the URL would display “/path/page-1.html”, that content does exist, and the rule is not forced.

So the answer is, it depends on whether you want actual files at that path to be displayed if they exist or if you want to always proxy to the other site. The “force=” setting will determine which of these two things your site will do.

If there are other questions about this, please let us know.


If I have a redirect on /, and also an index.html file, do I need to force that redirect if I want it to keep working?

(If you’re curious, my use-case is as follows: I have sites with a default index.html, but I often override it with _redirects.)

Thank you!

Yes, if the file actually exists, you must force the redirect.

In the email I got on the topic, it listed this as an example of a forced redirect that would stop working:

/index.cfm/2013/5/20/Capturing-camerapicture-data-without-PhoneGap ... /2013/05/20/capturing-camerapicture-data-without-phonegap/ 301 ...

How is this a forced redirect if I do not have a file named index.cfm in my repository?

Another example I got:

2014/11/7/Cordova-and-Asset-Downloads/ ... /2014/11/07/Cordova-and-Asset-Downloads/ 301 ...

I do not have a folder that corresponds to the left hand side. I do have one that corresponds to the right hand side. So do I just have a bunch of false positives?

Is there any danger in simply adding ! to every redirect? (I didn’t always use 301 but I should have, so I’d add it.)

Hi, @cfjedimaster, it does sound like it is a false positive but I’d like to double check to be sure. Which site is this for?

I, too, have received that warning on redirects from files with PHP extensions to those with HTML extensions. They work great, though, so I just ignored the warnings.