Several of the new Core REST API endpoints accept titles. We should see if they are similarly affected.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/542457 proposes a REST API param validator related to titles and may (1) also be affected by this and (2) might be a good place, or at least inspiration, for a reusable solution.

I haven't looked too deep into it, but I think the problem is that the title gets decoded before looking up the appropriate handler, which then presents a challenge in this case. Parsoid declares the following (relevant) route handlers:

{
	"path": "/{domain}/v3/page/{format}/{title}",
	"class": "MWParsoid\\Rest\\Handler\\PageHandler",
	"factory": "MWParsoid\\Rest\\Handler\\PageHandler::factory",
	"method": "GET"
}, {
	"path": "/{domain}/v3/page/{format}/{title}/{revision}",
	"class": "MWParsoid\\Rest\\Handler\\PageHandler",
	"factory": "MWParsoid\\Rest\\Handler\\PageHandler::factory",
	"method": "GET"
}

So the same code path handles both cases, and thus works both with and without a revision parameter present. What I think is happening is that when the path en.wikipedia.beta.wmflabs.org/v3/page/pagebundle/User%3APchelolo%2FOnDemand_Test/275844 is encountered by MW, it is first decoded into /en.wikipedia.beta.wmflabs.org/v3/page/pagebundle/User:Pchelolo/OnDemand_Test/275844, but that cannot be matched to any of the above routes, as

format: pagebundle
title: User:Pchelolo
revision: OnDemand_Test
???: 275844

Conversely, because of this matching algorithm, the request for en.wikipedia.beta.wmflabs.org/v3/page/html/User%3APchelolo%2FOnDemand_Test (i.e. without the revision) succeeds because:

format: pagebundle
title: User:Pchelolo
revision: OnDemand_Test

However, it should be noted here that the request succeeds only because Parsoid can handle requests both with and without the revid, and not because the handler look-up algorithm matched the route correctly.

Ok, I was partially correct. The problem is indeed that MW tries to match the decoded path, which fails because of the slash. However, it turns out that that's not on MW, but rather on Apache: it fully decodes the path before passing it on to PHP.

In T235375#5572575, @mobrovac wrote:

Ok, I was partially correct. The problem is indeed that MW tries to match the decoded path, which fails because of the slash. However, it turns out that that's not on MW, but rather on Apache: it fully decodes the path before passing it on to PHP.

I just checked and we have a number of test titles in round trip testing that have a "/" in them and they all successfully go through rt testing. So, yes, this must be something not in the M/W-Parsoid combo. Is there a way to prevent Apache from decoding? Or, not sure if it is feasible for the M/W code to not fail on "/" because the revid ought to be a number .. but presumably that kind of type information isn't available in the config .. so, I think the qn. is if Apache can be configured not to decode titles.