The site is raymondcamden.com
For the two redirects listed above, no files match those paths so there will be no changes to the behavior when the update occurs.
For example with that second redirect above, there is no such directory with an index.html (or a 2014/11/7/ directory with a Cordova-and-Asset-Downloads.html file). There is no file being “shadowed” so the redirect will always occur.
If you want to guarantee that nothing changes, add the “!” to any 301 rule now. Because 301 is the default redirect status if nothing is specified, this also means you would add “301!” to any rule without a status. This would always redirect those rules (which is the current behavior). If all rules are forced now, the current behavior will be guaranteed not to change.
Thanks - that’s what I’ll do.
I’m relying heavily on pretty urls in my _redirect file, like this:
https://www.mydomain.org/privacy.html https://www.mydomain.org/privacy
Does this change mean that I must now have a 301! after the second URL in the rule, like this:
https://www.mydomain.org/privacy.html https://www.mydomain.org/privacy 301!
Hi, @TheeMattOliver. It depends on if files exist at those paths before the redirect.
The 301! means redirect to the second URL even if there is a file deployed at the first URL. The 301 (no exclamation mark) means redirect if the file does not exist but, if it does exist the file itself will be served with a 200.
However, this is not currently how those rules work. It is how they should work, but they all are working like 301! rules instead. So, for redirects which are currently redirecting when a file does actually exists for that URL, they will stop redirecting.
The only way to know for certain if a specific rule needs the “301!” or not is to check the deployed files (with the button in the screenshot below) to see if a file exists which would match that rule. If you have great number of rules, this could be time consuming (or require code to be written to automate the check - which is also a time commitment).
The button to download a deploy is found here:
To know for certain, download a deploy and compare each redirect to deployed files to see if the 301 will stop happening. Using the rule above as an example, if the file privacy.html exists in the base of the unzipped directory tree, the 301 will no longer work after the change and this file will be served with a 200 status instead. If the file doesn’t exist, nothing will change.
So, if you just want to be on the safe side, you can add those "301!"s to rules now and skip the file check. If the “!” isn’t needed, there would never have been a change in behavior; it forces a redirect that would happen anyway. However, if the "301!"s are needed and you add them in advance, you are forcing the current behavior and so, again, no change in behavior when the update comes.
Does this mean that country based redirects will now need to be forced if a file exists at the path or are country based redirects still treated as force redirects? Those weren’t called out as potential problems in the email I received.
Does that mean that all current redirects acts as forced redirects? So if our current set up is working, and we just explicitly mark everything as forced, it will continue to work as it does today?
whoops, sorry I didn’t see your question in a timely @stephenbowling - I’d explicitly force them if you haven’t already, but if you didn’t and they are still working, you have the answer to your question…
Hiya @Tobbe and sorry to be slow to get back to you. All redirects do NOT currently act as forced redirects - only in some cases. If you mark everything as forced (such as this one: Rewrites and proxies | Netlify Docs) and you’ll probably break everything since all site assets will return html instead of e.g. /assets/logo.png…
