Recently at ru.wikipedia.ru Location headers started to be served uncorrectly (partially encoded, partially not). While some browsers have a fix for it, latest Chrome (most importantly) and some other branches of WebKit was not ready. As a result after each edit redirects lead to "type 25 pollution" of URLs and to "unacceptable symbol %D0" error page. Like this one (see parasite 25's in the URL)
The problem is reported to Chromium and they will restore the fix (their todo letter enclosed at the bottom). Still they asked to mention, that it is not a correction but a fix to fight with some servers non-standard behavior - ru.wikipedia.org this time.
So I'm mentioning it here. And if the headers will be corrected right now, Chrome users will not have to wait for the fix to have their work at Wikipedia restored.
The Chromium letter:
Fix handling of half-escaped Location headers.
Non-ASCII characters in URLs are supposed to be percent-escaped. This
includes when those characters are used in Location headers. However, we
tolerate unescaped characters by escaping them ourselves at various
stages in the process.
ru.wikipedia.org sometimes sends redirects where the path is
percent-escaped, but the fragment is not. Previously, we would fix the
escaping in the fragment, but leave the path as-is. However,
https://chromium-review.googlesource.com/c/chromium/src/+/1366759
switched it to always unformly escape everything, so the %s became %25.
This causes us to follow the redirect incorrectly.
Uniformly escaping things makes sense for NetLog, where we want to
unambiguously represent what the server actually sent, but escaping as
part of URL resolution as not intended to be invertible. Restore the old
behavior here and add some regression tests.
Bug: 942073
Change-Id: I009bc0dc9c5c8f836f072fe23ccd824698d550e0