recent canonical change is giving an infinite 301 redirect loop

[solomon123br]

Hello,
For 4.5.2 in canonical.php line 175, in prior versions there was an elseif condition which was removed. Can you please add it back?

&& isset($wp_query->queried_object) &&

For example, when we have akamai injecting GET parameters to our home page, it just goes in an infinite 301 loop due to line 175 now evaluating TRUE when in the past it would evaluate as FALSE, and we'd like that back.

Please and thank you awesome wordpress team!

[lukecavanagh]

Okay.

​https://github.com/WordPress/WordPress/blob/master/wp-includes/canonical.php#L175

[solomon123br]

Same as this : ​https://wordpress.org/support/topic/45-causes-infinite-redirect-on-static-front-page?replies=7

[solomon123br]

Not sure why that was removed by dd32: ​https://github.com/WordPress/WordPress/commit/84a3b4407f9e03311aa591004f3bec0639f3ba3f#diff-dc3247fd3fa65f15e6fc5ce8c6fa2d42

[swissspidy]

@solomon123br Have a look at [36237] and #35344 for the reasons behind these changes.

[gonlos]

I have been slaming my head against this bug for about two days. I was migrating a Wordpress instance into Docker and I noticed the bug while testing on my machine. It took me long to figure how to reproduce the problem on a fresh install of Wordpress 4.6.1.

The HTTP 301 redirect happens when under Settings > Reading the option "A static page" is set and a "Front page" is selected. When this option is unset or no page is selected the HTTP redirect does not happen anymore.

Below I leave details which might be useful when understanding/fixing the bug. Bear with me:

I noticed the bug when I was setting up a (Nginx) proxy through wich the requestes reached the container with Wordpress/Apache. The proxy rewrote the Host header to bar and Wordpress would reply a HTTP 301 with a Location: http://localhost, where localhost is the value of Wordpress's wp_options.option_name="home" in the database.

The browser, seeing a redirect to http://localhost would then perform a request to that URI, which would again be rewritten to Host: bar... and everything happens again. The web browser eventually says it has been redirected too many times and stops.

I wrote a script (which I leave at the end) to check exactly for which requests the redirect happened. Below are some cases I find interesting. These results were obtained for an empty .htaccess and without any proxy.

With "static page" selected (the bug occurs)

Notice the first two cases the redirect makes no sense at all!

+ GET / HTTP/1.0\n\n
HTTP/1.0 301 Moved Permanently
Location: http:///

+ GET /index.php HTTP/1.0\n\n
HTTP/1.0 301 Moved Permanently
Location: http:///

>> This one causes the redirect loop <<
+ GET / HTTP/1.0\nHost: bar\n\n
HTTP/1.0 301 Moved Permanently
Location: http://localhost/

+ GET / HTTP/1.1\nHost: localhost\n\n
HTTP/1.1 200 OK

>> And his one too <<
+ GET / HTTP/1.1\nHost: bar\n\n
HTTP/1.1 301 Moved Permanently
Location: http://localhost/

With no "static page" selected (no bug)

+ GET / HTTP/1.0\n\n
HTTP/1.0 200 OK

+ GET /index.php HTTP/1.0\n\n
HTTP/1.0 200 OK

+ GET / HTTP/1.0\nHost: bar\n\n
HTTP/1.0 200 OK

+ GET /index.php HTTP/1.0\nHost: bar\n\n
HTTP/1.0 301 Moved Permanently
Location: http://bar/

+ GET / HTTP/1.1\nHost: bar\n\n
HTTP/1.1 200 OK

In summary: without the bug, only rewrites such as /index.php to / happen and when they happen the Host header is left unchanged. This makes sense, unlike redirects to bogus locations such as http:///.

---

As promissed a script to ease testing is below. ​Here you can also see the full results I get when running the script with and without the bug active.

#!/bin/bash

WP_PORT="80"

for ver in "1.0" "1.1" ; do
  for host in "" "Host:" "Host: bar" "Host: localhost"; do
    for page in "/" "/index.php" "//"; do
      set -x
      echo -e "GET $page HTTP/$ver\n$host\n\n" | nc localhost $WP_PORT | head
      set +x
    done
  done
done

# pipe this script to
# grep --color -E "301|$"
# to display in color the return codes you want

@solomon123br Can you bump the version number of the ticket to 4.6.1? It still happens with this version...

[swissspidy]

Can you bump the version number of the ticket to 4.6.1? It still happens with this version...

No version bump. The version field is there to indicate the version a bug first appeared.

[afercia]

Removing the accessibility focus since it should be used for issues related to ​universal access for all users.