Search parameters are redirected
This link should lead to an alternate view of the ESG page: https://galaxyproject.org/projects/esg?solo=true
Instead it is redirected to the default view. Upon further inspection, all URLs containing search parameters are redirected with a 302 response. I can not reproduce this behavior locally, even with a production build, so I suspect this may have to do with the nginx configuration.
In some quick testing it looks like it's the lack of a trailing slash causing the issue; https://galaxyproject.org/projects/esg/?solo=true works fine. My guess is nginx trying to append slashes to the end of urls.
Who is in charge of the nginx? Is that @natefoo?
I could try changing all the internal links to contain a trailing slash
Yeah, using slashes as appropriate on the URLs is a fine quickfix.
Here's the configuration for galaxyproject.org if you want to take a look: https://github.com/galaxyproject/infrastructure-playbook/blob/main/env/galaxy/templates/nginx/galaxyproject.j2
It seems odd we should need to do the redirect to append a / in the proxy - I've never seen an application not handle this correctly.
Is the 302 actually coming from aws? (I think it is, note x-amz-error-code)

Good catch, yes, this is indeed S3. Specifically I believe it's the automatic index.html feature for static website serving. Here is a similar discussion: https://github.com/jariz/gatsby-plugin-s3/issues/51
Is there a reason we didn't just make this served by CloudFront? I am not sure if it would have the same issue (but could be addressed with the Lambda@Edge rule there, but in general it'd probably be preferable to being served from an EC2 instance.
No specific reason for picking this model; I think that's just what we already had set up for something else?
I originally really wanted to just use netlify but the build is too big for my free plan; I can revisit options. There was a cloudflare version I wanted to try, too.
Ok, just let me know. I have 4 different sites using CloudFront now so this should be relatively straightforward, except maybe for getting certs on the root of a domain not in Route 53.
@natefoo Yeah, if it'd be easy enough then let's just do that and swap over; no need to investigate other options if you're happy with CloudFront. Just let me know what I need to do -- I guess we'd just need to tweak the publishing destination for the github action here (at least as far as changes on the hub repo side)?
No, that's the best part, it'll just serve the bucket, so you shouldn't have to change anything on the backend.
There will unfortunately be some downtime as DNS propagates and for domain validation to get the cert.