Processing order of _redirects & TOML

Support
, , ,
#1

I found https://firebase.google.com/docs/hosting/full-config#hosting_priority_order really useful in understanding the order Firebase processes things, it’d be great if Netlify could provide something similar.

After reading https://www.netlify.com/docs/redirects/ I have questions like:

If you have rules in _redirects and in toml, what’s the order?

/foo /index.html 200
/foo /index.html 200!

What happens if /foo exists?

You could say the first rule matches, so it’s used, and since /foo exists, the static file is used.

Or you could say that /foo exists, so the first rule is ignored, so the second rule matches, rendering /index.html.

Language based redirects/rewrites (which are great btw!) seem to apply even if the static resource exists, even without ! after the status code, so I’m not sure of the order there.

#2

Hi Jake,

Thanks for letting us know. We definitely need more docs around that.

  • We parse, then combine the redirects taken from _redirects and those in your netlify.toml. They are taken and processed in order from top to bottom. The rules taken from your _redirects file are always processed first, and the ones from the netlify.toml are processed afterward. Other than that, they preserve the order you have in your files. This means that the bottom rule in your _redirects file will be above the top rule in your netlify.toml

  • In your example, when a user goes to /foo it will process that top redirect since it matches. The second one doesn’t matter in that case since that request won’t hit it.

  • Language and country based redirects are processed as though you set force = true or !. This is a behavior that may change in the future to make it more flexible, it’s something we’re exploring.

  • Even if you have ! on a rule, we still respect the order of your redirects.

  • A single request will process based on the first matching rule. After it’s redirected it will run through redirects again from the top using the updated request URI. It’s possible in some cases to have a single request hit multiple rules, like a redirect for HSTS followed by a regular redirect to another location. We have some intelligence on the edge that combines rules in some cases (though I don’t have details on this). We also detect redirect loops and break them.

3 Likes
#3

Thanks for the detailed answer!

Is this also true for rewrites? I thought I experienced something different, but may have been looking at it wrong.

#4

Np @jakearchibald. With rewrites it won’t run through multiple times because it just loads the content that you’re trying to proxy.