https://gerrit.wikimedia.org/r/570387 a.k.a. e4d02b5e9a896546d63cd800ce6b0d77ae8ea190 seems to have fixed this, as checked via a local override with that patch reverted. Then the task may belong in WikiEditor instead.

Recompiling the Sass should not be too hard. Hosting it as part of the tool itself would cause the benefits of the cdnjs to get missed, though, as far as the theme is concerned. Or I might do without the theme entirely. Anyway I'm not placing this up for grabs as it does not make sense for anyone else to work on the Wikidata Slicer in its current state.

Not discouraging anyone from picking the patch up or starting a new one

Not discouraging anyone from picking the patch up or starting a new one

Not going to work on this in the near future

Not going to work on this in the near future

Not going to work on this in the near future

Not discouraging anyone from picking the patch up or starting a new one

Babel AutoCreate still blocked on many wikis. Task likely in need of movement-wide clarification/reevaluation

Fixed by https://gerrit.wikimedia.org/r/521464 a.k.a. 9902e70e378d06925025b9b0bde8b86b694769c5? @Ladsgroup @Nikerabbit

Glad that the old files are still around and the change has been documented so that browser version data can be gathered again. Hope moving the logs to my local machine once every few years will help freeing up some disk space while complying with the privacy Terms

I seem to recall How we made editing Wikipedia twice as fast having a big impact on the public perception of HHVM. Is a new post in the works? Someone from the broader community is likely interested in the what/why/how of the switch back to Zend.

GitHub PR by GlazerMann https://github.com/wikimedia/mediawiki-oauthclient-php/pull/7 predates task but the repo seems to be using Gerrit.

I still get dropped connections (not 414) with much longer URLs (total header size from 9442 bytes onward). Is that expected?

@Vgutierrez my bad, I meant retrying with a shorter URL.

Thank you all for investigating. What would you recommend as the best practice w.r.t. URL length in client code? E.g. POST requests, hard-coded limits, retrying on 414-coded responses...

Firefox 63, Chromium 70, curl 7.58 all work fine with HTTP/1.1 but fail with HTTP/2 on Wikimedia servers. Other HTTP/2 servers seem not to be affected.

In T209590#4753835, @Anomie wrote:

When I try making a variant of that request (spaces replaced with %20) using curl, I get back the proper API response.

Thank you.