Allow multiple entries (array) in a single TOML redirect declaration

Features
, ,
#1

It would be helpful to be able to supply an array of “from” arguments in a particular [[redirects]] directive instead of having to repeat the entry multiple times. For entries that need to redirect from lots of possible matches with granular control (instead of broad “splat”-ing), arrays of “from” arguments would be SUPER helpful.

For context, here are the redirects as written in the custom hexo site I’ve been tasked with porting over to netlify. It uses a custom gulp process to write out the config for redirects (IE: NOT ON NETLIFY)

"type":"redirect",
         "matchPath":"^/(jobs|jobs/|jobs.html)$",
         "location":"https://careers.somesite.net",
         "status":301,
         "qsa":true,
         "caseSensitive":false,
         "cacheControl":"7200"

You can see from the “matchPath” it uses regex to parse multiple matches addresses. The only way to achieve this at the moment is to do something like this :

[[redirects]]
  from = "/jobs"
  to = "https://careers.somesite.net"
  status = 301
  force = true

[[redirects]]
  from = "/jobs.html"
  to = "https://careers.somesite.net"
  status = 301
  force = true

Again this is only two entries, but once it starts scaling this can become a maintenance nightmare, and explode the TOML file up to ridiculous sizes quickly.

Here’s what I think it should look like.

[[redirects]]
  from = ["/jobs", "/jobs.html"]
  to = "https://careers.somesite.net"
  status = 301
  force = true

Thanks

1 Like
#2

For your example, you could use /jobs* and that would cover all three paths. Our “globbing” is not a regexp so don’t try too hard to come up with a cool pattern, but it is better than nothing, particularly for files that share a /starting/path/component*.

I understand your request though to apply to files that are not so conveniently named, and short of restructuring your site to hold all content that needs to share a redirect in a folder you can apply the redirect or custom header to, it isn’t a workable solution, so I’ve added your voice to a related open feature request we have about making specifications more flexible.

#4

@fool I tried that, but that leaves it too open as /jobs* matches things like /jobs/a/b/c/d/e/z, /jobs-unavailable, /jobs/a/totally/different/redirect/required/here and /jobs/anything-what-so-ever.xml and anything in between. IMO this is not necessarily “better than nothing”, and better than nothing is not usually a solution. Any whooo!

I’m interested to know what that open feature request is? Can you post a link?

And thanks for the quick reply.

#5

Well, it depends on your use case I suppose as to whether it’s better than nothing. If people type nonsense URL’s into your site, I think it would be better to redirect them to a page that isn’t your 404 page if you could guess they wanted something “jobby”. But that’s just me, and I don’t make your business decisions.

Regardless, the feature requests are not public, so there’s nothing more for you to see except our hopeful eventual response in this thread if things change :slight_smile: But the text of the feature request is “better support for grouping redirect rules” which is a superset of what you are asking for.

#6

Sweet. Thanks and cheers!

#7

also, there’s a url that ends in jobs-sales which is not nonsense btw!

1 Like
#8

No problem - this is also already handled by our existing featureset:

existing routes will be served even if they match the glob:

If I have:

/jobs/index.html
/job-sales/index.html

and a redirect for

/jobs* /jobs/index.html 200

then /job-sales, /job-sales/, and /job-sales/index.html will all load, since you are not activating the “force” feature: