We have a large website that we split up into multiple Netlify sites. Our main site is www.dokteronline.com which we use to handle redirects and proxy to all the 9 (language) subsites.
We have Pretty URL optimization activated on all the subsites, and when visiting a page without a trailing slash on this subsite it gets redirected to the URL with the trailing slash. (ex: https://dokteronline-pt.netlify.app/pt/saude-dos-homens)
But the problem still remains that the 301 redirects are working when visiting the Netlify site directly, but they are not working when visiting the site when using Netlify proxies.
dokteronline-pt.netlify.app >> redirect is working dokteronline.com/pt >> [proxy redirect to dokteronline-pt.netlify.app] >> redirect is not working
I believe the redirects in the netlify.app subdomain is because the file being served is /saude-dos-homens/index.html. So technically /saude-dos-homens should return a 404 as browsers would look for /saude-dos-homens.html. But Netllify normalises this and serves /saude-dos-homens/index.html.
The behaviour that you see on dokteronline.com/pt is expected. Weâre proxying to the destination URL and are able to serve the file from there. When we normally make proxy rewrites, we respect the 301 header and redirect, but in the case I explained in the paragraph before, the 301 is getting ignored as thatâs a 301 set automatically by us and not by the user.
To solve SEO issues, I think you should add canonical tags.
curl -I https://docs-v5--material-ui-x.netlify.app/x/advanced-components is a 301 to https://docs-v5--material-ui-x.netlify.app/x/advanced-components/ where the underlying file served is /x/advanced-components/index.html
However, when we use a proxy: (/x/* https://docs-v5--material-ui-x.netlify.app/x/:splat 200) then the trailing slash auto redirection does not longer work.
Proof: curl -I https://mui.com/x/advanced-components is a 200.
The two sites you referenced appear to have different asset optimization settings. To resolve the issue, youâll need to:
figure out which site works the way you want, then go to the other site and
uncheck the âDisable asset optimizationâ setting in Site settings > Build & deploy > Post processing > Asset optimization
mirror the settings from the working site
recheck the âDisable asset optimizationâ setting
You may be wondering why you need to disable and then re-enable asset optimization. We have an open bug and disabling and re-enabling is the workaround until we can roll out a fix!
Apologies we donât have any docs on this, but you may want to check out our support guide on trailing slash behavior to get a better understanding.
I have updated the new sites to have the exact same asset optimizations and redeployed. It didnât solve the problem. @audrey I think that this could be turned into a bug.
Sorry for the delay. We think we know what is happening and have an explanation. Let us know if it makes sense to you. TL;DR, what youâre seeing is probably the way you want this to work instead of the other way it would work. Here goes the explanation:
When you use Netlifyâs Proxy feature, we respect the headers sent by the destination server. For example, consider the following situation:
You setup https://my-proxy.netlify.app/ to proxy to https://www.google.com/
You visit https://my-proxy.netlify.app/ and expect to see https://www.google.com/.
https://www.google.com/ sends a 301 status code and redirects the client to https://www.youtube.com/
Netlify would respect those headers and send a 301 to redirect to https://www.youtube.com/. Basically, the URL in the address bar would now show https://www.youtube.com/ and not https://my-proxy.netlify.app/.
In your case though, we actually send a 301 on the proxy destination. But, we treat internal proxies a bit differently than external proxies. So, we are able to normalise the URL and send a 200 response. Instead, if we send a 301 like we do for the actual site, the proxy would break and youâd be 301 redirected to the destination URL. This is not something you probably want.
We can add this as a feature request to support handling this 301 differently, but I donât think there would be any immediate actions about this.
I think that I have found another manifestation of how Netlify handles internal redirects differently than external ones. When the URL has a case issue, e.g.
https://mui.com/material-ui/getting-started/overvieW/ get redirected to https://mui.com/material-ui/getting-started/overview/
However, when the URL is a proxy, this doesnât work, e.g. https://mui.com/x/react-Date-pickers/Date-range-picker/.
We could look into using two different hosting providers to get this fixed (so itâs no longer an internal redirect).
Because it is not possible to create 301 redirects to get a trailing slash in netlify.toml, it is a nesseccary feature for us to enable 301 forwarding if we use the internal proxy to get content from servers outsite of netlify.
I think this is often needed for migration tasks to netlify.
Hi, @tom_morello. The redirect rule is redirecting this URL:
https://www.stayery.de/impressum
To this URL:
https://typo3.stayery.de/impressum/
It is redirecting a non-trailing slash URL to a URL with a trailing slash (redirecting to https://typo3.stayery.de/impressum/).
That URL with the trailing slash returns a 200 status. That 200 status is then returned to the client. There is no 301 redirect because the proxy target sends a 200 not a 301.
The solution for this will be to add one more redirect before the one above like so:
[[redirects]]
from = â/impressumâ
to = âhttps://typo3.stayery.de/impressumâ
status = 200
force = true
[[redirects]]
from = â/impressum/*â
to = âhttps://typo3.stayery.de/impressum/:splatâ
status = 200
force = true
If that doesnât resolve the issue or if there are any question, please let us know.
Yup, we donât intend to support automated trailing slashes on remote resources that we proxy to - we donât try to change the proxyâd response at all.
I think youâll need to implement a 301 on the server at typo3.stayery.de if the content you serve from there requires this.
,
