RESTBase patch for swagger here: https://github.com/wikimedia/restbase/pull/1317

@Nikerabbit MCS decom is coming soon and since we have identified a dependency on ContentTranslation, I wonder if there are any action items we should be taking here. cc/ @SLopes-WMF

We are working on migrating away: T337719: CX: Replace calls to the deprecated mobile content REST API.

Hi @MSantos, any idea why this fails? https://en.wikivoyage.org/api/rest_v1/page/mobile-html/Toronto

I wasn't aware PCS endpoints where marked for deprecation also. Thanks.

I represent a educational app that relies on the mobile-html endpoints, that were not supposed to be decommissioned.
https://en.wikipedia.org/api/rest_v1/page/mobile-html/July_6 should return a valid response, only the /page/mobile-sections pattern was announced to go away mid July.

Please revert the change until a solution to migrate users is possible. Currently, all users are affected by this change and they cannot use the application.

@alexandru.c.ene per T341248 and @akosiaris, I believe this should be fixed now.

This is a task to give any long tail use case reusers of the service to adjust.

My website made heavy use of the /mobile-section/ endpoint and we were unaware that there was any deprecation until it started throwing 403 errors today and our WP integration broke completely. So this entire issue comes as an unpleasant surprise to us.

Aside from the 403 error being misleading ("Error: Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes."), how were we supposed to know that /mobile-section/ API was going away?

And what is the replacement for it, given that /mobile-html/ is much harder to work with compared to the clean structured JSON of /mobile-section/ (which is why we moved from html to section in the first place)?

@Gwern Please see the notices posted to wikitech-l,
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/4MVQQTONJT7FJAXNVOFV3WWVVMCHRINE/

@Gwern A good candidate for section information is a combination of these Action API requests:

• Get section information for page <PAGE>

https://en.wikipedia.org/w/api.php?action=parse&page=<PAGE>&prop=sections

• Render the output only for the specific section identifier <ID>

https://en.wikipedia.org/w/api.php?action=parse&page=<PAGE>&section=<ID>

@Gwern if you want to get in touch and provide more context about your website and how you yse MCS you can reach me through msantos@wikimedia.org

Can you see requests from Wikidocumentaries to MCS? They should have Api-User-Agent starting with the string "wikidocumentaries" (at the beginning of the contact email address).

Can I get the same HTML from PCS or action=parse (perhaps with mobileformat=true?) as from MCS, and if not, is there a list of the differences?

https://en.wikipedia.org/w/api.php?action=parse&page=<PAGE>&section=<ID>

What's the reasoning behind not offering an endpoint that returns all the sections as JSON? When I display all the sections, it would cause extra work and requests to fetch them one by one. If there's a simple way (in JavaScript) to split a response into sections, their content and their metadata, that would also do fine, I think.

(Sorry I'm clueless even after trying to read the documentation - I haven't had to deal with these details before.)

@TuukkaH thanks for reaching out, the announcement and reasoning before MCS decomission can be found in this comment as stated by @Arlolra T328036#8998877

The allowed list will stop working soon (tentatively end of September) and the service fully removed from our servers. This allowed list is a temporary compromise for projects that already started migrating away from MCS and reached out before the deadline.

I appreciate your patience, and let us know if you have any more questions.

Untagging ContentTranslation which was handled in T337719: CX: Replace calls to the deprecated mobile content REST API.

In T361483, I 've been poking into selectively killing parts of changeprop that are no longer used. I am still in the /hopefully easy pickings/ phase, attacking things we KNOW aren't used any more. I am now targetting removing functionality from changeprop that refreshes all the mobile-sections parts of RESTBase, meaning RESTBase will no longer have up to date content for these endpoints.

MCS is still used by kiwix. I think wikiwand has stopped using the endpoint.

After some back and forth with kiwix folks it looks like end of July is reasonable to keep the MCS endpoints available for mw-offliner.
They have already migrated to other endpoints and they just finish some details.
Should we schedule to finally completely block the MCS traffic to complete the deprecation?

