Query strings with reserved characters get wrongly redirected to encoded variant at the root level.

[madstegge]

The asterisk ("*", ASCII 2A hex) and exclamation mark ("!" , ASCII 21 hex) are reserved for use as having special significance within specific schemes. Source: ​https://www.w3.org/Addressing/URL/4_URI_Recommentations.html

More here: ​https://developers.google.com/maps/url-encoding

WordPress however, redirects to a URI encoded variant when the query string at the root level contains these reserved characters.

So, ​https://wordpress.org/plugins/?test=123*456 doesn't redirect.

While ​https://wordpress.org/?test=123*456 redirects to ​https://wordpress.org/?test=123%2A456.

This is quite problematic for all WordPress sites that use for example Google Analytics 4 (GA4) cross-domain tracking. GA4 relies on a query string containing asterisks. Source: ​https://support.google.com/analytics/answer/10071811?hl=en

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the report.

Replying to madstegge:

WordPress however, redirects to a URI encoded variant when the query string at the root level contains these reserved characters.

So, ​https://wordpress.org/plugins/?test=123*456 doesn't redirect.

While ​https://wordpress.org/?test=123*456 redirects to ​https://wordpress.org/?test=123%2A456.

I could not reproduce the issue on a clean install. Testing with some other sites like ​https://ma.tt/?test=123*456, they don't redirect either.

WordPress.org does indeed redirect as noted, but I think that might be something specific to that particular network.

[madstegge]

Replying to SergeyBiryukov:

I could not reproduce the issue on a clean install. Testing with some other sites like ​https://ma.tt/?test=123*456, they don't redirect either.

WordPress.org does indeed redirect as noted, but I think that might be something specific to that particular network.

That's interesting. All WordPress sites that I know of present this behavior. But it might be caused by a widespread plugin then. I'm not a developer, so can't give any more details about the affected configurations.

[madstegge]

The good news is that Google Analytics seems to handle the encoded query string correctly after all. But it might cause difficulties for other applications...

[costdev]

Removing trunk as this has existed since before the 6.0 release cycle.

I can reproduce this on one site, and not on another. I've compared the plugins/themes/permalink settings and there's no difference that should have any impact on URLs/query strings. Both sites have existed for at least two years and both are currently running 5.9.3.

If I find out more, I'll post it. Until then, if others can test this and try to track down the cause, that would be great.