A few people have questions & wishlists regarding redirects. If you have an opinion you’d like to share, comment below. The more information we have about your use case, the better! 
1 Like
I want to pre-render different static HTML page versions for mobile and desktop in an SPA, and redirect the user to a correct one on first load to avoid screen flickering. Ideally I’d like to have a redirect rule based on screen size.
1 Like
Conditional redirect based on headers would be handy. One potential use case: redirect to webp image for browsers that support it via the accepts header and fallback to png.
5 Likes
Can you redirect to a netlify function?
Hmm, this article is old, but we believe still mostly valid as general guidance:
While yes, there are cases where this behavior would make things easier, and we do have an open feature request to extend things in this way to which I’ve added this thread’s desires and weight, it’s not sure that we’d implement it considering the TL;DR for that article which is summarized near the top, in a highlight:
It’s worth re-iterating: it’s very rarely a good idea to use user agent sniffing. You can almost always find a better, more broadly compatible way to solve your problem!
You can, @devotox, redirect to a function. Or you could load a function directly that does nothing except sniff the UA and return an HTTP 301 redirect, to the proper version of your site. But it’s pretty inelegant and probably not super speedy to put a function execution in your normal request path…
To be clear: I wasn’t talking about conditional based on the UA, I was talking about conditional based on the Accepts header.
2 Likes
Ah, yes, sorry! Still not possible but less of a bad idea IMNSHO 
We have a separate feature request for things like that which we definitely are considering on the roadmap, so I’ve also linked this thread over there so we can write back here if things change.
2 Likes
Adding to this. My blog has been running for over a decade and there’s a LOT of hotlinking to scripts I’ve written (this is pre-github/cdns etc).
Being able to conditionally redirect based on referrer (or referrer host) would be extremely useful (for controlling hotlinking).
Going by the new analytics Netlify offers, I’m pretty sure hotlinking to a script (that now 404s) is the cause of my overhead of bandwidth.
noted, I’ve added that detail to the feature request.
I think it would be very useful to be able to mark an url as accepting any query parameter and simply passing them through. For example, I imagine this in my redirects file:
/path/* *=* https://other.url/:splat
Meaning to pass through all query parameters from the original URL, and also redirecting if there are no query params. I really don’t understand why this is not the default behavior though, but it would be awesome anyways to have this feature.
4 Likes
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):
assets/css/
main.7bca136736.css
main.7bca136736.css.gz
main.7bca136736.css.br
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):
[[redirects]]
from = "/assets/css/*.css"
to = "/assets/css/:splat.css.br"
conditions = {
Accept-Encoding = ["br"]
}
[redirects.headers]
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 
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.
Examples:
/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 passkey=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 Apply for Fundbox Business Line of Credit In Under a Minute | Fundbox
/signup recently moved to Apply for Fundbox Business Line of Credit In Under a Minute | Fundbox
So after moving to Netlify, the prefill will stop working, unless I manually specify it.
Manually specifying is not possible for 2 reasons:
- We may not know what GET params are being uses right now
- 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 
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
gtm3.fundbox.com/landing-pages/fiverr?email=alex@fundbox.com
So either we’re not on ADN or it was rolled out?
That site does not use our enterprise CDN. Mystery solved
We can direct you on appropriate DNS settings in the helpdesk if you’d like to migrate. Please use your netlify login email (from Netlify App) to contact us either at support@netlify.com or from Support if you do write in.