Expanding functionality of redirects

It would be nice if we could get some basic statistics on our Redirects. I’ve got some redirects that I’m not sure if they are needed anymore, if people are still hitting the old URL or not, and having some usage statistics around how frequently a given redirect rule is hit would be nice.

I second @adrm’s feature request: passing through all existing query parameters is a must-have. I know we can list all the possible combinations of parameters but that’s not a scalable or maintainable solution when there are thousands of possible combinations.

My use-case is migrating an old WordPress site over to a modern stack: I have to implement redirects from pages with extensions like “.php” and “.htm”, but I must keep the existing query string. Query parameters are used for marketing channel attribution: it’s how we know whether a Facebook campaign makes money or how many leads an ad has generated.

Totally agree with @remy.

One of my use cases is similar: respond with the optimal pre-compressed version of a file depending on Accept-Encoding. For instance we have assets pre-compiled during build-time with maximum compression (gzip level 9 and brotli level 11):


For run-time compression I would typically use gzip level 5 and brotli level 4 for a good file size to compression time ratio. But being able to serve heavily pre-compressed files would be ideal.

So I’d love to be able to do something like this:

# netlify.toml (concept, not currently working syntax):
  from = "/assets/css/*.css"
  to = "/assets/css/:splat.css.br"
  conditions = {
    Accept-Encoding = ["br"]
    Content-Encoding = "br"

(I know Brotli is on the Netlify roadmap, this is just one of my use cases)

1 Like

thanks for that additional info @jbmoelker - we’ll definitely keep you all updated when there is movement on this :muscle:

I’ve added our usecase in other threads but will add them here.
Adding all query params to redirect as a rule is a must for us.
We don’t know in advance which URL params the marketing team will decide to pass in all cases.
And to which redirects.

And we’re while migrating the website, are carrying over tons of legacy redirects that there’s no way to know which ones have which GET params.

A blanket rule of “forward everything” like it exists in virtually every other server (NGINX for example) is a must.

@altryne, we do have a recent update which does forward all query parameters during a redirect. There is more about this here:

Note, there are limitation as described in the post above. Quoting that topic below:

The only exception: If your rule target already contains a query string, the proxy will only pass that along, nothing else.


  • /api/* https://my.remote.api/:splat 200! will pass query string unchanged
  • /api/* https://my.remote.api/:splat?key=secret-key 200! will only ever pass key=secret-key

Does this update meet the requirements for your redirects?

@luke there are 2 types of redirects, and IMHO the above only affects the proxy (200) redirects and not 301/302 redirects. Please correct me if I’m wrong.

Thus, it only partly meets the requirements, additionally there’s apparently a bug with the above and it wasn’t deployed to the Enterprise ADN.

The other part it doesn’t meet, is the 301/302 redirects and having them pass parameters too.

For example we have https://fundbox.com/signup?email_prefill=my@email.com
/signup recently moved to https://app.fundbox.com/signup
So after moving to Netlify, the prefill will stop working, unless I manually specify it.

Manually specifying is not possible for 2 reasons:

  1. We may not know what GET params are being uses right now
  2. According to the docs, manually specifying is really curbersome. You need to make sure all GET params exist on a redirect together, and that’s not always the case. Some of them are optional and may not get passed, which makes the whole redirect ordeal really problematic

Yup, you’re right - the proxying isn’t rolled out to the enterprise CDN but we will update here when it does get rolled out there. And you’re also right that it is very tedious and problematic to account for all possible combinations of query string parameters - definitely not trying to debate you on that :slight_smile:

However, our team is still discussing the best way to handle all the edge cases about changing our in-production-on-millions-of-websites old behavior without breaking sites that have worked around it, but we will follow up in this thread as things develop.

Sorry I don’t have any useful news for you today.

@fool can you please double check?
I was under the impression that it’s rolled out already as it’s been working for me on gtm3.fundbox.com/landing-pages/fiverr for example

you can see the prefill working if you add

So either we’re not on ADN or it was rolled out?

That site does not use our enterprise CDN. Mystery solved :slight_smile:

We can direct you on appropriate DNS settings in the helpdesk if you’d like to migrate. Please use your netlify login email (from https://app.netlify.com/user/settings) to contact us either at support@netlify.com or from https://www.netlify.com/support if you do write in.

Cookie based redirect/rewrite

In my static app I’m storing language info on localeStorage. My urls are like this:
/ -> home page with default locale
/ch -> home page with chinese locale

If user visited my app before and set locale to chinese then visits homepage “/” without “/ch” he is redirecing to “/ch” as soon as possible on client side code. Until I read localeStorage then redirect, user sees default locale. Reading locale from cookie and 302 redirect would be better.

My app also redirects visitors to their browser language path if they are at trying to access “/” and if didnt explicitly select another locale. Reading browser locale from window.navigator.language. Instead of doing that i would prefer read “accept-language” header then 302 redirect.

Hmm, if you use a 301 redirect, that should happen automatically, if you use language based redirects:


Does that not work well for you? Shouldn’t require anything on the client side, should never show the wrong content…

Wow. I was didn’t expect to this is exist. This is makes possible my use case I mentioned above. This is awesome.

So can I redirect to user different path if its language anything else than a certain language. Something like:

// I add a exclamation mark for example.
// Imagine my website language is chinese and I wanna redirect users to english if their language is not chinese.
/  /en  302  Language=!zh

Also I’m ignoring bots (e.g googlebot) in my client side redirect code for let the crawlers index pages on its correspondig language. Is this redirect rules do that for me? I dont want to crawlers to be redirected from / to /en because of its browser language.

1 Like

I’d love this to work:
ext:php https://somemirrorofsitewithphpexecution.com/:splat 200!

Thanks for the suggestion @niansa!

1 Like

We would love to be able to redirect Internet Explorer users. So User-Agent based redirection would be a great addition to us.

We no longer support Internet Explorer on our platform and are now showing users a page informing them of this fact. Our current redirection is based on a Vue.js route middleware, but even maintaining support for a “we do not support IE” page has proved to be unnecessarily difficult.

howdy @joaobarcia and welcome to our community!

We think that is a bit of an antipattern (see this article for the reasoning: https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent) so we don’t support it now, but if we change our mind and implement it, we’ll post in this thread to let everyone know :slight_smile:

1 Like
  1. Unfortunately, we don’t support negative matches like that. You’ll need a set of content for the language you want, and to make a 404 page for the content you don’t, something like this may work:
  /* /no-content-for-you.html 302! Language=zh
  /* /en 302!
  1. No rules to ignore bots provided on our service. You can set things like robots.txt or an X-Robots-Tag custom HTTP response header to control that

Thanks for the reply and the update :slight_smile: