Description
We will implement a short term solution addressing routing of requests through the Varnish layer to MW REST API described in T235779. However, moving forward, we need to determine a full canonical description for the MW REST API URI.
Mediawiki implements it’s own wfUrlEncode method, that’s different from the standards cause we want to have prettier URLs in the browser [[ https://github.com/wikimedia/mediawiki/blob/cd7972620fec25a6f2cb46846b5fc7ad6acf9fd8/includes/GlobalFunctions.php#L282-L309 | [1] ]], thus we skip encoding certain characters.
In RESTBase REST API, we mostly use Javascript encodeURIComponent[[ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent | [2] ]] semantics, since it’s implemented in JS. However, it’s not perfect either.
If we wanted to follow standards in core REST API verbatim, we would need to adhere to RFC3986 [[ https://tools.ietf.org/html/rfc3986 | [3] ]], which is different from JS implementation.
All has their own pros and cons, quite briefly:
- We can adopt wfUrlEncode semantics EXCEPT for the forward slash. This will make us more consistent with other parts of MediaWiki, but this will make it hard for the clients to compose the correct canonical URI.
- We can adopt encodeURIComponent semantics as canonical. If we expect most of the clients to be written in JavaScript, that’s the easiest for the clients to compose the canonical URI.
- We can state we follow RFC3986 - more standard but harder for clients.
This task should form a starting off point to discuss the options available and to converge to a solution outputting a canonical form that can be implemented at the Varnish and later ATS layer.
Requirements
- Internal team should discuss and comment on this ticket
- Seek input from stakeholder teams
- Document the results of discussion, determine concrete next steps and identify timeline