User Details
- User Since
- Oct 10 2014, 8:08 AM (492 w, 3 d)
- Availability
- Available
- IRC Nick
- dues, duesen
- LDAP User
- Daniel Kinzler
- MediaWiki User
- DKinzler (WMF) [ Global Accounts ]
Sat, Mar 16
I can't fiogure out what triggered the change in behavior. I made an experimental patch that may address the issue. However, I am not sure it is semantically correct in al lcases.
The relevant code was refactored by @Ladsgroup in June 2023, but
Thu, Mar 14
We decided to go ahead and remove the endpoints. We can always bring them back from Git histroy.
Wed, Mar 13
On T307816: Installing MediaWiki: Error: Class "FormatJson" not found, Tim says: "Maybe something in this file triggers an opcache bug." I don't really have a better idea...
I think it would be good to have that for rest.php as well.
It would be good if we could distinguish between "critical" jobs and "not-su-critical" jobs in the code.
Reopened pending merging of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1008538
Tue, Mar 12
Mon, Mar 11
Fri, Mar 8
Thu, Mar 7
Thank you all for investigating! And sorry for causing a mess...
Body is null in both, the only difference I see that the underlying library gzips the lowercase version but doesn't gzip the uppercase version.
@jnuche Can you try this one? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1009542
Logging code is on all servers now, but I'm not seeing anything in the HtmlOutputRendererHelper channel so far.
Logging code is on all servers now, but I'm not seeing anything in the HtmlOutputRendererHelper channel so far.
Wed, Mar 6
I'm still confused about the actual error though. The error message is triggered in a conditional block starting with if ( in_array( $requestMethod, RequestInterface::NO_BODY_METHODS ) ). NO_BODY_METHODS is defined as public const NO_BODY_METHODS = [ 'GET', 'HEAD' ]. So if the client sends "get", that shouldn't match...
I didn't realize that lower case method names are actually a violation of the HTTP spec: https://stackoverflow.com/questions/10766221/is-serverrequest-method-guaranteed-to-be-uppercase
Oh, that shouldn't be needed. The framework should normalized that. I'll make a fix.
Tue, Mar 5
I can't replicate on my system. Are you running this in an odd environment?
Potential blocker: T359149: Wikibase apitests broken in CI: Unsupported Content-Type: application/json-patch+json. This issue may affect other extensions in production. There is a fix for review on the ticket.
Working on a fix
Mon, Mar 4
I have the same problem on the command line:
I can't reproduce this locally anymore. But it still happens in production.
I can't reproduce this locally.
Fri, Mar 1
Thu, Feb 29
Tue, Feb 27
Made a couple of improvements to loggign and error reporting. That will hopefully give us more to work with. Once the patches are deployed, we should see these errors pop up in the HtmlOutputRendererHelper error.
Thinking about text browsers, I just realized that using MathML natively should be a huge improvement for screen readers. Do we know how well they support MathML? I just skimmed https://w3c.github.io/mathml-docs/gap-analysis/
I filed new tickets for parts of this, see T358557: Rest router should provide parsed body data to handler. and T358558: Rest ParamValidator should support validation of fields in the request body.