Pass url params in rewrites and redirects

[patleeman]

Please describe which feature you have a question about? Rewrites and redirects

Provide additional details Hello, I'm trying to set up a 301/302 redirect from a path in my amplify application. i.e. /test to another domain i.e. https://example.com/test. The redirect works as expected, but if I try to add some url parameters, /test?utm_test=test the redirect strips the url parameter and redirects to https://example.com/test. With the 200 rewrite, url params don't get stripped.

I want /test?utm_test=test&utm_something=something -302-> https://example.com/test?utm_test=test&utm_something=something

I get /test?utm_test=test&utm_something=something -302-> https://example.com/test

Is there a way to pass along all the url parameters in one shot?

As a side note, I am trying to redirect the path including the trailing slash and excluding the trailing slash. i.e. /test and test/. I know you can use the regex route to do both i.e. </(\/test)(\/)?/> -> https://example.com/test but there doesn't seem to be a way to use path parameters with regex paths?

i.e. </(\/test\/<path_param>)(\/)?/> --> https://example.com/<path_param> or even a way to specify the regex match group? --> https://example.com/<regex[1]> or something like that.

Thanks for the help

[apal21]

@swaminator Thanks for the update.

This is working properly if I define the redirects manually like this:

/foo?bar=<value> => /foo/?bar=<value>

But it is not working for dynamic URLs using *. Sometimes it is throwing 502. Any idea on how to implement this?

[Narrator]

@apal21 Could you please share the exact redirect rule that you're using and elaborate on your intended behavior? Thank you!

[eliottparis]

@swaminator Thanks for the update, but I think we are still facing the same problem here, query parameters are not passed to the rewritten URL.

Our redirection rule:

{
   "source": "https://foo.com",
   "target": "https://www.foo.com",
   "status": "301",
   "condition": null
}

$ curl -v -L https://foo.com/player.html?uid=3000
> GET /player.html?uid=3000 HTTP/2
> Host: foo.com
> 
< HTTP/2 301 
< content-length: 0
< location: https://www.foo.com/player.html
< server: CloudFront

> GET /player.html HTTP/2
> Host: www.foo.com

From the documentation:

Query parameters You can use query parameters for more control over your URL matches. Amplify forwards all query parameters to the destination path for 301 and 302 redirects, with the following exceptions:

• If the original address includes a query string set to a specific value, Amplify doesn’t forward query parameters. In this case, the redirect only applies to requests to the destination URL with the specified query value.
• If the destination address for the matching rule has query parameters, query parameters aren’t forwarded. For example, if the destination address for the redirect is https://example-target.com?q=someParam, query parameters aren’t passed through.

I don’t think we are in the exceptions mentioned above, or do we?

[apal21]

@Narrator We have some redirect URLs for OAuth like this:

/salesforce/auth/callback?code=<code> => /salesforce/auth/callback/?code=<code>
/google/auth/callback/?code=<code> => /google/auth/callback/?code=<code>

But I have to put all the rules manually. In some cases, there are multiple query params (?code=<code>&state=<state>). I thought since this is a pattern, is there a way to have a single rule I can write for this? That way I have to maintain a single redirect only.

Thanks.

[Jun711]

@Narrator It doesn't seem to support SPA redirection with query string params I created a thread here but I haven't got any reply https://github.com/aws-amplify/amplify-hosting/issues/2781

For example https://our-website.com/application/path1?param1=XXX&param2=YYY

application is an SPA path1 is a a path managed by the SPA

I tried with 301 redirect but it didn't work. It worked with rewrite but it would drop the query params

Can you at least reply to say if Amplify supports this feature? Thanks

[sadjow]

Details on SSG (Static Site Generator) Websites & Amplify Deployment:

When deploying generated HTML to Amplify, there is an observed behavior regarding query parameters. Specifically, Amplify appears to strip out query parameters in situations where a page redirects to an index.html file inside subfolders.

For root domains, the behavior is as expected. For instance, accessing www.example.com?utm_source=foo seamlessly redirects to www.example.com/?utm_source=foo.

However, challenges arise with subpaths:

Suppose there's a file named contact/index.html. When a user accesses www.example.com/contact?utm_source=foo, Amplify drops the query parameters and redirects the user to www.example.com/contact/, irrespective of any rewrite rules that might be set for query strings.

Consider the default behavior of Nuxt.js as an example. For a pages/contact.vue page component, it results in the creation of an HTML file structured as /contact/index.html. With this setup, Amplify maps URLs in the form of www.example.com/contact to this file, appending a trailing slash in the process. A potential solution to circumvent this issue is to tweak Nuxt's default settings. By setting the subFolders option in Nuxt to false, the generator will produce a contact.html file rather than the contact/index.html structure. Consequently, Amplify would retain the original URL— www.example.com/contact?utm_source=foo—without forcing a redirect.

