Per https://www.mediawiki.org/wiki/Developers/Maintainers I'm adding Language and Product Localization to this task.

Language team: please take a look at this as soon as you can. It's not clear when this started, sadly.

Certainly not caused by changes in the Interwiki extension, because there aren't any.

The Interwiki extension is confusingly named - it's just a form for editing the interwiki table. It has nothing to do with URLs of this kind.

There is no km.wikisource.org or mk.wikisource.org, so that redirects to wikisource.org.

Log:

Request URL:https://km.wikipedia.org/w/index.php?title=s:mk:MediaWiki:Gadget-removeAccessKeys.js
location:https://km.wikisource.org/wiki/mk:MediaWiki:Gadget-removeAccessKeys.js

Request URL:https://km.wikisource.org/wiki/mk:MediaWiki:Gadget-removeAccessKeys.js
location:https:https://mk.wikisource.org/wiki/MediaWiki:Gadget-removeAccessKeys.js

Request URL:https://km.wikisource.org/wiki/https://mk.wikisource.org/wiki/MediaWiki:Gadget-removeAccessKeys.js
location:https://wikisource.org/wiki/https://mk.wikisource.org/wiki/MediaWiki:Gadget-removeAccessKeys.js

Request URL:https://wikisource.org/wiki/https://mk.wikisource.org/wiki/MediaWiki:Gadget-removeAccessKeys.js
location:https://wikisource.org/wiki/Https://mk.wikisource.org/wiki/MediaWiki:Gadget-removeAccessKeys.js

Request URL:https://wikisource.org/wiki/Https://mk.wikisource.org/wiki/MediaWiki:Gadget-removeAccessKeys.js

Simple test case: km.wikisource.org/wiki/en:foo

Request URL:https://km.wikisource.org/wiki/en:foo
location:https:https://en.wikisource.org/wiki/foo

....

So there is extra https: which causes browsers to think it is a relative url. There is x-powered-by:HHVM/3.12.1 which would indicate it is MediaWiki issue and not Varnish etc.

Given this only happens for non-existing wikisources, it might not be an unbreak now.

For example 69f52123bb71d089e81c8e5427806450c201a35c could be a possible cause, though that seems impossible given the request is https, not http. Since the redirect code is 302 we can ignore those redirect() calls in core which set some other code.

Some candidates:

includes/MediaWiki.php
235:                            $output->redirect( $url, 301 );
291:                                    $output->redirect( $article );
347:                    $output->redirect( $targetUrl, '301' );
722:                            $output->redirect( $redirUrl );

Then again, given it is a non-existent wiki, the redirect might actually happen outside MediaWiki. But I don't find anything relevant in https://github.com/search?utf8=%E2%9C%93&q=org%3Awikimedia+302+wikisource&type=Code&ref=searchresults

The broken step is apparently km.wikisource.org -> mk.wikisource.org. That would happen somewhere in the multiversion code, not in MediaWiki.php, wouldn't it?

Probably somewhere here then: https://github.com/wikimedia/operations-mediawiki-config/blob/c3a43aa66d1f34499d34136830139f82298a206d/wmf-config/missing.php#L94-L103 – that file has not seen many changes either.

I have no idea under which tag this would fall under, but I'm stopping here and removing Language-Engineering.

In T143968#2590069, @Nikerabbit wrote:

Probably somewhere here then: https://github.com/wikimedia/operations-mediawiki-config/blob/c3a43aa66d1f34499d34136830139f82298a206d/wmf-config/missing.php#L94-L103 – that file has not seen many changes either.

That seems about right. Must have been broken by 4d933e8 changing $iw_url to not be protocol-relative.

So now we have an UBN! task with no associated projects? Only Regression?

Without an explicit handoff, @Nikerabbit, Language Engineering is still responsible for this (I tasked you with it first to triage, you determined it's not you, but, pray tell, who knows more about this issue? We can NOT just let UBN! issues fall on the floor like this).

In T143968#2590105, @Tgr wrote:

In T143968#2590069, @Nikerabbit wrote:

Probably somewhere here then: https://github.com/wikimedia/operations-mediawiki-config/blob/c3a43aa66d1f34499d34136830139f82298a206d/wmf-config/missing.php#L94-L103 – that file has not seen many changes either.

That seems about right. Must have been broken by 4d933e8 changing $iw_url to not be protocol-relative.

Let's at least add the person who we think is responsible for the breakage.

@Legoktm current theory here is the switch to HTTPS only broke this. Please take a look if you can.

I agree with Niklas that this shouldn't be an UBN; it only breaks interwiki links to non-existing wikis, which probably wouldn't have much use anyway. The worst thing I can think of is that strangely ordered interwiki chains that take you over a non-existing wiki to somewhere meaningful will break (e.g. mk:w:Foo from the English Wikisource).

In any case, an easy fix, I just did not want to mess with it at one in the morning.

Already fixed actually.

(Fixed the component.)

In T143968#2592377, @Tgr wrote:

I agree with Niklas that this shouldn't be an UBN; it only breaks interwiki links to non-existing wikis, which probably wouldn't have much use anyway.

I missed that (that it shouldn't be UBN!), sorry for nagging aggressively then!

In any case, an easy fix, I just did not want to mess with it at one in the morning.

Intelligent :) Thanks for the fix.

In T143968#2592482, @greg wrote:

Intelligent :) Thanks for the fix.

It was fixed by TTO in the EU SWAT: T141208#2590919