Adding a permissive CORS policy to w.wiki(fine but more dependent of web-server configuration).

Both could be done, independantly, but that should be filed as a different task.

Change 1005186 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/UrlShortener@master] Add API module to resolve short urls to longer ones

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

Not actually a duplicate of T228781: Create API to retrieve list of short urls; the patch is more to get a list of all short urls, not resolve specific ones

A query like "action=query&list=shorturl&suurl=https://w.wiki/1" would however only return the URL behind the one given? From my point of view that would resolve the use case.

Is the input here meant to be the full short URL or just the code? If the former, should it support both the normal and alt forms?

I would somehow expect it to be the full URL, as it fits with the mental model of a URL shortener but in practice it probably do little to no difference.

Change 1009853 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/UrlShortener@master] SpecialUrlRedirector: Enable CORS via Access-Control-Allow-Origin header

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

Is this a discoverable API? Is it faster and/or more cacheable for end-users? Is it easier to maintain?

It seems to me the answer to all three is no. Perhaps addressing the CORS issue would suffice?

Is this a discoverable API? Is it faster and/or more cacheable for end-users? Is it easier to maintain?

It could be more flexible (e.g. accept multiple short URLs in a batch, or accept just the short code on its own, or return a QR code, etc.), but for the use case of single lookups it does seem that the existing API is fine (inspecting the Location header of the response to a request to the normal short URL). It seems that adding Access-Control-Allow-Origin: * is the simplest change to help here — but adding an Action API would be fine too I'd say (it'd be more discoverable, as it'd be listed in ApiSandbox etc.).

Change #1009853 merged by jenkins-bot:

[mediawiki/extensions/UrlShortener@master] SpecialUrlRedirector: Enable CORS via Access-Control-Allow-Origin header

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

Adding a permissive CORS policy to w.wiki

Note: this will not always receive the exact target of short URL. e.g. if the target is a redirect it will receive the target of the redirect instead of the redirect itself.

Note: this will not always receive the exact target of short URL. e.g. if the target is a redirect it will receive the target of the redirect instead of the redirect itself.

I'm not sure that's correct. UrlShortener just stores the URL as given doesn't it? It doesn't check to see if the URL is a redirect and then fetch the target.

For example, https://en.wikipedia.org/wiki/Stevedore redirects to https://en.wikipedia.org/wiki/Dockworker but the shortened URL of https://w.wiki/9YdJ redirects to the former (i.e. it's a double redirect).

For example https://w.wiki/9Yfs is the shortened URL for https://en.wikipedia.org/wiki/WP:AN. When this code is run (after CORS is enabled):

fetch('https://w.wiki/9Yfs', {
    method: 'HEAD',
    redirect: 'follow'
}).then(response => {
    return response.url;
});

• https://w.wiki/9Yfs 301 redirect to http://en.wikipedia.org/wiki/WP:AN
• http://en.wikipedia.org/wiki/WP:AN 301 redirect to https://en.wikipedia.org/wiki/Wikipedia:AN
• https://en.wikipedia.org/wiki/Wikipedia:AN is no longer a 301. It displays content of Wikipedia:Administrators' noticeboard with a redirect banner, and a script to replace the URL in browser bar

So the returned url is https://en.wikipedia.org/wiki/Wikipedia:AN. However this is not the exact target of short URL, which is http://en.wikipedia.org/wiki/WP:AN

I'm a bit confused as to why https://en.wikipedia.org/wiki/Wikipedia:AN is not a redirect. How does it get redirected?

But anyway, I'm not sure UrlShortener can do much here. I do think adding an API is a reasonable idea, but it'd still only return http://en.wikipedia.org/wiki/WP:AN when https://w.wiki/9Yfs (or 9Yfs or _tVNA) is requested. It seems that this example short URL should've just been https://w.wiki/bFt and avoided the double redirect.

I wouldn't expect the API to interact with actual redirects at all and if it's decided that the CORS-webserver option is better I wouldn't expect that either to effect anything other than the initial redirect, thus an user could still get a CORS error down the chain as intended by the downstream target(s).