Yeah I had a chat with Jeff Watson and @Bhavana regarding the enterprise account but this issue didn’t come up then, I only now noticed it.
We finally fixed the proxy part of this
You can find more here: Bug fixed: Proxy did not pass query string to target
amazing news! thank you marcus - and thank you to all of the folks who mentioned they needed this and waited patiently for us to ship it
Oh, the proxy wasn’t passing them along! great that it was fixed (as this is even more problematic for us than the redirects)
@marcus any ETA on this getting on the enterprise?
@altryne rollout for enterprise will definitely be this week, today or tomorrow.
we identified a regression with this change: Breaking change to redirect query parameters
therefore we are going to delay the rollout for the enterprise cdn
Additionally, is there any update on the rewrites GET param and it’s Enterprise CDN rollout? 80% of our payed traffic will move through a rewrite so this is blocking our deployment at the moment.
No updates yet. This has been a bit more challenging than expected with more moving parts. We’ll update here as things develop!
The change for proxy type rules is now rolled out across all CDN tiers.
Redirect (3xx) rules are not updated yet.
When you say “Redirect (3xx) rules are not updated yet,” does this mean that it’s ready to be rolled out? Will it be soon? Or is it a ways away?
I’m just trying to get a rough idea as we’re looking to do a migration from a naked domain to www. We have around 20k (that we know of) inbound links, some of which have query params that we can’t afford to lose in the redirect. This use-case and, pretty much, everything agworld laid out, to a T.
I would not bet on getting it before January. The work is not scoped out and we don’t know how it plays with our caching, so there is still stuff to figure out.
Thanks for the follow-up!
Loved @agworld’s use cases — totally agree. Our main use cases are UTM (e.g. ?utm_source=) and search params (?q=), directing traffic to correct locale. Something that indicates we should be preserving all query params would be amazing. Glad to see this is actively developing.
We currently use
netlify.toml … could re-write to
_redirects but ideally wouldn’t have to (though would prefer to rewrite if it made the solution quicker to implement).
My understanding is the issue lies somewhere above
_redirects. For both of these, you need to specify all combinations of query parameters. I’m assuming that a fix will allow use of either one to implement redirects that keep arbitrary query parameters intact without having to write out the params in configuration files.
Thanks for the clarification @robert! If you happen to know, could you possibly show me an example of how I could go about even getting one or two permutations done? I’m trying to understand the complexity. Would love to ideally be able to account for at least
utm_medium for two of my redirect rules.
Hey! I just wanted to follow-up and see if there was any movement here. Thanks!
I don’t see things changing anytime soon here, Thomas. The work for 301/302 redirects is complicated and there are a lot of decisions to be made, so I’d suggest it is best to work within the constraints of our current setup (specify all combinations of params explicitly) for success in the near term.
I promise we’ll follow up here if things change.
I just found a better way to do this. In my case, I am redirecting an entire domain. Using Cloudflare completely solves the issue for me with a single setting:
*revddit.com/* now redirects to
This works for wildcard subdomains and query parameters. The domain you are redirecting (in my case,
revddit.com) must be managed by Cloudflare.
Hi, has there been any update on this?