[18:11:04] Hm.. looks like my vagrant just got randomly corrupted. All page views complain about revision #xx not existing in the database. But if I look in the history, it's all there still. So revision table is fine presumably, but text table disappeared? [18:11:21] older revisions are broken the same way [18:11:28] "The revision #74 of the page named "Images" does not exist." [18:11:33] "The revision #75 of the page named "Main Page" does not exist." [18:17:31] Can't seem to make edits either, since WikiPage requires fetching the latest revision while saving a new one action=submit MWException from line 1697 of /vagrant/mediawiki/includes/page/WikiPage.php: Could not find text for current revision 75. [18:17:48] Creating a new page does work [20:07:12] bd808: I was just looking at https://www.mediawiki.org/wiki/Community_Tech and I noticed you didn't manage to lose "Manager" from your job title ;) [20:08:31] yikes! [20:09:42] I'm back to "Senior Software Engineer" on foundationwiki [21:11:53] TimStarling: Wondering if maybe you have ideas on how to address https://phabricator.wikimedia.org/T131414? Can we feasibly make these encodings work consistently? Or should we let go of canonical redirects? [21:45:36] anomie: any concerns about enabling AuthManager in beta wikitech? [21:45:53] which is apparently not beta in the sense that it's not controller by the -labs.php files [22:22:25] tgr: good luck! It's cool to see this work roll out. [22:23:12] thx [22:56:33] Krinkle: looking [22:59:04] did you reproduce it? [22:59:40] TimStarling: Not on my own server, but I can reproduce it on theirs. [23:00:04] (using Chrome) [23:00:37] https://phabricator.wikimedia.org/T131414#2225488 [23:01:22] http://test.bismilah.de/wiki/Spezial:Letzte_%C3%84nderungen redirects to itself [23:01:27] I vaguely remember having a discussion about this [23:02:07] So presumably it's a layer on the server that decodes it? [23:02:24] I was concerned that getFullRequestURL() might not always be right [23:02:41] and the response from the developer I was talking to was that it should always be right, and if it's wrong, we should fix that [23:03:32] Yeah, in prod, vagrant and on plain apache/php on my mac it all works fine. [23:04:56] For search engines, the canonical url is fine (no redirect needed). This is primarily about caches (e.g. Varnish). The alternative would be to change our purge methods to predict (or worse: track) all possible ways to encode the same url. [23:06:45] Another alternative would be to make this responsibility of middle-ware. Varnish in case of prod (which we do mostly already). MW in case of using file cache (also does that, it saves and reads from disk based on the normalised title). [23:07:18] But I'm on-board with the intent of moving more MW-specific things out of Varnish. [23:08:04] The current implementation makes it the responsibility of the site admin to configure their server properly to not decode things or otherwise interfere with this (assuming that this is feasible and realistic in all cases we support?) [23:10:50] we can easily make that redirect configurable, and test support in the installer [23:13:27] [some related bugs: https://phabricator.wikimedia.org/T127734 https://phabricator.wikimedia.org/T131414 (servers) https://phabricator.wikimedia.org/T106793 (browser) https://phabricator.wikimedia.org/T112425 (search engine)] [23:15:01] https://phabricator.wikimedia.org/T122786 (google translate) [23:15:04] Yikes, that's a lot [23:15:23] Some reproducible on our config as well. Which means we're not decoding as much in Varnish as we perhaps could. [23:15:32] Or maybe it's decoding the wrong way. [23:15:39] That could actually be the cause of some of these bugs [23:16:23] the server-config is potentially solveable, though I wouldn't be surprised if some servers are just broken that way. [23:16:55] Krinkle: last time we tried to fix encoding/decoding of apostrophes for the tools that have problems with them, it caused issues with firefox. ;) [23:16:56] But the client issues (Opera 12, Google bot apparently) is a separate thing. This is the case where the browser actively changes the url before fetching from the network. [23:17:12] Yeah, there is no one encoding that all browsers take as-is [23:17:27] Firefox wants apostrophe encoded, Opera 12 wants it decoded. [23:17:38] and they'll change it locally to the way they want it. [23:18:28] MatmaRex: Or was there a differnet issue with Firefox? I forget. [23:19:34] Krinkle: it was something like that. i don't remember either, the story is linked somewhere from those bugs [23:26:48] I've merged the client-related ones [23:30:20] Per https://github.com/wikimedia/operations-puppet/blob/3218df65dcc4c9d42ce6deef0e130db817613f58/templates/varnish/normalize_path.inc.vcl.erb#L15-L50 it seems we don't decode single quotes [23:30:28] So we're not causing it ourselves in prod.