But https and www. don't.
There was gerrit change 53264 yesterday but no idea how it could have this effect.
Version: unspecified
Severity: minor
URL: https://www.mediawiki.org/wiki/Thread:Project:Current_issues/API_request_for_mediawiki.org_being_redirected_to_en.wikiquote.org
RewriteCond %{HTTP_HOST} =wikiquote.com [OR]
RewriteCond %{HTTP_HOST} =wikiquote.net [OR]
RewriteRule ^(.*)$ http://wikiquote.org$1 [R=301,L]Note the last RewriteCond as an [OR] statement that should probably not be there.
These are all the redirects to that domain which my script can find (including the correct wikiquote.com one):
bookshelf.wikimedia.org -> http://wikiquote.org/
commons.wikipedia.org -> http://wikiquote.org/
wikivoyage.de -> http://wikiquote.org/
wikiquote.com -> http://wikiquote.org/
mediawiki.org -> http://wikiquote.org/
meta.wikipedia.org -> http://wikiquote.org/
it.wikimedia.org -> http://wikiquote.org/
www.meta.wikimedia.org -> http://wikiquote.org/
hu.wikimedia.org -> http://wikiquote.org/
wikivoyager.de -> http://wikiquote.org/
boards.wikipedia.org -> http://wikiquote.org/
wikivoyage.com -> http://wikivoyage.org/
wikimania.wikimedia.org -> http://wikiquote.org/
... ignore the random correct wikivoyage one in there as well. I manually filtered the output and missed that one :P
The root cause was fixed, so no new redirects are not going to get issued. I've explicitly purged from our caches all of the URLs mentioned in comment 6, let me know if you find more that need explicit purging.
(In reply to comment #8)
The root cause was fixed, so no new redirects are not going to get issued.
I've
explicitly purged from our caches all of the URLs mentioned in comment 6, let
me know if you find more that need explicit purging.
Did you purge URLs with path and/or params?
$ curl 'http://commons.wikipedia.org/w/index.php?title=%25' --stderr - -v | grep Location
< Location: http://wikiquote.org/w/index.php?title=%2525
Please also check the double-escaping issue.
(In reply to comment #9)
Please also check the double-escaping issue.
AFAIK that's bug 20409 (allegedly fixed).
wikivoyage.com also works meanwhile.
Faidon purged the URL as well:
11:48 < paravoid> I just purged it, so unlikely
11:48 < paravoid> try shift+f5
11:48 < Krenair> works now
(In reply to comment #14)
Fixed by Faidon.
For the record:
Change-Id: I6b4143de2299578b30deb2e9972f14b163b2afe0
(In reply to comment #9)
(In reply to comment #8)
The root cause was fixed, so no new redirects are not going to get issued.
I've
explicitly purged from our caches all of the URLs mentioned in comment 6, let
me know if you find more that need explicit purging.Did you purge URLs with path and/or params?
$ curl 'http://commons.wikipedia.org/w/index.php?title=%25' --stderr - -v |
grep Location
< Location: http://wikiquote.org/w/index.php?title=%2525Please also check the double-escaping issue.
This given case still fails.
(In reply to comment #17)
(In reply to comment #9)
(In reply to comment #8)
The root cause was fixed, so no new redirects are not going to get issued.
I've
explicitly purged from our caches all of the URLs mentioned in comment 6, let
me know if you find more that need explicit purging.Did you purge URLs with path and/or params?
$ curl 'http://commons.wikipedia.org/w/index.php?title=%25' --stderr - -v |
grep Location
< Location: http://wikiquote.org/w/index.php?title=%2525Please also check the double-escaping issue.
This given case still fails.
It was probably stuck in squid cache, logged in with no cache that commons.wikipedia url works fine.
I purged it from squid cache and it works now (tested in incognito mode with no cookies/cache, logged out).
I experienced a hour ago with mediawiki.org but I wasn't debugging so I don't know what it means.