Amplify-console: Rewrite for 404's cancelling out trailing /'s

[HMilbradt]

Describe the bug
Under the heading "Trailing slashes and Clean URLs", it says:

The Amplify Console automatically creates clean URLs by adding a trailing slash when required.

This works great on it's own, but we needed to add 404 handling for our static site, so we added the following rule:

EDIT: Adding 404 rewrite
/<*> rewrites to /200.html - 404 rewrite

This also works great. We no longer see the "Access denied" error that is returned for 404's. However, adding this breaks the clean URL functionality, and we're now seeing all our URL's twice in analytics, once with a trailing /, and once without it, depending on how the user lands on the page.

It looks like the rewrite that's applied to clean URL's is applied after the 404 fallback rule, which of course just means that the rule is never hit.

To Reproduce
Steps to reproduce the behavior:

1. Add the above rewrite rule
2. Navigate to a page that had trailing /'s applied before
3. Observe that no trailing / is added

Expected behavior
I would expect the clean URL's rule to be applied before the fallback 404 rule.

Context
Our site is statically generated, and has routes like a final folder structure like /blog/index.html.

Bonus
We would really like the ability to just define a 200.html or 404.html, and have Amplify automatically pick that up and rewrite to it when a page cannot be found. A lot of other static hosting providers do this already, making for a much easier integration with the platform. We actually didn't even notice the "Access denied" issues until someone pointed them out to us.

[Joycehao19]

Hi @HMilbradt , Could you please provide your appID and region to us?

[HMilbradt]

The app ID is d3bsiju3l3vwuf, and the region is us-east-2. However, we've since removed the rewrite rule to prevent our analytics data from being tainted. Currently, a 404 is served with the S3 "Access Denied" page.

I did just try re-adding the rule, and noticed that the behaviour was a bit different. Instead of only rewriting traffic that doesn't have a matching page, it seemed to apply the rewrite rule to all pages.

[HMilbradt]

I did a little more testing, and realized my original post is incorrect. The redirect that does what I describe in the post is this:

source: /<*>
target: /200.html
type: 404 rewrite

Using this fixes "Access Denied" errors, but allows trailing and non-trailing URL's to pass through, which are counted separately by our analytics.

I will be leaving this rewrite on in case you need to debug this 👍

[Joycehao19]

Thank you for providing the test case. We cut a ticket in our team backlog.

[HMilbradt]

Thank you. Feel free to reach out to me if you need any more info on this, I'd be more than happy to help 🙏

[Joycehao19]

Hello, @HMilbradt
once with a trailing /, and once without it, depending on how the user lands on the page.
Can you provide some user cases, with / and without?

[HMilbradt]

One example is /blog/ and /blog. Our site is being linked externally, and we get almost all our pages coming in with and without trailing /'s which we don't control. I've read the section on trailing slashes, and can confirm that a page like /blog/index.html is not being rewritten when /blog is received.

Before adding the catch all 404 rule i mentioned above, the /blog would be rewritten to /blog/, and our analytics would work correctly. However, with the rule added, /blog is being treated as a 404 instead, not being rewritten, and being counted as a separate page in analytics.

[talebbits]

Can confirm this behaviour, what we also having after add 404 redirect.

[lettertwo]

We managed to work around this (for now) by implementing the 404 redirect as suggested in this comment.

[HMilbradt]

Thanks @lettertwo, we'll give this a try

[swaminator]

@HMilbradt @lettertwo @talebbits we released a fix. Could you please verify?

[HMilbradt]

@swaminator Unfortunately, we decided to migrate off Amplify to netlify due to #396, so I'm unable to test.

[swaminator]

@HMilbradt sorry to see you go. I added a clarifying question on #396.