btw, this seems to be the log entry for the 500 the user from discord experienced https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-default-1-7.0.0-1-2024.11.12?id=AL88IJMBLmySI1N_AuNw

This test failed gate-and-submit for https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1084281 (https://integration.wikimedia.org/ci/job/mediawiki-quibble-composer-mysql-php74/4154/console). That patch should have been 100% things that had already passed the gate-and-submit tests to produce each hash collected in the wmf/next branch update.

Change #1072540 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] EXP: REST: distinguish between module path prefix and module ID

https://gerrit.wikimedia.org/r/1072540

Here we see both forms of module specification. The specs/v0 bit actually specifies the specs/v0 module, per the specs.v0.json module definition file. The content.v1 bit would be our new format for specifying module ids as parameters in urls.

But that approach is a bit hacky, because it makes assumptions about the module id structure, and it really only works if the module id is the last parameter. Which means that any endpoint that takes two module ids is problematic.

tl;dr: sure, why not?

The RESTBASE API has been deprecated, please use https://api.wikimedia.org/wiki/Core_REST_API/Reference/Pages/Get_HTML

+1 user through the iOS support email
cc @ARamadan-WMF
T371409: Implement Pending Changes System for Arabic Wikipedia in the App

The Pending Changes system is not functional within the app, which makes it difficult for contributors to effectively participate in the Arabic Wikipedia. The Pending Changes system is crucial for maintaining the quality of content and ensuring that edits are reviewed before being published.

Update: API response is {"code":"unexpected-error","message":"Unexpected error"} for the second call.

Everyone seems to be happy with content.v1, so let's do it!

At least it should fail with an "edit conflict" error or something, but since the statements are different, I would expect both calls to succeed

I think this wouldn't be very useful as a security measure:

• When authenticating with cookies, all cookies use the Secure flag already, so a reasonable client would not send them over HTTP.
• OAuth 1 is designed to be secure over HTTP.
• The OAuth 2 spec forbids serving HTTP requests, so if we allow them currently, we should stop doing that. There is some value in key revocation but I'm not sure if it's worth the effort - you'd need to avoid write on GET, notify the user somehow, it's easy to cause mass breakage by revoking keys which don't need to be revoked (SSL is terminated way before the request reaches the appserver so MediaWiki can't directly check what protocol is being used), hard to do consistently (how would non-MediaWiki APIs revoke?).

Tagging MW-Interfaces-Team as they are API owners.

+1 for content

I'm also +1 to content. Thanks for doing this!

Good question. Not sure I have a great answer, but I do have a few thoughts.

For reference, here are some adjacent endpoints that are related to pages but do not correspond to the old parsoid endpoints:

• /v1/page/{title}/history
• /v1/page/{title}/history/counts/{type}
• /v1/revision/{from}/compare/{to}
• /v1/page/{title}/links/language
• /v1/page/{title}/links/media
• /v1/file/{title}