Docs-website: Query parameters require trailing slash

[jbeveland27]

Description

Previously, docs.newrelic.com/search was able to use a query param like q=my-search-string, where the full URL would look like: docs.newrelic.com/search?q=my-search-string.

However, the new site needs a trailing slash to have the same desired effect. So this now becomes: docs.newrelic.com/search/q=my-search-string. I think this is some combo of amplify or gatsby-plugin-s3 not working as expected, as we had a similar issue that was never resolved with the open source site (#413).

I'm raising this as an issue since it might not be apparent to others that query params are sort of broken in general unless a trailing / is used. We just came across this with the Guided Install XP in the newrelic-cli, as we display links like https://docs.newrelic.com/search?query=infrastructure-agent-installer that are now resulting in 404s. We can update our broken links, but I wonder if something can/should be addressed more globally with our Gatsby sites to fix this everywhere.

Steps to reproduce

Broken

1. Visit https://docs.newrelic.com/search?q=test
2. Results in a 404, but expected this to resolve to a search

Working

1. Visit https://docs.newrelic.com/search/?q=test
2. Works as expected

[jpvajda]

@zstix / @jerelmiller FYI on this one

[jpvajda]

@jerelmiller had some good context here, perhaps he can add some information to the issue.

[jpvajda]

@jbeveland27 I'll paraphrase what @jerelmiller said, essentially using the / is something we discovered was a requirement of Amplify and Gatsby at this time. We've reported an issue to AWS about this, so the suggestion was to change your pattern to include the / where ever query params are being used to generate search queries.

You can see a lot of context in this issue: https://github.com/newrelic/docs-website/issues/1014

[jerelmiller]

Apologies for the long delay on my response. I can chat a little more about the technical detail here.

Unfortunately Amplify does not really allow for non-trailing slash routes. At least, it doesn't keep it that way. Gatsby builds the site by creating a folder at the path with an index.html file in it (as you're probably well aware). Because of this, Amplify is unable to match a route without the trailing slash. If you do navigate to a route without the trailing slash, Amplify will attempt to match an index.html file for that particular route and do a 301 redirect if it does find it. You can find out more about this at Amplify's documentation under the "Trailing slashes and clean URLs section": https://docs.aws.amazon.com/amplify/latest/userguide/redirects.html

Up until recently, we used non-trailing slashes everywhere, but as you're seeing, Amplify's redirect behavior would kick in and send a 301 to redirect you to the trailing slash variant of the route. Annoying, but it worked. There were a few cases where we saw some really weird behavior, so instead we opted to force trailing slashes everywhere to try and avoid the 301s when clicking on links.

All this to say, when you're now linking to the docs, its best to use a trailing slash, even with query params, to avoid that 301. Amplify doesn't seem to want to maintain the query params when it does the 301, which doesn't help. Also of note, the /search route no longer exists and is actually a 404 page. To open the site with the search prepopulated, the q query param is enough. If you can link instead to https://docs.newrelic.com/?q=<search term>, that should fix your problem.