In T328036#9930685, @Jgiannelos wrote:

After some back and forth with kiwix folks it looks like end of July is reasonable to keep the MCS endpoints available for mw-offliner.
They have already migrated to other endpoints and they just finish some details.

\o/

Should we schedule to finally completely block the MCS traffic to complete the deprecation?

Sure. I put 2 items in my cal, one to update https://wikitech.wikimedia.org/wiki/Deployments in mid july pointing out the removal and 1 to do the actual removal of the exception on July 30. Let me know if that's not sufficient.

Change #1054512 had a related patch set uploaded (by Jgiannelos; author: Jgiannelos):

[operations/deployment-charts@master] changeprop: Disable pregeneration for mobile-sections

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

Change #1054512 merged by jenkins-bot:

[operations/deployment-charts@master] changeprop: Disable pregeneration for mobile-sections

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

Exception for wikiwand and kiwix removed. We now have a deny everything rule. Chagngeprop is also not invalidating cache for mobile-sections, what's left is to remove from RESTBase I think.

In T328036#9019598, @TuukkaH wrote:

Can you see requests from Wikidocumentaries to MCS? They should have Api-User-Agent starting with the string "wikidocumentaries" (at the beginning of the contact email address).

Can I get the same HTML from PCS or action=parse (perhaps with mobileformat=true?) as from MCS, and if not, is there a list of the differences?

https://en.wikipedia.org/w/api.php?action=parse&page=<PAGE>&section=<ID>

What's the reasoning behind not offering an endpoint that returns all the sections as JSON? When I display all the sections, it would cause extra work and requests to fetch them one by one. If there's a simple way (in JavaScript) to split a response into sections, their content and their metadata, that would also do fine, I think.

(Sorry I'm clueless even after trying to read the documentation - I haven't had to deal with these details before.)

Wikidocumentaries started to fail now with an error pointing to this ticket. Still no help available?

MCS has been decommissioned for almost a year now. I don't think that any errors appearing lately can be related.

@TuukkaH can you provide more context on how Wikidocumentaries relied on MCS in the past? You should be able to get the same HTML from Parsoid or PCS.

What Yiannis said is true, MCS has been blocked for almost a year please let us know if you have any doubts in regards to the usage of the APIs you can use to replace MCS.

In T328036#10720435, @Jgiannelos wrote:

MCS has been decommissioned for almost a year now. I don't think that any errors appearing lately can be related.

The requests worked until now, and now none of them work. The timestamp of the first failure is Tue, 08 Apr 2025 07:39:37 GMT. Perhaps until now, the requests were being served from a cache?

Here's an example of a URL that started failing now -- at least it looks like an MCS URL: https://en.wikipedia.org/api/rest_v1/page/mobile-sections/Vietnam

Here's the error response (when the request is made from within WMCS):

{
  type: 'https://mediawiki.org/wiki/HyperSwitch/errors/not_found#route',
  title: 'Not found.',
  method: 'get',
  uri: '/en.wikipedia.org/v1/page/mobile-sections/Vietnam'
}

Here's the headers (converted to JSON):

