Redirects don't preserve query params

[muffinresearch]

As noted in mozilla/addons#8234 a redirect doesn't appear to preserve query params.

For example:

https://extensionworkshop.com/documentation/themes?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=dev-hub-legacy-menu-link

is redirected to:

https://extensionworkshop.com/documentation/themes/

Presumably this relates to s3 or cloudfront configuration? Can this be updated to preserve query params?

According to https://stackoverflow.com/questions/30775068/amazon-s3-redirect-rule-preserve-query-params#30798325 there's an option under CloudFront > Behaviors > Forward Query Strings. Though there are also other references in the same question that suggest this doesn't always work.

[bqbn]

Yeah, we already set "Query String Forwarding and Caching" to "Forward all, cache based on all", which means all query strings in viewer requests are included in the cache key and are automatically included in requests that CloudFront sends to the origin.

That's why if we go to https://extensionworkshop.com/documentation/themes/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=dev-hub-legacy-menu-link, we see the query params are preserved.

The problem lies in S3. Particularly, we previously solved the "redirect URLS without a slash to the slashed variant" problem in #586, where we leveraged the x-amz-website-redirect-location property of an object (e.g. /documentation/themes) to redirect access for that object to its slashed partner (e.g. /documentation/themes/). However, when S3 does the redirection, it drops the query params, and unfortunately, we can't configure S3 not to do that.

[muffinresearch]

@bqbn I've filed an issue to workaround this by ensuring links don't cause a redirect for now. Are there any alternatives? Would it be possible to have cloudfront -> nginx -> s3 for example? Thinking ahead, would GCP provide a different solution that would enable redirects to work without losing query params?

[bqbn]

Using Nginx between CloudFront and S3 can be an option. That would require us to change the current architecture design, and maintain a couple of Nginx instances.

A second option may be to leverage the Lambda@Edge to append a slash to the path. We can try this first IMO.

The design and technology used by extensionworkshop.com are applied to a few other static websites that cloudops supports, but AFAIK, ops hasn't looked into how to implement static websites in GCP yet. The best I can tell at this point, moving static websites to GCP is low priority, and will probably happen in later 2022, if at all. That should give us some time to research and experiment how to do it later.