I suspect there might be an underlying bug in Amplify's code path responsible for appending the trailing slash and inadvertently removing the original query parameters.

[IkKan]

Almost 3 years later and there's no fix yet... 😞

[doc-l]

yeah it could be fixed easily if there just was an option to deploy it on your own S3 bucket instead of Amplify's. You can then add your own cloudfront distribution and have full control of what you need.

We ran my workaround above for a few months, now we have moved completely over from amplify ci/cd+hosting to github ci/cd + s3 + cloudfront while still using the rest of amplify. It works perfectly

[iyunusov]

This is some sorta bull-sh*t, why should query params bother ones setup at first place team amplify? Resolution must be initiated before a workaround.

[DevPowers]

This is happening to me as well, I spent a whole day debugging to figure out the cause and find myself here. Sad to see the issue isn't closed yet after 3+ years

[DevPowers]

Also I haven't seen it mentioned anywhere but if you just use a url with 'www', the query params are preserved.

So trying to navigate to 'example.com/path?query=query1' --results in--> 'example.com/path'

But if you just throw in the 'www' (avoiding the redirect in the first place which strips the params). Such as:

• navigating to 'www.example.com/path?query=query1' --succesfully results in--> 'www.example.com/path?query=query1'

Not a fix at all or even a work around. Just a tip to try and avoid the redirect in the first place.

[simoneagostinelli]

@DevPowers you saved my night!

[dev-sym]

Any hope for this issue to be fixed?

[sadjow]

Believe it or not, the following works:

In the AWS Amplify rewrites section:

• Source address: </^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|woff2|ttf|map|json|webp)$)([^.]+$)/>
• Target address: /
• Type: 200 (Rewrite)

EDIT: this works only for SPA sites.

[dev-sym]

Unfortunately, this doesn't work for me, I am redirecting www to non-www while trying to keep the query string.

[ChoiYongWon]

this solution works for me the whole rewrite and redirection configuration as below

[
    {
        "source": "/<*>",
        "target": "/index.html",
        "status": "404-200",
        "condition": null
    },
    {
        "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>",
        "target": "/index.html",
        "status": "200",
        "condition": null
    }
]

[smada2108-happly]

this solution works for me the whole rewrite and redirection configuration as below

[
    {
        "source": "/<*>",
        "target": "/index.html",
        "status": "404-200",
        "condition": null
    },
    {
        "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>",
        "target": "/index.html",
        "status": "200",
        "condition": null
    }
]

This is so close to working for me but I lose my custom font when I have this rule :(

[sadjow]

this solution works for me the whole rewrite and redirection configuration as below

[
    {
        "source": "/<*>",
        "target": "/index.html",
        "status": "404-200",
        "condition": null
    },
    {
        "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>",
        "target": "/index.html",
        "status": "200",
        "condition": null
    }
]

This is so close to working for me but I lose my custom font when I have this rule :(

You need to include your custom font extension in that list.

[trandaison]

It's 2024 and the issue is still there... Adding trailing slash is not working.

[swaminator]

@trandaison could you explain what you mean by the trailing slash not working?

[trandaison]

@swaminator Sorry for the confusion. In my case, the root cause was the cloudfront was not forwarding the query string to the amplify. So adding the traling slash was not working. The problem was not on the amplify itself.

[mauerbac]

Hello everyone -- this issue has been resolved! Now redirects will preserve the query parameter passed to it. Please let me know if you see the correct behavior. @trandaison @dev-sym @iyunusov

[github-actions[bot]]

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.

[sadjow]

@mauerbac, is it required to declare all the query parameters to it to keep the query parameters in the URL? For example, UTM parameters:

/some-page?utm_content=foo&utm_medium=bar

/some-page/?utm_content=foo&utm_medium=bar

Should we declare variables in all redirects to preserve them, or is this fix still pending deployment?

[mauerbac]

hi @sadjow the team made that change earlier. So a url will go from /some-page -> /some-page/. When doing the redirect it keeps all the query params that was passed to the original request.

[sadjow]

@mauerbac thanks, but for me it still not working. See example: https://www.svenlic.com/contact?foo=bar got removed from the bar after it adds the trailing slash.

[mauerbac]

Do you have any redirect rules? This will work without any the need for redirect rules? I wonder if they could be interfering. What you show should now work without any rules. Let me know what rules are set.

[github-actions[bot]]

This issue has been automatically locked.