The beta3 release of the Cloudflare module changed the priority at which the request event is modified. In 1.0.0-beta2, the ClientIpRestore event subscriber had a priority of 20, which fires after the subscriber in the Redirect module. In 1.0.0-beta3, the CloudFlareMiddleware has a priority of 300, so it fires before the redirect module's event subscriber (as it should, right?).
I think that the problem lies in that the Cloudflare's call to Request::overrideGlobals modifies $_SERVER['QUERY_STRING'] such that the query string no longer matches what the user sent over, and introduces a mismatch between Request::server->get('QUERY_STRING') versus Request::getRequesturi. ?query-var !== ?query-var=.
Later on in the processing (priority=30), the Redirect module accesses $request->server->get('QUERY_STRING') to get the query string, which yields ?query-var=, but also calls $request->getRequestUri() which yields ?query-var.
This results in a mismatch that causes the redirect module to issue a 301 from https://example.com?query-var to https://example.com?query-var=.
on its own, it might be innocuous enough, but...
This change is proving to be somewhat troublesome when combined with the page_cache_query_ignore module.
$_SERVER via a call to Request::overrideGlobals on line 175 of the middleware (this is what transforms the current query parameter from some-query-param to some-query-param=https://example.com?some-query-param and redirects it to https://example.com?some-query-param=some-query-param and some-query-param=, and therefore responds with a HTTP/301 from https://example.com?some-query-param= to https://example.com?some-query-param=, thus forming an infinite loop.Prevent the Cloudflare module from altering $_SERVER['QUERY_STRING'].
Needs manual testing.
None
None
None
Needs review
Code
The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.
Demoting to 'major' -- details will be coming in the I.S., but right now it looks like the lesser used page_cache_query_ignore plays a role here.
Let's see what the test bot thinks of this.