{
  'access-control-allow-origin': '*',
  'access-control-allow-methods': 'GET,HEAD',
  'access-control-allow-headers': 'accept, content-type, content-length, cache-control, accept-language, api-user-agent, if-mat
ch, if-modified-since, if-none-match, dnt, accept-encoding',
  'access-control-expose-headers': 'etag',
  'x-content-type-options': 'nosniff',
  'x-frame-options': 'SAMEORIGIN',
  'referrer-policy': 'origin-when-cross-origin',
  'x-xss-protection': '1; mode=block',
  'content-security-policy': "default-src 'none'; frame-ancestors 'none'",
  'x-content-security-policy': "default-src 'none'; frame-ancestors 'none'",
  'x-webkit-csp': "default-src 'none'; frame-ancestors 'none'",
  'cache-control': 'private, max-age=0, s-maxage=0, must-revalidate',
  server: 'restbase1030',
  'content-type': 'application/problem+json',
  'content-length': '166',
  date: 'Tue, 08 Apr 2025 07:55:09 GMT',
  age: '0',
  'x-cache': 'cp1108 miss, cp1108 pass',
  'x-cache-status': 'pass',
  'server-timing': 'cache;desc="pass", host;desc="cp1108"',
  'strict-transport-security': 'max-age=106384710; includeSubDomains; preload',
  'report-to': '{ "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?
stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }',
  nel: '{ "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}',
  'set-cookie': [
    'WMF-Last-Access=08-Apr-2025;Path=/;HttpOnly;secure;Expires=Sat, 10 May 2025 00:00:00 GMT',
    'WMF-Last-Access-Global=08-Apr-2025;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Sat, 10 May 2025 00:00:00 GMT',
    'GeoIP=:::::v4; Path=/; secure; Domain=.wikipedia.org',
    'NetworkProbeLimit=0.001;Path=/;Secure;SameSite=Lax;Max-Age=3600'
  ],
  'x-client-ip': '172.16.5.11',
  connection: 'close'
}

In T328036#10720727, @MSantos wrote:

@TuukkaH can you provide more context on how Wikidocumentaries relied on MCS in the past? You should be able to get the same HTML from Parsoid or PCS.

I don't know the history of this as I've inherited the code, but somehow the way it ended up working was that the JSON response from the /page/mobile-sections endpoint was used to be able to process and join the HTML of the different types of sections separately (lead, disambiguation page sections, content sections, references sections).

What Yiannis said is true, MCS has been blocked for almost a year please let us know if you have any doubts in regards to the usage of the APIs you can use to replace MCS.

Like I wrote earlier, I don't know the detailed differences between MCS and PCS responses, and I couldn't understand the documentation regarding this. I think this question is still relevant, because Wikidocumentaries depended on the details of the HTML in the MCS response, so I'd like to get something as similar as possible and I'd need to know the differences so I can try to make the necessary changes in the processing code:

[1.] Can I get the same HTML from PCS or action=parse (perhaps with mobileformat=true?) as from MCS, and if not, is there a list of the differences?

In the following question, my points were that Wikidocumentaries was (evident now) built to use the JSON response from MCS and such a JSON response would still seem like a handy endpoint to have in the API in general, but if there isn't going to be such an endpoint anymore, do you suggest to multiply the number of requests by the number of article sections, or can you suggest a way to split a full-article HTML into the sections and corresponding section metadata?

https://en.wikipedia.org/w/api.php?action=parse&page=<PAGE>&section=<ID>

[2.] What's the reasoning behind not offering an endpoint that returns all the sections as JSON? When I display all the sections, it would cause extra work and requests to fetch them one by one. If there's a simple way (in JavaScript) to split a response into sections, their content and their metadata, that would also do fine, I think.

Here's the function that handled the MCS JSON response: (The /page/summary endpoint seems to still be responding, so perhaps that part is safe.) https://github.com/Wikidocumentaries/wikidocumentaries-api/blob/master/wikipedia.js#L41

Here's the function that was used to process the MCS HTML parts: https://github.com/Wikidocumentaries/wikidocumentaries-api/blob/master/wikipedia.js#L140

Also some client-side code and CSS will depend on the structure of the HTML content, but it's difficult for me to know or find the relevant parts: https://github.com/Wikidocumentaries/wikidocumentaries-ui

Per T264671, mobile-sections endpoints should be superseded by mobile-html. This might be a topic for a separate task as this one is resolved.

The requests worked until now, and now none of them work. The timestamp of the first failure is Tue, 08 Apr 2025 07:39:37 GMT. Perhaps until now, the requests were being served from a cache?

No, but the example you pasted is from WMCS, which is treated specially and thus bypassed the rule at the edge layer, that we had set for MCS decommissioning. This was on oversight on my part, sorry about that. You should have seen the same errors everyone else saw 1.5 years ago per T340036#8994407.