Preserve query parameters on redirect

Hi, @uhawaii. We have this topic cross-linked with the issue tracking the change. If/when it is enabled again, we will post an update here to let you know about it.

Any chance you could provide more details about what went wrong? I’m confused b/c in the post you say it is “one of our most frequently requested features”, and you build it, then rolled it back, now say “if” we enable it again. I totally get that it might be too complex, but we will have to dedicate and plan decent engineering resources to work around this or exlpore differen cdns, so some more info would help a lot with our planning process! Thanks for the updates so far and again if it’s not going to happen soon I get it, just would be very helpful to know.

Nothing specific to report, only the changes broke other working aspects of the service. We simply say if/when because we’re not part of the project team working on the larger deliverables – though we have added our customer’s voices. We don’t want to promise something that we don’t have the final decision on, is all.

1 Like

Is this related to the wiping of referrer data when using the Pretty URL asset optimization? I noticed today that document.referrer is empty when navigating to a url without a trailing slash that is then redirected to the same url with a trailing slash. This is concerning since this means our referrer analytics data has been affected for the 6 mos we’ve had this optimization enabled. If this is intended behavior it would be useful to document that somewhere (or maybe it is and I missed it).

1 Like

2 week ping. Any word? Any chance someone from the dev team could drop a line or two about what happened and why it was nixed? If for nothing else just for the technical curiosity

hey there, thanks for your interest~

Looking at our internal issue, I see that we switched this off because we are waiting on the rollout of some bigger changes that will make this change a bit more stable and less error prone. I can’t share more details at the moment, but we do plan on bringing this back as soon as some other upgrades are in place.

1 Like

Makes sense! A common and understandable reason, and usually things like that are worth the wait.

1 Like

FYI for those looking, this feature has been re-enabled and should be live once again:


Maybe it is because I am in development, but I still have this issue.

netlify -v
$ netlify-cli/2.69.11 darwin-x64 node-v12.16.3
# netlify.toml
  functions = "serverless"

  from = "/api/*"
  to = "/.netlify/functions/express/:splat"
  status = 308

We don’t necessarily support all the “special” redirect codes like 308 (or 314). Could you try it with a 301 or 302 instead please, and let me know how well it works for you? You are also a major version behind in our CLI so you’ll need an upgrade to the latest as well since this is a very recent change!

Hi everyone, I’ve implemented the following in our netlify.toml file:

  from = "/"
  to = "/fr?utm_source=:source&utm_medium=:medium&utm_campaign=:campaign"
  force = true
  query = { utm_source = "source", utm_medium = "medium", utm_campaign = "campaign" }

From my tests, any combination of these 3 query parameters (including 2, 1 and no query parameters) in the URL lead to a correct URL. Am I missing something, or is this indeed enough to redirect for all these 3 parameters?

Hey @Floriferous, can you elaborate on what a ‘correct URL’ is? What is the true intended URL?

There’s a sample file here and this discussion will be useful for you, too!

Correct means:

  • /?utm_source=A/fr?utm_source=A
  • /?utm_medium=B&utm_source=A/fr?utm_medium=B&utm_source=A
  • Etc. no matter the order and amount of the 3 query strings I pass.

Gotcha. Unfortunately, you’re going to need a redirect rule for each of the possibilities.

If your rule specifies three parameters, our engine will expect to see all three parameters but it doesn’t matter what order they’re in. For example, this rule:

  from = "/origin"
  to = "/new/origin"
  status = 301
  query = {one = ":one", two = ":two", three = ":three"}

Will successfully redirect the following:

  • /origin?one=yes&three=yes&two=yes
  • /origin?one=yes&two=yes&three=yes
  • /origin?one=yes&two=&three=
  • /origin?three=yes&two=&one=

It will not redirect /origin?one=yes.


I tried your reproduction, and it doesn’t seem to work for /origin → /new/origin

From what I can tell, it works on our production website without specifying all other possibilities?

I would expect that you need a rule without the query string parameters, to redirect /origin to /new/origin.

If you’re not seeing this and this is still an issue, do you mind sharing your site’s app ID and/or applicable deploy ID so I can see what rules you have and check what’s actually happening?

1 Like

Sure, it’s, and the redirect is from / to /fr.

Hey @Floriferous,

I see what’s happening – it’s because we automatically pass through query string parameters now! The query strings would always be passed through, it’s just what we do.

So, you won’t actually need the second-to-last rule with the query string rules, if you want to pass these parameters through.

If you don’t want to pass them through, you’ll want to instate something like this (see section Query String Parameters).

Your last reply is a bit confusing, do we need to specify query = { } in the netlify.toml or not now?

What “second-to-last” rule are you referring to?

Have we been talking all along about outdated product information?

Hey @Floriferous,

It depends what you’re trying to do and I’m struggling to understand what you want.

If you want any sort of query string to be included in the redirect, you don’t need to specify it in a redirect rule. If you want all query strings to be passed through, remove the redirect rule containing query = { } (this was the second-to-last rule I was referring to)

If you want only specific query string parameters to be included in the redirect, you’ll want to follow the advice from before and observe the reproduction I created.