Redirect loop on attachment pages

[OPunWide]

Summary: a URL to an attachment page will redirect to itself in an infinite loop in certain cases.

Speculation: this may be due to my permalink structure, which would be why others are not complaining about it.

This issue depends on the letter case of the URL. The attachment pages exist, and there is a method that allows them to be accessed, however they cannot be reached if the link is all lowercase letters. Because that is the link generated by the Media Library, users can encounter this.

It took me a while to convince myself that this is a WP core issue because it does not happen on all servers. After adding logging code to some of the action hooks, I could see that a URL comes in and then generates a redirect, using wp_redirect, to the exact same URL that was requested.

My permalink structure is /%postname%.html, and the WP portion of the site is in a subdirectory, so WP pages are accessed as: ​http://yourfriendpaul.com/wp/shredding-on-my-guitar.html

Trying to reach the attachment page using this URL will result in an infinite loop:
​http://yourfriendpaul.com/wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900

Trying to reach it with this one will succeed, note the uppercase C. Making ANY letter in path uppercase will make it succeed:
​http://yourfriendpaul.com/wp/shredding-on-my-guitar.html/good-at-shredding-dsCn4850-1200x900

To complicate matters further, this does not happen on my Ubuntu server, but does happen on GoDaddy with the exact same database (other than site name).

This is my first bug report, so I'm not sure how much info to put in the initial report. The following is an excerpt from my error log, with some notes added. Sorry for the formatting, it is just pasted.

Thanks in advance for looking into this.
Paul

