Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Client-only routes cause 302 redirects or 404 responses

See original GitHub issue

I’m building an app on top of Gatsby using this package to bundle and deploy the front-end.

Reproduction:

Clone this starter by Nader Dabit that contains some client-side routing https://github.com/dabit3/gatsby-auth-starter-aws-amplify
Deploy it with gatsby-plugin-s3

Current behavior:

RoutingRules will be generated on the s3 bucket which will cause 302 redirects on /app/login to /app. Same thing if you try to hit /app/login directly.

Potential fix:

Add a flag to not generate RoutingRules via the CLI?

Manual fix:

After every deployment, remove certain routes on the s3 buckets RoutingRules

Closing Remarks:

Thank you so much for your hard work. I love/recommend this package a lot.

Issue Analytics

State:
Created 4 years ago
Reactions:1
Comments:10 (2 by maintainers)

Top GitHub Comments

4reactions

pierluigi-giancolacommented, Mar 16, 2020

Hi everyone, I create an example project to reproduce #133 . I’ve tested it and it loops because of the rules written on the bucket.

We generate the redirect rules here. This is the only place we generate them. Since we just generate rules for whatever Gatsby gives us, looks like this isn’t a bug in our plugin.

Even if it’s not a bug in your plugin, I’ll leave the project here so that anyone intrested can investigate.

If I’ll find out anything I’m gonna write the info on this issue.

Thank @JoshuaWalsh for your help, have a nice day everyone.

3reactions

JoshuaWalshcommented, Jun 26, 2019

Hey @jariz, I’m thinking about this one. In an ideal world we would preserve the path. In httpd you would do this using a rewrite, so instead of returning a 301/302 it would perform the redirect within the web server and just return the contents of the destination page.

S3 doesn’t support this and I was wondering how we could. Initially it seemed to me it would need a Lambda@Edge Origin Request function for this, but I’ve thought of a simpler way:

What if we just copy the contents of the rewrite destination to the original path? That should function the same as a traditional rewrite. Obviously the new behaviour should be optional, but I think it would help for many clientside-only route use cases.