Changes to Redirects with query string parameters are coming

Features Updates
,
1

One of our most frequently requested features is “automatic pass through” of query string parameters present on a URL covered by an HTTP 301 or 302 status redirect rule. We currently handle proxy redirects (HTTP 200 status) in this way, but not 301/302 redirects. For 301/302 redirects today, we can only reliably handle query string parameters which you explicitly configure to use a specific combination of query string parameters as described in our documentation. This is both brittle (a new or changed value will not be handled automatically unless you also update your redirects configuration), and leads to some workflows where a site needs thousands of redirects for a handful of paths to cover all the possible combinations of query parameter options that might be appended to a URL.

Today we are happy to announce that we have implemented automatic query string argument pass through, and intend to roll it out to our non-enterprise CDN next week. This will apply to all redirects that do not already specify a query string parameter pattern - whether to another path on the same site, a function, or a path on a separate site at Netlify or away from Netlify.

What does this look like in practice? Let’s talk through some examples!

Today, a redirect like /path /otherpath 301 will match requests to /path?var=value - but /otherpath is redirected to, WITHOUT ?var=value appended. In the new world, it will work as you’re expecting: /path?var=value will redirect to /otherpath?var=value.

This works identically in the toml file:

[[redirects]]
  from = "/old-path"
  to = "/new-path"
  status = 302

will redirect https://site/old-path?variable1=value1&variable2=value2 to https://site/new-path?variable1=value1&variable2=value2

Note that if you have existing (or future) query-parameter-SPECIFIC redirects like this one:

[[redirects]]
  from = "/old-path"
  to = "/new-path"
  status = 302  
  query = {id = ":id"}

…those redirects will continue to apply ONLY to requests to /old-path with a query param variable named id - so, this shouldn’t break existing configurations. If you can think of a problem that might affect your site, please bring it up in a response to this topic as soon as possible so we can talk through it with you.

This change is planned to go into effect on Monday, 4 October for the non-enterprise CDN, and the following Monday for the Enterprise CDN.

8 Likes
3

Nice! Glad to see the movement on query string params in the Redirector! :star_struck: Thanks @fool!

1 Like
4

Hi everyone!

As @fool announced it last week, a few minutes ago, we enabled this new capability for our non-enterprise CDN tier.

Please, let us know if you have any questions in this thread.

2 Likes
5

Unfortunately we had to turn this back off today to address a related bug. Will post here again once it is back on!

6

Any word on this? This is a key feature we utilize for out site.

1 Like
7

Nothing yet. Behavior matches how it has always worked here, except for the few days when we had this update live.

We will post in this thread as soon as there is an update.

9

FYI folks we have re-enabled this feature on our non-enterprise CDN this morning. Let us know if you see anything unexpected please!

10

Curious to know if there’s any plans to bring the netlify dev CLI tool to parity with this change? Currently, as far as I can tell, requests made to a server spun up with netlify dev which hit redirect rules do not automatically pass query parameters through.

2 Likes
11

Not sure, @sine - if you use the latest CLI and see that problem, could you file an issue here?

12

Just wanted to let everyone else who might be monitoring this thread know that the change is now deployed across all CDN’s we run, so all customers should now see automatic query string param forwarding for 301 redirects (unless your redirects specifications override that for any specific params or combinations thereof, using the syntax here: Redirect options | Netlify Docs)

2 Likes
13

@fool Done!

1 Like
14

Thanks much! I pinged the dev team to take a look. Not sure if it will be a quick fix but it is now on their radar. They’ll give updates in the issue as things, er, develop!

15

@fool
So I am probably going about this wrong, but how do I redirect and NOT preserve the query params?

Here is a demo site I created that only has the following redirects, and no javascript whatsoever.

https://agitated-borg-b9f1bd.netlify.app/

# Pagination
# redirect page 1 to route with no page in URL
/*    page=1   /:splat   301!
# Redirect queryparam to param
/*    page=:page   /:splat/:page   301!

So what I want to have happen is

https://agitated-borg-b9f1bd.netlify.app/test?page=1 redirect to https://agitated-borg-b9f1bd.netlify.app/test

And

https://agitated-borg-b9f1bd.netlify.app/other?page=2 redirect to https://agitated-borg-b9f1bd.netlify.app/other/2

What happens with my setup though, is the ?page=1 redirects to itself infinitely because the query params are preserved. And ?page=2 redirects to /2?page=2 which redirects to /2/2?page=2 and so on, infinitely getting deeper in the infinite redirect.

Is there a way to say redirect but do NOT preserve the query params?

Thanks for any help or insight on how I can go about this.

1 Like
16

hi there, before we dig in, did you see this brand new guide on debugging redirects?

I strongly suggest you give it a thorough read through and see if this fixes your problem:

if not, please post again, and we’ll try and troubleshoot.

17

Thanks for the reply.

I have read that article, and been through your docs on query params redirects. I may be missing something but I still don’t see an answer to my question.

How can I make these redirects NOT preserve query params?

/* page=1 /:splat 301!
/* page=:page /:splat/:page 301!

I think this rule used to work as intended, but this change to preserve query params you have just rolled out makes it infinitely redirect. I could be wrong though.

I have no other redirects. There is no application code, I created this application to debug these 2 rules in isolation.

If the query param were to not be preserved, the condition page=1 would no longer match after the first redirect and it would not redirect again.

Thanks for the help

18

Or is there a better way to achieve the same result without the infinite redirect?

I want any URL that has ?page=1 to redirect to the same URL but without ?page=1

And

Any URL that has ?page={any other value} to redirect to the same URL but with /:page at the end and the page query string removed.

2 Likes
19

A post was split to a new topic: Query string cached when redirecting

20

Hey Rob! This is a very new change which I too am still familiarising with.

I’ve set up a repro and I can also observe this. I’m not seeing a quick win so I’ll raise this internally to see what the wider team suggest. Thanks for bearing with us!

@annejan, are you saying that the content on the page with the query string is being cached by our CDN, or is this explicitly an issue because we now pass the query string parameter to the result (similar to the report above)?

21

@robmsw et al,

I’ve filed an issue for our team to investigate. You can break the redirect loop, for now, by including a dummy query string param. @robmsw, your redirects therefore could look similar to this:

/*    page=1   /:splat?no-query-string   301!
/*    page=:page   /:splat/:page?no-query-string   301!

I’ve created a demo showcasing this for you here: https://redirect-dummy-query-string.netlify.rodeo

Thanks for bringing this to our attention!