Tue, Feb 16
Jul 26 2020
Jul 8 2020
Just to mention that apache httpd does a camel casing by default when proxying back from an http2-talking backend to an http1.x-talking frontend:
Jun 27 2020
Thanks for notification. The problem is what I'm running is not a single task, but ten individual tasks instead. To minimize common mode failures, they were designed to run as individual processes, each being able to do its own task by itself, from login to querying to editing, without relying on sessions/tokens from other processes. On finishing, they logout and exit. A batch file is created to run all of them every 10 mins.
Sep 16 2019
Aug 19 2019
Aug 10 2019
Codes or scripts should only edit via api.php rather that index.php, and the former does provide the choice between "bot" and "nonbot". Thus I would suggest close this as invalid.
Aug 8 2019
BTW, all pages listed above contain T228876-like issues, indicating they are probably caused by the same bug.
Based on these observation, I would suspect that this is a message/message-cache only issue. I've noticed that recently serveral changes were made to Message.php and MessageCache.php (T228555). Could one of them have the potential to cause these problems?
Collected a few problematic responses. It seems that this issue has nothing todo with the following:
- Cookies. Given that my code for fetching these pages send no cookies, except the one that enforces php7, to the server, cookie is not the necessary condition to get such errors. This also implies that switching the default language (which cannot be done unless by using cookies) is not necessary for reproducing errors.
- Client-side 304 issues, given that my code doesn't implement client-side caching at all.
- HHVM/PHP7 preference. All above requests were served by php7, thus the claim "PHP7.x instances are correctly configured" is not true.
- Varnish cache, as all above requests encountered a cache miss.
Jun 27 2019
It seems that only requests coming through Varnish frontends at eqiad are affected.
Jun 16 2019
Also, ATS doesn't change the via header as Varnish does.
May 28 2019
The cause of this problem has been identified. Given that
May 25 2019
Mar 22 2018
> Anyway, anyone with a real use case is very much invited to re-open this task and explain their case.
Feb 22 2018
Nov 21 2017
This seems to be a side effect of this commit.
Sep 18 2017
Sep 8 2017
The problem seems to be a side effect of this.
Aug 26 2017
Jul 27 2017
Jun 20 2017
Sep 14 2016
The patch works for me.
Aug 18 2016
Well, it has something to do with zhwiki. zhwiki uses the language converter, which converts "Category:XXX" to simplified Chinese "分类:XXX" or traditional Chinese "分類:XXX" for logged-out users, based on the location of their IP address. In your patch, this->getPrettyPageNameHtml() is called to get the subheading, and you might expect that expression
Aug 8 2016
Do you mean in preview mode?
Aug 7 2016
It didn't change anything on the edit page. However, it did change the subheading on the submit page, which had been "Pages in category 'Test'" before your patch was applied.
This change completely breaks our category subheading displaying mechanism. https://en.wikipedia.org/w/index.php?title=Category:Test&action=submit gives "Pages in category 'Editing Category:Test'", and https://zh.wikipedia.org/zh-cn/Category:2016%E5%B9%B4%E8%8B%B1%E5%9C%8B%E9%AB%94%E8%82%B2 gives "分类'分类:2016年英国体育'中的页面".
Feb 27 2016
I was getting the same error on Chinese wikipedia when I tried to change my password.
Feb 12 2016
https://github.com/fastily/jwiki/blob/master/src/jwiki/core/Auth.java#L37 Jwiki doesn't handle the token properly.
Jan 29 2016
Nov 20 2015
Nov 17 2015
Also, User:Markmingjie failed to restore his flow archive today.