https://bugzilla.wikimedia.org/show_bug.cgi?id=53498
--- Comment #10 from Brad Jorsch <[email protected]> --- I haven't found anything new since comment 3. Until just now, anyway. Here are some sample request and response headers, in case they help anyone: GET /wiki/%E1%83%A1%E1%83%90%E1%83%9C%E1%83%A2%E1%83%98 HTTP/1.1 User-Agent: curl/7.32.0 Host: xmf.wikipedia.org Accept: */* Cookie: centralauth_User=Anomie; centralauth_Token=REDACTED HTTP/1.1 301 Moved Permanently Server: nginx/1.1.19 Date: Mon, 30 Sep 2013 16:50:16 GMT Content-Type: text/html; charset=utf-8 Content-Length: 0 Connection: keep-alive X-Content-Type-Options: nosniff Cache-Control: private, s-maxage=0, max-age=0, must-revalidate Set-Cookie: xmfwikiSession=REDACTED; path=/; secure; HttpOnly Vary: Accept-Encoding,X-Forwarded-Proto,Cookie Expires: Thu, 01 Jan 1970 00:00:00 GMT Last-Modified: Mon, 30 Sep 2013 16:50:16 GMT Location: https://xmf.wikipedia.org/wiki/%E1%83%A1%E1%83%9E%E1%83%94%E1%83%AA%E1%83%98%E1%83%90%E1%83%9A%E1%83%A3%E1%83%A0%E1%83%98:AbuseFilter X-Cache: MISS from cp1006.eqiad.wmnet X-Cache-Lookup: MISS from cp1006.eqiad.wmnet:3128 X-Cache: MISS from cp1010.eqiad.wmnet X-Cache-Lookup: MISS from cp1010.eqiad.wmnet:80 As I mentioned earlier, that bears all the signs of coming from OutputPage. But it's somewhat unusual because OutputPage's default is 302, so we only need to look at places where OutputPage::redirect()'s second parameter is being passed 301. I did just find a possible explanation for this while following up that last comment. I see in AbuseFilter::filterAction() it's setting $wgTitle to Special:AbuseFilter if $wgTitle is null. So if that somehow gets called and then RequestContext::getTitle() gets called before MediaWiki::getTitle() is called in MediaWiki::main() (in the process of setting $wgTitle in the first place), then it will pull in that bogus title from $wgTitle instead of calling MediaWiki::parseTitle(). And then MediaWiki::performRequest() is going to find a mismatch between the title it got from the RequestContext and the title in the request and do a 301 redirect. CentralAuth's auto-creation could certainly do it, and it's possible that the call to $this->context->getUser()->isLoggedIn() added in Gerrit change Iaa9dd210 is causing that to happen before MediaWiki::main() sets $wgTitle where before it didn't happen until something later unstubbed the User. Although there must be something else getting into AbuseFilter::filterAction() early in some rare cases. At any rate, if all that is the cause then the fix belongs in AbuseFilter, it should clear $wgTitle if it set it in the first place. I'll submit a patch to do that in a few minutes. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
