[wp-trac] [WordPress Trac] #37115: recent canonical change is giving an infinite 301 redirect loop

[WordPress Trac]

#37115: recent canonical change is giving an infinite 301 redirect loop
-------------------------------------+-------------------------------------
 Reporter:  solomon123br             |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Canonical                |     Version:  4.4.2
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch dev-         |     Focuses:  accessibility,
  feedback                           |  performance
-------------------------------------+-------------------------------------
Changes (by gonlos):

 * keywords:  reporter-feedback => needs-patch dev-feedback
 * focuses:   => accessibility, performance


Comment:

 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 make sense, unlike redirects to bogus locations such as
 {{{http:///}}}.

 ---

 As promissed a script to ease testing is below.
 [http://hastebin.com/noyacabile.bash Here] you can also see the full
 results I get when runing 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...

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37115#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform