(In reply to comment #0)

(I've no idea what "srcset" is).

It's this: Gerrit change 24115

(In reply to comment #1)

(In reply to comment #0)

(I've no idea what "srcset" is).

It's this: Gerrit change #24115

So is it a coincidence that, when that fails and no srcset is added, MediaWiki also fails to use the correct (protocol-relative) src?

• Bug 47653 has been marked as a duplicate of this bug. ***

At first glance, maybe the difference is if it was a thumbnailed file vs if original file.

I cannot reproduce the observations after step 3 any more.

(In reply to comment #5)

I cannot reproduce the observations after step 3 any more.

I can still reproduce that some are protocol-relative and some are not.

(In reply to comment #0)

<img alt="P economy blue.png"
src="/w/images/thumb/1/1a/P_economy_blue.png/135px-P_economy_blue.png"
width="135" height="124"
srcset="https://upload.wikimedia.org/wikipedia/commons/1/1a/P_economy_blue.
png
1.5x, https://upload.wikimedia.org/wikipedia/commons/1/1a/P_economy_blue.png
2x" />

I don't know why we're discussing what protocols are being used - why is the src of this a local resource but the srcset pointing to commons?

After purging, https://translatewiki.net/w/i.php?title=Project:About&oldid=5630868 and going to its "View source" shows twelve links to http://, and zero https:// or // links.
Using my browser's "View Source" I get thirteen links (one being in the footer).

Not sure if I understand the bug report correctly though.

I cant reproduce this on http(s)://www.omegawiki.org/DefinedMeaning:pink_%286772%29

However it might only occur if the image doesnt need scaling down - as I havent found a scenario for that..

I guess this bug can be closed, since Commons only has HTTPS now, and all links I found on the specified page on Translatewiki are called in HTTPS.

I guess this bug can be closed, since Commons only has HTTPS now

It's still bad to link/embed http though, isn't it?

Probably can't be reproduced with Commons images, either, since InstantCommons is now defined with an absolute HTTPS URL.

To clarify, this bug is that when embedding an image from a foreign repo that is smaller than the requested thumbnail size (e.g. the thumb is really big, or the image is relatively small), the API will provide the url to the original image (e.g. it won't make a thumbnail for the same size).

Since ForeignRepo only caches thumbnails, the original is thus served from the original wiki (e.g. Commons), not from the local wiki. It seems the API does not provide protocol-relative urls but absolute urls (based on the protocol the incoming request from the local wiki used). As such, when browsing a wiki that supports both HTTP and HTTPS, it will cache the url to the original image based on the request. So if the last editor/purger of an article used HTTP and you use HTTPS, you're downloading insecure content.

@Krinkle, the current task summary is "ForeignAPIRepo (InstantCommons) thumbnails have non-protocol-relative srcset URLs in certain cases", but from your comment it seems that it should be something more like "ForeignAPIRepo (InstantCommons) original-size files are served directly from source instead of local thumbnail". Can you confirm this is correct?

@brion No, that's T101015. The bug here seems that the API is wrongly using an absolute protocol where a relative protocol is expected. (e.g. it may protocol-relative for thumbs, but not for originals). Though if T101015 is fixed, that likely leads to the removal of the code causing this bug.

In T50133#1606949, @Krinkle wrote:

Since ForeignRepo only caches thumbnails, the original is thus served from the original wiki (e.g. Commons), not from the local wiki. It seems the API does not provide protocol-relative urls but absolute urls (based on the protocol the incoming request from the local wiki used). As such, when browsing a wiki that supports both HTTP and HTTPS, it will cache the url to the original image based on the request. So if the last editor/purger of an article used HTTP and you use HTTPS, you're downloading insecure content.

The URLs in the API response depending on the protocol of the API call is arguably a bug, but how does the protocol of the API call depend on the protocol of the pageview which triggered the API call? ForeignAPIRepo::httpGet() calls wfExpandUrl( $url, PROTO_HTTP ) on the URL, which comes straight from the apibase parameter of the repo configuration. So, if an absolute API URL is configured for the repo, that is honored, otherwise it uses HTTP. Again, not very security-conscious and arguably a bug, but I don't see how it would result in the behavior described here.

So either this got fixed some time in the past or the problem is at some other place (parser cache maybe?).

T49653#526397 seems to be about the same issue (and contains an unmerged patch, too).

The relevant part is ApiQueryImageInfo.php line 496 and 517-518. I'm not sure it could be improved: PROTO_CANONICAL would return HTTP URLS for a HTTPS CORS AJAX request in some cases even when the repo is HTTPS-capable, PROTO_RELATIVE would return non-absolute URLs which non-browser-based clients might be unprepared for, and PROTO_HTTPS could cause problems for clients with poorly configured HTTPS libraries (there are lots of those).

In T50133#1614931, @Tgr wrote:

The relevant part is ApiQueryImageInfo.php line 496 and 517-518. I'm not sure it could be improved: PROTO_CANONICAL would return HTTP URLS for a HTTPS CORS AJAX request in some cases even when the repo is HTTPS-capable, PROTO_RELATIVE would return non-absolute URLs which non-browser-based clients might be unprepared for, and PROTO_HTTPS could cause problems for clients with poorly configured HTTPS libraries (there are lots of those).

It somewhat reminds me of https://gerrit.wikimedia.org/r/#/c/191533/, where a parameter was being added to specify how to expand URLs. That patch got bogged down in the fact that we had no way to globally specify URL expansion for everything that generates a link during the parse, but this case wouldn't have that problem.