The data is captured using the error log.
The first entry is made in wp-config.
The next 3 lines are when yfp_functions is loaded.
It creates the function that prepends **yfplog to an error message.
The final three lines are from the action hooks indicated.

	` # A call in all lowercase has multiple tries, in bursts, which loop and cause 301 redirects to the original URI,
	` # but one uppercase letter avoids any redirects and finds the content. Only two of the redirects are shown.
	` 
	` [24-Jan-2017 06:19:04 UTC]   *** in wp-config.php, REQUEST_URI is /wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900
	` [24-Jan-2017 06:19:04 UTC]   **fyplog - *** Log writing is enabled in yfp_functions, making funcion yfp_write_log()
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -   script: /wp/index.php
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -   uri:    /wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -  wp_loaded() action was called.
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -  wp_redirect() action was called, location: http://YourFriendPaul.com/wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900, status: ""
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -  wp_redirect_status() action was called, location: , status: "301"
	` 
	` [24-Jan-2017 06:19:04 UTC]   *** in wp-config.php, REQUEST_URI is /wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900
	` [24-Jan-2017 06:19:04 UTC]   **fyplog - *** Log writing is enabled in yfp_functions, making funcion yfp_write_log()
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -   script: /wp/index.php
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -   uri:    /wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -  wp_loaded() action was called.
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -  wp_redirect() action was called, location: http://YourFriendPaul.com/wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900, status: ""
	` [24-Jan-2017 06:19:04 UTC]   **fyplog -  wp_redirect_status() action was called, location: , status: "301"
	` 
	` [24-Jan-2017 06:19:49 UTC]   *** in wp-config.php, REQUEST_URI is /wp/shredding-on-my-guitar.html/good-at-shredding-dsCn4850-1200x900
	` [24-Jan-2017 06:19:49 UTC]   **fyplog - *** Log writing is enabled in yfp_functions, making funcion yfp_write_log()
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -   script: /wp/index.php
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -   uri:    /wp/shredding-on-my-guitar.html/good-at-shredding-dsCn4850-1200x900
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -  wp_loaded() action was called.
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -  ******* in function get_attachment_link()
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -  ******* in function get_attachment_link()
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -  ******* in function get_attachment_link()
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -  ******* in function get_attachment_link()
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -  ******* in function get_attachment_link()
	` [24-Jan-2017 06:19:49 UTC]   **fyplog -  ******* in function get_attachment_link()

[breshich]

Hi all,

We are experiencing similar issue after 4.7.1 update and now still on 4.7.2.

After processing encoded URL as parameter on index.php, WP issues a 301 request with same parameter, but this time decoded. This happens only sometimes and then triggers an infinite redirect loop, onto itself.

Temporary workaround that worked for us was switching permalink structure from Day and name to Plain, however we hope that it would be possible to revert it soon.

Let me know if you need any additional information.

Thanks,
H.

[OPunWide]

I haven't started a trouble ticket before, so I'm not familiar with the fixing timeframe. How long does it tend to take before there is any activity? Is there anything I can do to move along the process?

I don't really think this is a "Media" problem, for what it's worth.

Visitors to my site have been getting redirect loops for six weeks on pages such as http://yourfriendpaul.com/wp/shredding-on-my-guitar.html/good-at-shredding-dscn4850-1200x900 and http://yourfriendpaul.com/wp/the-illusion-of-control.html/placebo-like-icon.

[geekysoft]

Same exact issue.

[geekysoft]

@OPunWide, somewhere in either WordPress or your server setting, you‘ve inadvertently used upper case characters in your domain (YourFriendPaul.com should be yourfriendpaul.com everywhere.) From your server headers, it looks like it’s somewhere in WordPress’ configuration. (The following header is produced by WordPress.)

Location: ​http://YourFriendPaul.com/wp/the-illusion-of-control.html/placebo-like-icon

The infinite redirects here are caused by a WordPress bug when comparing an upper-case domain to a lower-case domain. I’m trying to narrow down exactly where this comparison takes place.

---

For my own situation, I have a reverse proxying server in front of WordPress. Files are fetched from origin.example.com and served as www.example.com. Every other WordPress page gets the correct www.example.com page in every URL. However, for attachment pages there is some strange URL magic going on in redirect_canonical() that reads the server hostname from $_SERVER instead of WP_HOME. This is also a bug. There are a lot of assumptions and mistakes in this code that differs from the rest of Core.

[OPunWide]

It seems very odd that something like that would only happen in this one case, and that it only happens with some URL case variations.

Perhaps having any uppercase in anything after the hostname kicks off some sort of correction code that isn't seen if its only in the host name.

Yes, I prefer mixed case domains because it makes the words decipherable.

Replying to geekysoft:

@OPunWide, somewhere in either WordPress or your server setting, you‘ve inadvertently used upper case characters in your domain (YourFriendPaul.com should be yourfriendpaul.com everywhere.) From your server headers, it looks like it’s somewhere in WordPress’ configuration. (The following header is produced by WordPress.)

Location: ​http://YourFriendPaul.com/wp/the-illusion-of-control.html/placebo-like-icon

The infinite redirects here are caused by a WordPress bug when comparing an upper-case domain to a lower-case domain. I’m trying to narrow down exactly where this comparison takes place.

[OPunWide]

An issue for 14 months and this still has a status of "Awaiting Review".

Because I'm only experiencing the problem in one area, and it's not something that is widely used, I just let this be and waited. I figured that at some point it would bubble to the surface in the bug fix process.

Now I'm running into trouble with Google because of a Redirect Error:

"Search Console has identified that your site is affected by 1 new Index coverage related issue. This means that Index coverage may be negatively affected in Google Search results. We encourage you to fix this issue."

It seems that there was a potential clue, when the "WordPress bug when comparing an upper-case domain to a lower-case domain" issue was raised 8 months ago. So I waited again.

Today I updated to the latest WP (4.9.5), and the problem still exists. Changing to a lower-case URL in the General Settings Site Address does seem to fix it, based on very minimal testing. As stated before, to improved readability I'd rather not do that, but am feeling backed into a corner when Google complains. The fact that I can mask the problem with this setting does not, to me, mean that the bug no longer exists.

[niceguyit]

This seems to be the same issue as ticket #21602. The STR are listed in comment 5. I'm using the Enigma theme which triggers the bug by calling is_front_page().

For me, the solution was to make the home_url('/') lowercase to match $_SERVER['HTTP_HOST']. YMMV

Line 177: wp-includes/canonical.php

        } elseif ( is_page() && !is_feed() && 'page' == get_option('show_on_front') && get_queried_object_id() == get_option('page_on_front')  && ! $redirect_url ) {
            $redirect_url = strtolower(home_url('/'));