Plugin directory redirecting to wrong plugin

[DvanKooten]

In some browsers, the URL for a plugin redirects you to an entirely different & unrelated plugin instead.

To reproduce the issue, please go to ​https://wordpress.org/plugins/mailchimp-for-wp/ in a browser other than Chrome. It should bring up the MailChimp for WordPress plugin but is instead taking me to ​https://wordpress.org/plugins/changelog/.

Affected browsers:

• Firefox
• Brave
• Mobile Chrome

User report: ​https://wordpress.org/support/topic/download-mailchimp-plugin/

[DvanKooten]

It actually seems to affect Chrome too, the error is just very inconsistent. Sometimes it works for a short timespan (~10 minutes), then it stops working for what seems to be the same timespan. Something cache related?

[tomgreep]

For me it's in all browsers I have access too:

• Chrome on Windows and Android
• Internet Explorer on Windows
• Edge on Windows
• Firefox on Windows
• Opera on Windows

Since I experienced this, it only some of the times worked in Chrome on Windows and Android. But as said before, very inconsistent.

[tomgreep]

Maybe good to see: I used browsershots.org to show ​https://wordpress.org/plugins/mailchimp-for-wp/ in a lot of browsers. About half of them show the correct page, the other half don't.

[WiZZarD_]

Full headers when I open this page are as follows:

Request URL:https://wordpress.org/plugins/mailchimp-for-wp/
Request Method:GET
Status Code:301 
Remote Address:66.155.40.249:443
Response Headers
content-type:text/html; charset=UTF-8
date:Wed, 29 Mar 2017 13:43:40 GMT
location:https://wordpress.org/plugins/changelog/
server:nginx
status:301
strict-transport-security:max-age=360
x-frame-options:SAMEORIGIN
x-nc:HIT lax 249
x-olaf:%E2%9B%84
Request Headers
:authority:wordpress.org
:method:GET
:path:/plugins/mailchimp-for-wp/
:scheme:https
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-encoding:gzip, deflate, br
accept-language:en-US
cache-control:no-cache
cookie:devicePixelRatio=1
pragma:no-cache
upgrade-insecure-requests:1
user-agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

There seems to be a redirect that triggers on something.

[dd32]

There was a few reports of this at launch, which spurred [5178] - I have no idea if that's the code responsible, but it's the only thing I could think of to redirect to that specific path (/changelog/). This is the first i've heard of it still happening since that commit too.

The sporadicness of it is that only one webnode has cached the bad redirect (301's get 1hr caching for logged out users), but I'm still not sure where the redirect has come from

[tomgreep]

Now it also happens for Contact Form 7.

[lukecavanagh]

Not having that issue ​https://wordpress.org/plugins/contact-form-7/
Replying to tomgreep:

Now it also happens for Contact Form 7.

[DvanKooten]

We're still getting reports from several people that they're being redirected to the Changelog plugin. Browsers seems to be caching the HTTP headers so when trying different browsers, you have to be in "luck" to run across it. Once you do, you'll get that same behavior for a short time.

When using curl or wget there seems to be a 50% change of being redirected, even on consecutive runs.

curl -v ​https://wordpress.org/plugins/mailchimp-for-wp/
wget -S ​https://wordpress.org/plugins/mailchimp-for-wp/

Unfortunately, I am far too unfamiliar with the WordPress.org code and/or architecture to dig into this myself (not even sure if I can). This has to be happening for other plugins too, right? Anything in our plugin's README that could be triggering it?

[Otto42]

This is not browser caching, there is nothing you can do to fix it, please don't try to do so.

This is caching on our end and we're sorting it out.

[Otto42]

Update: We have worked out why this is happening. Working on a way to test a fix now.

[Clorith]

#2650 was marked as a duplicate.

[Otto42]

In 5211:

Plugin Directory: Handle redirects for clients that send the URL fragment back to the server after a redirect. Redirect such clients to the URL without the fragment. Fixes #2630.

[Otto42]

Sorry, finally correctly fixed in [5217]. This one took a couple tries because I had to wait for caches to expire to see the results.

The few plugins doing this (3 that we know of) that are currently redirect looping should clear up within an hour, and after that the problem should not recur.

[DvanKooten]

That does seem to do the trick, great! Thanks so much for acting on this.

[tomgreep]

I still had to clear the local cache, but indeed it seems to work!